Oh, come on, it's much more complex than that. It's more like an hour.

A unified open free OS is only easy to develop for if nobody uses the rights that they prize. If people start modifying the OS the way they claim to want, instead of a small number of, say, mediocre and predictably broken OSes, you end up with a large number of unpredictably broken OSes, simply by virtue of the fact that, while visible and reproducible, changes do not instantly apply everywhere, and by the principles of F/OSS software, indeed they should not.

Does anybody remember UNIX? UNIXes embodies far more fully the principles of Open Source in that they spread, forked, and changed by whim far more freely than, say, Linux has done. Many UNIXes were flat-out incompatible, even with source, with other flavours of UNIX. It is for this sort of incompatibility (among other issues) that many people looked to Open Source software for a remedy, not realizing that it is simply a codification of the same principles that produced the problem.

The ability to fork (essentially, the only difference between F/OSS and proprietary software) can only exist in a vibrant community when it is used exceedingly sparingly. This is why Linux (the kernel) has such popularity, while so many distributions essentially repackage the same software, creating more confusion than value. It is precisely by failing to embrace the principles of F/OSS software that Linux, Apache, and other enduring open source projects have attained the popularity, ubiquity, and even quality that they have.

Imagine if everyone who wanted a bug fixed in Apache had simply patched their own version, and distributed the patch themselves. Imagine the confusion of patching, having to know whose versions of what patches were previously applied, because there are dozens of versions of each bug's patch, and some (many) of them change internal values or structure in incompatible ways. It is precisely because Apache has been centrally maintained that it is so simple and easy to say "I'll just use Apache."

But, you say, surely the ability to see the code is the key? Apple and Microsoft both have ways of allowing people to see certain parts of their useful codebases, under licenses that claim any changes (Apple) and/or forbid further use (Microsoft). These are typically criticised as being "not open". What, then, is left? The key difference, then, is simply the ability to re-use - i.e. fork and own. From a practical standpoint, therefore, access to the source without the ability to directly make changes and use/distribute the modified versions is not sufficient to satisfy the demands for F/OSS software.

The one line that differentiates F/OSS software from proprietary software is the ability to fork without permission or recourse, and it is that ability that prevents an open free PC with a unified open free OS from ever existing.

The ability to modify the Javascript neither grants the ability to read statements from a server that no longer supplies them (by far the most common cause in such a scenario) nor does the lack of such ability prevent a trivial, yet far, far more effective counter to such changes - downloading or making PDF versions of the statements. Further, allowing such modifications could be construed to relieve the bank of the burden of providing a working web interface, as the blame could be put squarely on the open-source community, and any problems attributed to the use of the wrong version of the Javascript display code.

Google Documents stores documents on Google's servers. Having a modified version of the Javascript used will not grant access to server-side resources from an even moderately competently designed web service.

Business web apps tend to be either in-house apps or likewise tied to external servers. Having access to the front end does not in any way mitigate the problem of losing the back end server and database. If you want an entire F/OSS system (front and back end) those are already available and clearly marked as such. The F/OSS status of the Javascript really only matters when it is part of such a system.

Most sites either provide their account terms online in text (rather than Javascript) form, and the license status of the Javascript itself is completely irrelevant to the terms for the service itself.

If you want to study encryption, download the Firefox code and see how it implements SSL. Real applications typically use SSL for encryption rather than relying on tricky Javascript encryption that just adds complexity without benefit. Anyone who does use such encryption or other security features in Javascript already exposes the code to public scrutiny by virtue of View Source. Allowing others to re-use that bad decision just results in worse web apps and bad attempts at "encryption" under the assumption that somebody would notice if it was a problem.

If you only use your web "browser" to ensure that you meet the most stringent standards of pointless ideological purity, then you might want only F/OSS Javascript running in it, but your application scenarios have shown that not only does GPL'ed Javascript provide no practical benefit, it has serious drawbacks both from the perspectives of consumers and businesses.

I want the option to "(x) Warn before running dodgy F/OSS Javascript"