Page 4 of 5 FirstFirst 12345 LastLast
Results 61 to 80 of 84
  1. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #61  
    Quote Originally Posted by Cobraextreme View Post
    I'm so sick of s219 and his ilk hijacking every thread and making it about code obfuscation that I feel compelled to respond to this. Yes, this is an issue with webOS, but it's also an issue with all client-side code. Whether your code is obfuscated or not, someone can always reverse engineer any software you make. There is always a shop in India or an MIT student that can rip you off, and do it better and cheaper, and compiled code makes absolutely no difference in preventing that.
    On a scale of 1 to 10000, reverse engineering javascript would be a "1" and reverse engineering machine code would be "10000". It's a huge deterrent. For all practical purposes, I consider machine code secure. Many linchpins of IT security are based on this same assumption.

    People who only work on phone apps and call themselves developers should be reminded that coders are a dime a dozen and do not a software business make, any more than factory workers make a car company.
    Actually, in the mobile market right now, ideas are a dime a dozen but developers are about $200 per hour (and good ones are fully booked).

    If you can't figure out how to make money using the tools that are available, then you either need to hire some non-geeks who know how to run a business or find something else to do for a living.
    The problem for Palm is that there is a third and more obvious option, and that is to develop for another platform instead.
  2. #62  
    Quote Originally Posted by clipcarl View Post
    As a long time software engineer I can tell you this is a really big deal for many developers. And people have been looking for systems to protect this type of interpreted code for years and nothing really effective has been developed. I doubt Palm is going to be able to come up a good solution to secure this type of code when much bigger companies over a much longer period of time have not been able to.
    I disagre completely that "nothing really effective has been developed" for "this type of interpreted code".

    Zend was effective enough for PHP4 that the core functionality of the engine is now a part of PHP5. One of the primary purposes of Zend has been to protect commercial PHP code.
  3. #63  
    Quote Originally Posted by s219 View Post
    ...
    The problem for Palm is that there is a third and more obvious option, and that is to develop for another platform instead.
    And yet, the apps keep coming in...
  4. #64  
    Apparently Palm sees a way to make money while their code is exposed. I guess they're better at this than you are.

    So if you really don't see a way to make money here, why are you in this forum spreading FUD all the time? Shouldn't you be off making your allegedly profitable iphone apps? (ha! - when's your IPO, I really want to get in on that!) It really hampers my enjoyment of the forum to have you in here spreading nonsense all the time and trying to scare the newbies. They aren't interested in you not being interested, and they're not going to go buy an iphone and buy your 99 cent app because you post in this forum.
  5. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #65  
    Quote Originally Posted by hparsons View Post
    I disagre completely that "nothing really effective has been developed" for "this type of interpreted code".

    Zend was effective enough for PHP4 that the core functionality of the engine is now a part of PHP5. One of the primary purposes of Zend has been to protect commercial PHP code.
    Zend encrypts the source script and then decrypts it at run time. This is effective for server side code that executes on the server. It will not work for client side code that runs locally however. There is a big difference between protecting remote-execute code and local-execute code. In the case of the latter, you can ultimately get to it at runtime.
  6. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #66  
    Quote Originally Posted by Cobraextreme View Post
    Apparently Palm sees a way to make money while their code is exposed. I guess they're better at this than you are.
    Don't count your chickens before they hatch; at least wait for the financial report next week.

    So if you really don't see a way to make money here, why are you in this forum spreading FUD all the time? Shouldn't you be off making your allegedly profitable iphone apps? (ha! - when's your IPO, I really want to get in on that!) It really hampers my enjoyment of the forum to have you in here spreading nonsense all the time and trying to scare the newbies. They aren't interested in you not being interested, and they're not going to go buy an iphone and buy your 99 cent app because you post in this forum.
    I am not in here for the personal gains you theorize about; the anonymity of forum posting eliminates that. In fact, I have taken extra caution to not give out specific information on my projects or my client's projects because it's not appropriate.

    What you call FUD is reality (it's backed up by fact, irrespective of my opinion) and pointed criticism from a developer in the trenches. I know it bothers some of the folks that run around cheerleading the platform. But cheerleading will not advance the platform. Cheerleading will not resolve the issues. Cheerleading will not make the issues go away.

    I've said it before, and I'll say it again. If people like you moaned when developers were complaining about iPhone 1.0, labeling dissenters as anti-platform and stifling the criticism with blind support, the iPhone platform would not have flourished like it has. That has served to energize the entire mobile market. To this day, developer critique of the iPhone platform is among the most effective ways to steer it and move it forward. Third party developers look farther ahead than consumers and have more of a technocratic view of a platform.

    If you want to ignore what I am saying, fine. It's not going to hurt my feelings. But as a consumer, you should be concerned about some of these issues, because they have a direct impact on the long term viability of the platform.
  7. #67  
    Quote Originally Posted by s219 View Post
    Zend encrypts the source script and then decrypts it at run time. This is effective for server side code that executes on the server. It will not work for client side code that runs locally however. There is a big difference between protecting remote-execute code and local-execute code. In the case of the latter, you can ultimately get to it at runtime.
    Thank you for confirming what I said. You will notice, I said nothing about remote-execute code vs local-execute code. I specifically quoted his comments about "nothing really effective has been developed" for "this type of interpreted code". Something, in fact, has been developed that compiles and (when needed) obfuscates intepreted code. That was my point. Before PHP (which was an interpreted code), ZEND didn't exist. It was developed because PHP presented a need to obfuscate such code. The symbiotic relationship matured to the point where the ZEND enging no basically makes PHP5 a compiled and executed code. The widespread use of PHP made such a system possible. In spite of the naysayers who can't see beyond the box of their current methodology, it's new uses (such as WebOS) that spawn new solutions.

    You've made it clear that you don't like Palm's methodology. That's fine. However, I suspect that no other new OS has had the number of apps (and services) released for it that WebOS has in 3 short months. That says something about Palm's decision. Apparently, others feel they can accomplish something with the system Palm's introduced.
  8. #68  
    Quote Originally Posted by s219 View Post
    ...
    What you call FUD is reality (it's backed up by fact, irrespective of my opinion) and pointed criticism from a developer in the trenches.
    ...
    No it's not. The FUD (Fear Uncertainty Doubt) is not reality. You keep insisting that developers are not going to develop, yet it keeps happening. You've implied that commercial developers are not going to develop, but they are. You're posts have been accurately portrayed as what they are, your opinions whose point seems to be to scare readers to other platforms.
  9. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #69  
    Quote Originally Posted by hparsons View Post
    No it's not. The FUD (Fear Uncertainty Doubt) is not reality. You keep insisting that developers are not going to develop, yet it keeps happening. You've implied that commercial developers are not going to develop, but they are. You're posts have been accurately portrayed as what they are, your opinions whose point seems to be to scare readers to other platforms.
    I am not insisting anything. One need only look at existing apps and new apps to show that developers are developing. I am not disputing that at all. Again, you're interpreting my remarks and narrowing them down to make a point I am not making.

    Yes there are apps, that is reality. Just like the issues I raise. Those issues are preventing other developers from working on the platform.

    When you see OpenGL apps, apps with protected source, apps doing sound processing, and apps using high accelerometer rates (among a much longer laundry list of things I have been hammering on) then some of my concerns will have been addressed. Then you are 100% welcome to tell me I am wrong, but at that point I will be glad to be wrong. That is *not* the case now, and my concerns stand.

    If this is a case of glass half-empty versus glass half-full, that's fine, you're entitled to see it from your own viewpoint. But the fact that developers are doing "A,B,C" doesn't change the fact that they're not doing (or can't do) "X,Y,Z". For the developers who want to do "X,Y,Z" it's a problem. That's where I am coming from.
  10. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #70  
    Quote Originally Posted by hparsons View Post
    Thank you for confirming what I said. You will notice, I said nothing about remote-execute code vs local-execute code.
    Which means your point was irrelevant, which is what I was trying to point out. What works for PHP is not relevant to local javascript execution.
  11. #71  
    @hparsons: PHP is not the same as Javascript. Server side code is not the same as client-side code. And Zend's obfuscation is easy to get around and not at all effective (google "dezender" and there are quite a few others similar to that). You are comparing apples to oranges but even so your example actually does more to prove my point that those types of solutions are ineffective than your own point that they are.


    However, Cobraextreme is right about one thing. This is not what this thread is about so perhaps this discussion should be taken elsewhere?
  12. #72  
    I agree this thread has gone off topic...but it's still a fascinating discussion and I hope it continues.

    A few questions:

    1) Is there a server side solution to this Javacript issue? For instance, could there be a client side code that executes on the server? I suspect this might mean that an internet connection would always be required for the application to run. But isn't that how Evernote is set up right now?

    2) s219, do you have any recommendations on what Palm could do to protect the code, or is it a lost cause?
    Last edited by Really mobile; 09/07/2009 at 07:17 PM. Reason: added: "or is it a lost cause?"
  13. #73  
    Quote Originally Posted by s219 View Post
    Which means your point was irrelevant, which is what I was trying to point out. What works for PHP is not relevant to local javascript execution.
    Actually, it does not "make my point irrelevant." You make the mistake of assuming because something is not relevant to you, it is simply not relevant. The person whom I quoted made a statement. My response was relevant to that statement.

    Not everything is about you, or your view.
  14. #74  
    Quote Originally Posted by clipcarl View Post
    @hparsons: PHP is not the same as Javascript. Server side code is not the same as client-side code. And Zend's obfuscation is easy to get around and not at all effective (google "dezender" and there are quite a few others similar to that). You are comparing apples to oranges but even so your example actually does more to prove my point that those types of solutions are ineffective than your own point that they are.


    However, Cobraextreme is right about one thing. This is not what this thread is about so perhaps this discussion should be taken elsewhere?
    Ahh, the "I will make my point, now everyone please stop talking about it" tactic.

    Yes, I understand that the difference between Javascript and PHP. You missed my point completely. Not only was there no way to obfuscate PHP before some one came up with ZEND (and other similar engines), their development completely changed PHP. Whether you choose to accept it or not, similar possibilities exist for Javascript. They already exist in their beginning stages (just like ZEND was much more primitive when it was first developed.)

    I'm glad that the world is full of more imaginative IT engineers than what I see represented by the "it can be doners" on here...
  15. #75  
    Quote Originally Posted by Really mobile View Post
    I agree this thread has gone off topic...but it's still a fascinating discussion and I hope it continues.

    A few questions:

    1) Is there a server side solution to this Javacript issue? For instance, could there be a client side code that executes on the server? I suspect this might mean that an internet connection would always be required for the application to run. But isn't that how Evernote is set up right now?
    Absolutely:
    Server-side JavaScript - Wikipedia, the free encyclopedia

    They are not widely implemented, but "widely implemented" doesn't happen until ... well things begin to get implemented widely. Most of the popular technologies used today were once not widely implemented. I suspect the original developers of HTML (Hyper Text Markup Language) never conceived of the things that are being done with HTML5 and the rich markup language that allows apps to be more easily, and more consistently, placed on the web.
  16. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #76  
    Quote Originally Posted by Really mobile View Post
    I agree this thread has gone off topic...but it's still a fascinating discussion and I hope it continues.

    A few questions:

    1) Is there a server side solution to this Javacript issue? For instance, could there be a client side code that executes on the server? I suspect this might mean that an internet connection would always be required for the application to run. But isn't that how Evernote is set up right now?

    2) s219, do you have any recommendations on what Palm could do to protect the code, or is it a lost cause?

    Well, javascript executes locally on the device in webOS apps. Even if you distribute javascript code to the device from a server, it ends up executing on the device and becomes transparent within the device's javascript environment (webKit in this case). That's where it becomes vulnerable.

    You can run stuff on the server, and that is the approach I have taken with the web apps I have developed. Then they deliver results to the device for display. I can still use javascript on the device for any interaction with the results, perhaps sending something back to the server, but it's so minimal and basic I don't care if that code is exposed. The main point is that the sensitive code is contained on the server behind some sort of secure shield (I normally use PHP for server side stuff).

    As you noted, the downside is that you need an internet connection, so it's not really attractive for many apps. In my opinion, the web app approach only makes sense if the app has an honest to goodness "web" aspect to it, or if the developer has some reason to update source code frequently and wants to be able to push changes out to devices. Three of my iPhone apps (the three which require a web connection for functionality) mix native app technology with javascript running in a webKit webView and communicating with PHP on the server. It ends up being the best combined approach. The rest of the apps don't need an internet connection and it would not make sense to incorporate a server component.

    I honestly don't see an easy way to protect locally executing standard javascript code because javascript is an interpreted language, and at some point it must be converted into readable code prior to execution. Palm could come up with some random way to encrypt the code and then write their own custom runtime environment to execute encrypted, but that would break everything in the webOS because of the dependence on webKit (which only runs straight javascript code). They'd have to write their own custom webKit basically -- no small feat (we'd be talking years of work just to get where webKit already is).

    I think the fact that Palm's own apps ship without protection and they are distributing third party apps in the catalog without protection indicates they don't see a solution (and they've indicated as much in their dev forums). Once the app catalog kicks into full swing, they won't really be able to backtrack -- generally that stuff gets established and sticks for a while. If there was a solution, the time to implement it would have been a few months back when everything launched.
  17. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #77  
    Quote Originally Posted by hparsons View Post

    As a follow up to my post, I wanted to note that this is in the same vein as running PHP or any other scripting or compiled language on the server. It requires isolating some aspect of the execution to the server and limits what you do on the device.
  18. #78  
    So it seems that developers have two main ways to create apps: (1) protected apps that execute on the server side but that require an internet connection, OR (2) unprotected apps that execute on the client side

    Certainly not an optimal suite of options but something a few developers might decide to live with in the short term. In a year or so, assuming Palm is still around, option #1 might not be too bad if there's better internet connectivity/capacity...especially as carriers migrate to LTE. At that point web apps (Google's preference, right?) could indeed rule. But in the short term, it's a much less palatable option for developers given the availability of alternative platforms like Android. That does not mean we won’t see apps that leverage this option (e.g., Evernote).

    An open question is whether we'll see a significant amount of proprietary applications under option #2 above. It's too soon to tell. It’s also not clear what target to use to determine if a sufficient amount of developers are on board. Is it one paid app, 100 paid apps, or 1K paid apps? I think each of us has our own metric in mind. But we'll certainly get a better sense in a few months how quickly the platform is being adopted by developers. Right now it’s too soon to tell.
  19. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #79  
    And keep in mind that option 1 comes with compromises that might not make sense for some app concepts, like ones that don't want (or need) to be dependent on an internet connection for functionality. There are a lot of reasons to pursue a web app approach that bring benefits to the app. Doing it for source code protection alone is more like accepting a compromise. Ideally, making a web app would be motivated by other reasons first.
  20. #80  
    Quote Originally Posted by Really mobile View Post
    So it seems that developers have two main ways to create apps: (1) protected apps that execute on the server side but that require an internet connection, OR (2) unprotected apps that execute on the client side
    ...
    An added aspect to all of this is the fact that the Pre is a client and a server. There are already server side applications (Java and PHP) being run on the Pre.
Page 4 of 5 FirstFirst 12345 LastLast

Posting Permissions