4 ms·

Blocking the JS is great and makes complete sense. It's like a slightly more open NoScript, in that it tries to analyze the JS first. The part I take issue with

• lazaroclapp 10y ago
  Technically, you wouldn't be asking them to disable AJAX, you would be asking them to make the code free software. Now, if people do this for Gmail or Twitter they will probably get no response or a formulaic response about not opening their code. But how about Wordpress? Or Wikipedia? Or government sites developed with public money in certain countries that require open sourcing public works? I think opening that tab by default is a bit much, but I can imagine cases where people would report "hey, this site is/should be running open-source/free software, please add a license to your code". This is not about blocking code execution in your browser, is about not running proprietary code in your browser if you don't want to.
• comex 10y ago
  No, people 'should' (according to this view) be emailing Google and asking them to release their client webapp as free software, after which they can continue using all the AJAX they want. If by some miracle they agreed, it would give users a number of advantages including: - Making customization (Greasemonkey etc.) easier by removing the need for customization tools to muddle through JS minification/obfuscation. While in practice various tools today are doing a good job customizing Gmail anyway, I imagine they could make more changes and more invasive changes with access to the source. - Special case: making client-side encryption browser extensions safe. Right now they are fundamentally unsafe (if they hook into the webapp rather than providing a separate interface), because there is nothing stopping Google from quietly adding some JS code to grab and report the plaintext before it gets encrypted. By itself, releasing the webapp's source wouldn't fix this because you would still have to trust Google's servers to send the same JS to everyone - but a browser extension could be enhanced to hash the page JS and refuse to operate with non-approved hashes, combined with a process where someone outside of Google manually approves changes as they are released, providing at least cursory review. Nobody wants to review obfuscated code. - Allowing users to detect and remove any other forms of tracking/deanonymization that might be present such as mouse cursor or keystroke recording, canvas fingerprinting, etc., more reliably than with the sorts of purely technical measures that could be implemented in a browser (since these things are hard to block without preventing the app from doing its job). - The kicker: Allowing the same webapp to be used with a different backend, so if you don't want Google to have access to your email, or don't trust them not to cripple functionality in the future, or need a lot of storage and can get it cheaper elsewhere, or are in China and have an (intentionally) shitty censored connection to the international internet, ... the list goes on... then you can self-host it, without losing the familiar interface. You can also host your own clone service for others to use, perhaps forking off the original code when Google makes an unpopular change, as they are wont to do. Of course this requires someone to actually do the technical work of writing a suitable new backend for the client to talk to, and in the case of a fork to maintain a huge codebase (compare Palemoon and such), but without free software you can't even get started (legally). Of course, Google might not be too happy about that last point. But rms's ideology has never been pragmatic about 'business needs' and such. It's concerned only for the users. Twitter is a somewhat less traditional case: the case for free software is either less applicable or far more, depending on how strictly you define "free software". This is because unlike Gmail, which provides decent support for third party clients, Twitter has long cracked down on them in various arbitrary ways and enforced strict rules that prevent them from innovating on UI. Since one of the informally-defined 'freedoms' of free software is the ability to modify it, it should be possible to morph the official browser client into anything you want - even if that means keeping just the API access layer and building an entirely new UI on top - and continue to use it freely. Thus if Twitter changed their tune and actually dedicated themselves to these freedoms, that would imply starting to tolerate access by arbitrary client software, and users would hugely benefit. However, if for some reason Twitter were to hypothetically release their client under a free license - even under the GPL - while otherwise continuing with their current policies, it wouldn't affect the situation much. The license would at least allow third parties to check the source for Twitter's own API key and copy it into their own apps without exposing themselves to legal liability related to copyright/DMCA. But Twitter could still try to identify and block rogue clients, sue under the CFAA ('hacking' statute) for unauthorized access, ban the personal accounts of creators of rogue clients, etc.