FSF Suggests That Google Free Gmail Javascript
Phoe6 writes "Apparently, FSF is calling it a 'JavaScript Trap' and wants 'useful websites' such as Gmail and others such as Twitter, Facebook to release their JavaScript code under Free Software License so that users can trust their service."
FSF wants Windows, Office, Photoshop, and everything else to be free. That's their job. People need to be able to make money on software, or large corporations won't invest in it. That's why FOSS-friendly companies like Sun are going under and being snapped up by profit-hungry pricks like Larry Ellison. Film at 11.
You do realize that you can already debug it and step through because it's client side?
XML is a known as a key material required to create SMD: Software of Mass Destruction
You may not know it, but the website you're reading RIGHT NOW is a festering hotbed of evil. EVIL. Evil code that will steal your information, kill your wife and children, and damage the transmission on your car.
The ONLY way around that is to use our new FSF GnuWebScript, which is Totally Open and Free. Not only is it a Force for Good, it whitens your teeth and makes your toes smell nicer. It will never do those evil and nasty things that the Javascript does, because it's not Javascript - it's GnuWebScript!
GnuWebScript is a free side-set* of ECMAscript, a tragically unfree industry standard. GnuWebScript implements everything in ECMAscript slightly differently using free, non-proprietary language extensions.
GnuWebScript - to be free you must chain yourself to it!
* side set is not a superset or a subset - it's a sideset.
I feel like it's asking too much. The concern is, "hey gmail maybe your code triggers some js machine bugs, and we dont trust it." That's valid. But asking them to open source it for inspection, well that lets other folks pick the pieces up and start hawking their own version. Isn't there a middle ground [to ask for, and be denied]? I've just become jaded enough to start agreeing with that crappy business model "let the 10% that complain cancel their service". So long ago that seemed like a joke answer a fake company would use, but now we see it all the time. And I agree with it, alas. If you dont trust gmail, dont use it. Dont ask for their trade secrets either under the veil of security auditing and the intended benefit of legally copying it, or legitimately security auditing it and haphazardly allowing competing services to glean legal copies. Ask for some NDA access to have yourself or someone you trust inspect it. Just because something can be open sourced, doesn't mean it needs to be.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
I would agree that client side code is (relatively) accessible via the programmer (even if it is compressed); however trusting their server side execution of those includes is really where the trust factor comes into play. Most browsers will lock down cross domain requests. The real power is controlling what the server serves to the users that use that include.
For example, www.xyz.com decides to include a couple lines libraries from google.com, say, jquery, and analytics. By virtue of making the include, that third party site has the ability of pass messages back and forth via code generation (to bypass the cross domain issues) and manipulate the DOM of www.xyz.com in however it sees fit. Now, a security minded person wouldn't include a resource that's off-site, for this very reason. Good examples of this are bank sites like usaa.com. No where on that site will you see a third party domain resource, once you've signed to your account. Putting the resource files on www.xyz.com makes a lot of sense for versioning, but also securing the site from potential hacks of the third party (hacking that google's analytics includes or akamai servers is a juicy opportunity, but only if you could execute code server side).
When it comes to javascript, the best way to secure your site is to host your own resources, and DON'T use off site includes that are from untrusted sources. Even if the source is trusted, it doesn't mean your in the clear. Your best bet, is to always host your own site resources.
I don't quite see the point. Sure it would be nice to have the Javascript under a Free Software license, but that would be very far down my list of priorities, as with Javascript and the Web in general there is one very fundamental difference to regular software: You neither own that stuff nor control it, they do and that is the problem that needs attacking. It doesn't make a difference if they stick a GPL header on top of their code or not, I as I would still be forced to use whatever version they ship me, keeping around an older copy with features they might have changed/removed/whatever doesn't help me when the API to their servers has changes, that old GPL copy might either break or become unusable. The real solution would be to provide standard data driven APIs for webservices, so that I wouldn't depend on their Javascript and HTML code, but could roll my own.
The whole problem with the Web today is that I don't have direct access to my data, but instead can only access it via a whole swoop of HTML and Javascript stuff, that makes it frequently hard or even impossible to actually do certain operation. A very basic example would be backup. Yeah, I can download mail from GMail via POP or IMAP and that will give me some of my mails, but what about chat logs, mail I send, tags, contacts, etc. and a bunch of other meta data that isn't just the mail? Can I backup all that? And even more importantly: Can I actually restore it? If GMail decides to delete my account tomorrow, can I open a new one and restore my backup into the new account? Can I do that when I change mail providers? Will meta data survive the transfer? That is the problem that needs fixing, as almost all webpages suffer from it, even the glorious 100% Free Software ones generally don't give you full import and export capabilities of your data and even when they do the interfaces are often limited and cumbersome.