On Friday 27 March 2009 00:28:07 Daniel Cheng wrote: > 2009/3/27 Matthew Toseland <[email protected]>: > > On Thursday 26 March 2009 15:26:19 Daniel Cheng wrote: > >> On Thu, Mar 26, 2009 at 9:47 PM, M <[email protected]> wrote: > >> > I understand that javascript has to be disabled because of the > >> > multitude of security holes it could open up. I was wondering if anyone > >> > had ever thought about a freenetscript similar to how facebook > >> > implemented FBML and FBJS to allow developers lots of scope for > >> > functionality whilst stopping phishing attacks. > >> > >> I did propose something similar in the past. > >> But some developers think it is far better to have a JavaScript > > parser/filter. > >> -- a "good" one, not a "complete" one. . > >> [it can not be comepleted, for it is a proven equivalent to the halting > > problem] > > > > Not true. Only a filter which cannot modify code is equivalent to the halting > > problem. A filter which can modify code and insert guard functions is quite > > feasible: it does not need to know what the long-term behaviour of the code > > is, it just needs to know that the function for e.g. HTML insertion will > > always be fed through our HTML filtering. > > Either we have to code a HTML filter in javascript, > call back to server, or we end up with something too tight.
And what's wrong with calling back to the server via an XMLHttpRequest? > > Doing this in *static* context is *undecidable* in tuning machine. Agreed, static analysis is equivalent to the halting problem. > > Attempt to do this would confuse the user : > -- programmer always want something predictable. The output of the filter should be predictable. It won't be the same as the input but it will be derived from the input. Bugs in the filter are of course a possible problem but bugs are always a problem. > -- the user may spend hours inserting a freesite and end up with > something doesn't work .... Minor problem, there are solutions to this e.g. local-only inserts, FCP filtering interface for authoring tools etc. > > > Having said that, there are various > > subtle attacks which it may not be possible to exclude completely without > > some fairly extreme measures (e.g. not allowing scripts to insert). > > > > Also I don't recall a proposal for a flexible scripting subset, iirc we were > > talking about recipes... > > Long time ago, > I have proposed a very small defined javascript subset with helper functions > (just if-then-else, while, with a few functions no access to dom > object directly, etc) > > This subset have to be predictable -- that is the developer > should know if it will work without actually go though the filter. Any subset that doesn't include DOM is going to be *very* freenet specific: we will have to provide safe APIs to change images etc, rather than using the DOM attributes. Existing javascript therefore cannot possibly work, eliminating much of the attraction of supporting javascript in the first place. > > >> > The FreenetScript could be parsed by FProxy and turned into regular > >> > javascript with freenet-only links.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
