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.
-- http://gnuzilla.gnu.org
