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: Narcis Garcia
Subject: Re: [Bug-gnuzilla] IceCat 38.3.0 release
Date: Fri, 16 Oct 2015 09:08:40 +0200

JavaScript cases to whitelist by default:
- Single JS command in HTML event (e.g onLoad="document.frm.i.focus();")
- Identified JS file or function available at JS FLOSS repository. Then
use only the file or function from that trusted repository.

JavaScript cases to blacklist by default:
- Script file provided (src=) from a different domain than user is visiting.

+Manual approval or disapproval of functions or files.

We are facing the same problem as in MS/Windows with applications, where
people download and run executables from unknown sources.



-------- Missatge reenviat --------
Assumpte: Re: [Bug-gnuzilla] Freedom of html... JavaScript trap
Data: Sat, 04 Jul 2015 09:51:14 +0200
De: Narcis Garcia <address@hidden>
A: address@hidden

This returns to a 2014 thread, when Jonas Wielicki said "99% of the
users don’t understand javascript. And those who do will *still* be
faced with ununderstandable minified gibberish".

I took part of Julian Marchant's idea to expose my similar opinion:

Managing scripts as software packages that user authorises to install
and/or update.
This could open the door to, in the future, exist JS FLOSS repositories.

99% of the users don't understand Java, but they install java
applications from mobile's repositories, and select what to add or remove.

And many users understand the concept of "extensions" or "plugins" for
an application. If we consider a website as an application (as most
users do), we can consider JavaScript functions (or libraries) as
optional plugins.

This conceptual view can allow in the future to develop better
webbrowsers and give easier access to security and privacy.



El 16/10/15 a les 05:00, Ivan Zaigralin ha escrit:
> 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.
> 
> 
> 
> 
> --
> http://gnuzilla.gnu.org
> 



reply via email to

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