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. 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
