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

[Ivan Zaigralin]

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

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