On Fri, Jan 24, 2003 at 03:19:26PM +0000, Gordan Bobic wrote: > On Fri, 24 Jan 2003, Matthew Toseland wrote: > > > > > No. Your application would not use Fproxy anyway, it would probably use > > > > a library to talk directly to the node using FCP. What language are you > > > > considering? > > > > > > Perl for maintainance utilities and browser-side JavaScript for client-side > > > operation. > > > > > > And yes, I know that JS will make the anonymity filter complain, but > > > ultimately, JS in browser is no more of an anonymity issue than any other way > > > to create Freenet application. > > > > Hmm. Interesting. Have you considered writing it in java as a servlet? > > I thought about it, but fundamentally, what is the difference from the > technical perspective? Other than the filter warnings? > > > Surely you do not want to make users have to click anonymity warnings every > > five seconds? :). > > Yes, that is the one thing a servlet would have going for it. This, > however, will only make it APPEAR to be more secure as far as anonymity > leaking is concerned. Whatever method is used, the only way to be sure > nothing untoward is happening is to read the code - something most users > will not do one way or the other. Well, firstly, the anonymity filter currently REMOVES all javascript on the fly. It does not give the user an option to allow the javascript, short of disabling the filter completely. If it did, it would still be bad, because with a servlet, the user installs it, and sets it to be trusted, once, because they got it from a "safe" source, because they don't care, or because they read the code. If however we rely on the user clicking through, either they will turn off the filter altogether for everywhere, or they will always click any warnings that come up. Either way they are fucked. > > I will probably make a JS prototype first. After that, if it looks > worthwhile, I may be tempted to write a servlet implementation that could > sit within fred. > > > Eventually, we will implement somse sort of server > > side scripting... with a couple of limits it could be reasonably safe. > > Do you mean node scripting? Or do you mean routed single-server style > access? The latter would always be voulnerable to routing analysis to some > extent. But, this is probably too small a risk to worry about in a very > busy network, as there is no way what connection is for what. > > But if node-side scripting exists instead, then that means that ANY node > can download and execute script code to serve a request. This would be a > fantastic solution for hugely distributed web applications with near > infinite scalability (any node can run any script, just like it can serve > any file request, provided it has it). > > Have you considered using the Rhino Java based JS interpreter? That would > be a very "cool" feature. > > As far as algorithms and optimizations are concerned, however, all four > approaches (fred servlet, fred scripting, browser scripting, > standalone app) would be pretty much the same. Fred servlet idea has > merits in the fact that there will be no filter complaints. > > I think I like the fred scripting idea best, because it has all the > advantages of the other approaches, but is additionaly the most scaleable > one, because any node could serve a request. This could also be used to > move the process to the data, rather than always moving the data to the > process. The downside is that if there is a security exploit, ALL of the > nodes would compromised almost immediately. So, if something goes wrong, > it's time to re-initialize ALL the nodes... :-( > > There is the question of how to optimize the issue of which node runs > what. Why not have only the requestiong node run the code? In that case, > there is no difference between node-scripting and servlets or > "browserlets". Fred scripting would still be safer, because, at least in > theory, the code would not be able to get out of it's Freenet sandbox. But > then there is nothing to stop it collecting potentially anonymity > threatening information... > > > We might just allow some client-side stuff, but only "trusted recipes". > > How would these be identified? Keeping a list of "trusted" sites? > > > Help with this would be greatly appreciated :) > > Which part? I'd be happy to lend a hand here and there as far as coding is > concerned, especially if it would help with getting features such as > node-side scripting to work. I am concerned, however, with the danger that > could potentially cause to the network should a security exploit exist... > > Hmm... Should I should subscribe to the development list for further > discussion of this particular feature? > > Regards. > > Gordan > > > _______________________________________________ > Tech mailing list > [EMAIL PROTECTED] > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/tech >
-- Matthew Toseland [EMAIL PROTECTED][EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/eI49KUM9vEY/ ICTHUS.
msg01069/pgp00000.pgp
Description: PGP signature
