bug-gnuzilla
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnuzilla] IceCat 38.3.0 release


From: Ivan Zaigralin
Subject: Re: [Bug-gnuzilla] IceCat 38.3.0 release
Date: Thu, 15 Oct 2015 20:00:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/15/2015 05:31 PM, Julian Marchant wrote:
> There's another problem: JavaScript code embedded in Web pages can't
> be replaced with other JavaScript code properly, unless you can get
> the entire Web page downloaded to your local hard drive (which is
> often impossible because of dependence on server-side code). There
> needs to be a browser feature that makes such replacements possible.
> I've suggested in the past that all scripts accepted by the user
> should be stored permanently; that way, the script could be modified,
> and it could even provide a nice bonus of telling you any time
> JavaScript code on a website is modified.
> 
> That should be a goal of IceCat.

Mmmmmay be, in the absence of anything better. At least it will work for
some users. I honestly don't know anymore if there's ANY way to "fix"
javascript. I envy RMS, who has the gully to actually refuse to run ALL
non-trivial non-free javascript. I hope (for his sake) he actually looks
at the code for the purposes of making that distinction :) Most users,
however, cannot afford to inspect the code or audit the changes in the
way described.

> Until then, I think it should just be
> shipped with JavaScript disabled by default.

I don't know if we want to go this far, but I am tempted to agree. I am
afraid this is the only honest approach, and it is consistent with how
we treat addons. After all, we solve the addon problem by whitelisting
the ones we know to be free. If we take the same approach to javascript
and refuse to aid the user in running nonfree javascript, even by
mistake, we immediately realize we cannot whitelist scripts. So the only
practical thing to do is to whitelist domains which start with https,
the domains of parties we know and trust. And this, of course, implies
javascript off and a link to noscript or something like that.

Optimally, there should be an up-to-date list of free-loving domains out
there (like a live web service), so that the user can just jump in and
never touch the javascript settings ever. Or may be some kind of
distributed solution resembling a web of trust. At any rate, running
even just one hot-off-the-web script without crypto-authing the source
is a recipe for disaster. There is just absolutely no way to say whether
it's going to be free.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]