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. > > 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. I mean running limited scripts on a VM in fproxy. > > 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). Err, maybe. > > Have you considered using the Rhino Java based JS interpreter? That would > be a very "cool" feature. Thanks for the tip. Somebody was going to implement it but it was too early and they disappeared. > > 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. They are not equivalent in security. We cannot allow any javascript code to pass to the browser because we cannot tell what it might make the browser do, and the browser generally isn't very cautious about letting javascript open web pages from other hosts etc. > > 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... :-( It would run on the fproxy, not on the node. > > 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... The requesting fproxy would have to run the code. Given that it can only access a few limited methods, it could be made reasonably safe. For example, we don't want to let it set HTLs for requests of 0. We also don't want it to be able to run parallel requests and see which happens first. Either of these would allow anonymity compromize by various attacks. > > > We might just allow some client-side stuff, but only "trusted recipes". > > How would these be identified? Keeping a list of "trusted" sites? No. Keep a list of (parametized) trusted strings of javascript. Simple things like rollovers or whatever. > > > 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... Help with integrating rhino into fproxy would be useful. You'd need to collude with me quite a bit because of security and portability/bundling issues. > > Hmm... Should I should subscribe to the development list for further > discussion of this particular feature? Probably. > > Regards. > > Gordan
-- Matthew Toseland [EMAIL PROTECTED][EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at ICTHUS.
msg01073/pgp00000.pgp
Description: PGP signature
