Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

I am not sure about the details, but this page explains what the web masters 
are expected to do, annotation-wise, in order to placate LibreJS:

https://www.gnu.org/software/librejs/free-your-javascript.html

I would not call this strategy crazy, but ineffective, yes. What's crazy is 
the common user behavior of allowing their computers to download and execute 
the code from literally dozens of independent sources, none of it audited ever 
by anyone, every time they reload a web page. To add insult to injury, 99% of 
these web pages would be fully functional and much faster if they were 
implemented in flat HTML+CSS.

On Thursday, February 22, 2018 18:50:30 Narcis Garcia wrote:
> It seems a crazy strategy.
> If GNU distributions used this kind of analysis instead of trusting
> software from subscribed repositories, all our computers could be a
> jungle (either with scripts and compiled files).
> 
> How does LibreJS check an script's license?
> 
> El 22/02/18 a les 18:43, Ivan Zaigralin ha escrit:
> > From what I can pick up, LibreJS tries to detect and whitelist "trivial"
> > code first, meaning, the code which an algorithm can recognize as
> > data-like and harmless. For all other code, it checks the license. I
> > don't have details on how these things are done, but both can clearly be
> > programmed in a variety of ways.
> > 
> > On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
> >> I was asking about the CURRENT principle for LibreJS, not for "good" or
> >> "bad" of theoretically prossibilities.
> >> 
> >> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> >>> On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
> >>>> Which is the principle for LibreJS to approve JavaScript functions
> >>>> and/or files?
> >>>> A license mention?
> >>> 
> >>> Can be regarded as necessary, but not sufficient.
> >>> 
> >>>> A signature?
> >>> 
> >>> Useful for creating a trust model between users and web parties, but
> >>> this
> >>> is already implemented by https+noscript, and it solves a different
> >>> problem, not directly freedom-related.
> >>> 
> >>>> A well-known functions comparison? A code analysis? It replaces
> >>>> funcions?
> >>> 
> >>> A code analysis is pointless. Detecting obfuscated code, in particular,
> >>> is
> >>> an intractable problem. If you could define "obfuscated" formally,
> >>> chances are, there would be a formal proof that the detection is
> >>> unsolvable by a TM. But generally speaking, a good way to obfuscate is
> >>> by
> >>> writing a virtual assembly interpreter, and then feeding it "binaries"
> >>> which appear to be perfectly cromulent, poetic even, JavaScript sources.
> >>> And obfuscated code cannot be considered free.
> >>> 
> >>> None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
> >>> miners are all the rage right now. This is where we are today.
> >>> 
> >>> 
> >>> 
> >>> --
> >>> http://gnuzilla.gnu.org
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> >> 
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.