On Fri, Dec 20, 2002 at 09:08:58AM -0800, Ian Clarke wrote: > On Fri, Dec 20, 2002 at 10:01:45AM -0500, Wayne Scott wrote: > > > Please explain, specifically, the bad thing that will happen if we use > > > Javascript in the manner I describe. If you can explain what this bad > > > thing is, then we won't use Javascript. Vague "Javascript is evil" > > > responses don't count. > > How about this one: > > If effect Freenet says this: > > Javascript downloaded from freenet is dangerous and we can't really > > protect you from it so you should really disable Javascript in your > > browser when browsing Freenet. > > You want to add this: > > Most people ignore our advice so, for the best experience enable > > Javascript when running Freenet. But don't worry it is completely > > optional. > > > > It is pretty inconsistent. > > Firstly, that is exactly the vague "Javascript is evil" type of > response I predicted. Secondly, the words you are putting into my mouth > are spinned to death to support your argument, a more accurate > description of my proposal would be: > > "Most people decide to take the informed risk of allowing Javascript and > trusting the FProxy filter. Javascript allows us to make the user informed risk? LOL. The last vulnerability we found was only a month ago, and I'm sure there are more out there. Sooner or later we need to implement a real parser-based anonymity filter. However I am not entirely opposed to either a) server-side scripting with certain limitations (no access to clock, can't set HTL below 2, if request multiple files in parallel, it has no way of telling which one finished first), and b) if and only if we have a good opt-in filter, limited client side scripting (a set of known-good recipes). > interface better than we otherwise could, so lets take advantage of it > when its available, provided that this doesn't deminish the user > experience when it isn't". After we have a good filter, we will be allowing limited scripting... certainly after that point it makes sense for the UI to use javascript. Before that it's a bit hypocritical, but I don't feel strongly about it (now). Implementing such a filter is probably 0.5.3 or so. > > Again, I ask a simple question: > > What is the specific bad thing that will happen if we do this? Browsers with javascript disabled will be slightly less user friendly for freenet. No big deal. Anyone that paranoid can expect slight inconvenience. I agree with Ian. HOWEVER, I am not sure exactly what he is proposing - at what point, exactly, do we create this dialog box? The logical thing would seem to be at the point of clicking the original link from the freesite, and I am not sure we should implement "trusted recipes" at this point. > > It is a perfectly reasonable question, and one nobody seems capable of > giving a straight answer to, rather people are making vague references > to what we are "saying" by taking advantage of Javascript when it is > available. I want more information, but provisionally I am in favour. > > Ian. > > -- > Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] > Latest Project http://cematics.com/kanzi > Personal Homepage http://locut.us/
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021220/7c48f6f1/attachment.pgp>
