Why do browsers not allow non-readable javascript?
11 comments
If you encrypt it, then everyone will need to decrypt it. Which means they need the decryption key or it won't work :-) Sort of defeats the purpose!
If the browser can decrypt it then it is a simple matter to get at the decrypted code.
If you want to make it really difficult to "steal" code just run it through a minifer. You'll never really be able to hide what a script is doing though. If you want logic not to be user-known and very likely user-modifiable you -must- make it server side. If this weren't the case DRM would actually work ;)
If you want to make it really difficult to "steal" code just run it through a minifer. You'll never really be able to hide what a script is doing though. If you want logic not to be user-known and very likely user-modifiable you -must- make it server side. If this weren't the case DRM would actually work ;)
The companies are just going to have to adapt to the culture.
If the browser can decrypt it, then anybody else can. Everything else will be security by obscurity and will be broken.
The one thing I've noticed about every single person so far who has asked me if I could help them "protect" their javascript is that there was nothing at all unique about it.
They've almost always reinvented some part of jQuery or a well know plugin and done it badly.
They've almost always reinvented some part of jQuery or a well know plugin and done it badly.
If your algorithm isn't black sorcery and does anything visible to the end user, another programmer can reproduce it.
Because DRM doesn't work in practice.
There is No Such Thing as Proprietary Client-side JavaScript (http://www.sarajchipps.com/2011/12/there-is-no-such-thing-is...)
I'm all for hating on DRM, but those of you posting here saying that DRM doesn't work under any circumstance are being a bit disingenuous, I think.
Putting the ethical questions aside, if browsers allowed javascript encryption and company X has a program that "frombulates widgets" and they want to protect their code from their main competitor Y, such encryption would present a valuable obstacle, even if it may not be 100% impossible to crack.
Putting the ethical questions aside, if browsers allowed javascript encryption and company X has a program that "frombulates widgets" and they want to protect their code from their main competitor Y, such encryption would present a valuable obstacle, even if it may not be 100% impossible to crack.
I'm getting a flashback of all the sites that used to try to disable right click.
I would say that the fact that the browser "inflicts" open-source upon organizations could be one of the best things that could happen for society. Companies for which this paradigm "doesn't fit the [company] culture" are going to have to make a choice: keep things secret server side and compromise on the UX or move things client side for the sake of a better UX and compromise on secrecy of source code.
Those companies that have secrecy as a cultural value are going to be at a clear disadvantage from a UX point of view. The web is getting faster. People in general are becoming less and less tolerant of load times and other delays. The success of native apps proves this. Choosing secrecy will hurt your company unless you truly have a sauce so special that people will be tolerant of latency to taste it.
Native apps are the last refuge of companies that want to maintain end-to-end secrecy throughout the entire stack. The fragmentation of smart phones suggests that web apps are the future because every apps with social features is less useful if only people with the same kind of device as you can use it. Companies will have no choice but to develop in a space that is open.
As a consolation to companies with secrecy as a cultural value, the locus of computation is increasingly blurred between the browser and the server. The source code of most advanced client-side javascript apps that I've seen so far look like swiss cheese in that they're all full of holes, where the holes are functionality that is handled server side and are often the most complex tasks that an app is performing for the user.
Those companies that have secrecy as a cultural value are going to be at a clear disadvantage from a UX point of view. The web is getting faster. People in general are becoming less and less tolerant of load times and other delays. The success of native apps proves this. Choosing secrecy will hurt your company unless you truly have a sauce so special that people will be tolerant of latency to taste it.
Native apps are the last refuge of companies that want to maintain end-to-end secrecy throughout the entire stack. The fragmentation of smart phones suggests that web apps are the future because every apps with social features is less useful if only people with the same kind of device as you can use it. Companies will have no choice but to develop in a space that is open.
As a consolation to companies with secrecy as a cultural value, the locus of computation is increasingly blurred between the browser and the server. The source code of most advanced client-side javascript apps that I've seen so far look like swiss cheese in that they're all full of holes, where the holes are functionality that is handled server side and are often the most complex tasks that an app is performing for the user.
Perhaps by encrypting the Javascript files and providing a mechanism for them to be decrypted by the browser internally?
Don't get me wrong, I'm all for open source and openness but for some companies it just does not fit the culture.