Hi Matthew, Sorry to take so long to reply, it's been a bit hectic for me these days.
On Thu, Feb 24, 2011 at 5:06 PM, Matthew Toseland <toad at amphibian.dyndns.org > wrote: > Okay, we've clearly gone off in different directions. > > not necessarily, i think i just didn't fully understand what you were proposing, which made we talk about irrelevant things. > > To address your question first: > > A purely in-browser implementation of Freenet is probably possible, with > the cross domain authorisation stuff. On opennet it might work acceptably > while the number of fixed nodes remains much higher than the number of > browser nodes, but adding a lot of very low uptime nodes would definitely be > a problem - and even more so if they have little storage (how much storage > can you access from such an application?) On darknet it would be even worse: > Freenet in darknet mode only routes through your friends, and possibly > friends of friends. This means they have to be online at the same time as > you are. > > Also IP address detection might be a pain, depending on security settings. > > I take it there is no way to circumvent the uptime requirement? Freenet in > a browser would only run for as long as a browser window was open with > Freenet on it. And it certainly wouldn't run when the browser wasn't > running. > > If opennet has a long-term future it might be worth thinking about, but > even then the uptime would be a problem. If as I believe currently opennet > has no future it is pointless. > > ok, i think we can agree we don't want to run freenet nodes inside browsers. my thought of offering freenet as an unhosted service is also pointless, because if you have, say, a freedombox, or a commodity host, running freenet for you, then you might as well point your browser straight at it instead of pointinf your browser at some intermediate unhosted web app, which then connects to it through cross-origin ajax. So let's skip to the other chain of thought. > > To answer my own chain of thought: > > Currently Freenet cannot allow any Javascript whatsoever. The hardest to > deal with reason for this is that if a browser app can fetch Freenet keys > and time them, and then upload what it finds out, it can compromise the > user. For instance, it could try to work out where on the keyspace the user > is by trying fetches of different keys, and it could try to identify what > chat boards the user uses, what users they trust, and possibly even their > own identity, by downloading messages from them. Likewise with freesites > (freenet-hosted websites). Put all this data together and you have a > detailed profile of a user which is very dangerous. > > I had thought maybe we could avoid this by only allowing javascript apps to > fetch data from per-user and possibly per-app stores, and possibly requiring > that the user explicitly authorise each contact. > > However, on further analysis, any Javascript app will be able to open pages > in new windows, frames, images etc, and will be able to time these fetches. > If it can't that's not going to be very useful! We could limit it to some > small amount of resources from its own site but it would limit functionality > and cause other problems, and wouldn't entirely solve the problem ... > yes, if you start allowing javascript, there is no telling what people could put in there in terms of identity phishing so to speak. also, keep in mind that unhosted is nothing more than a browser trick. it's a trick to do something with your browser that would normally require you to install a desktop app or at least a browser plugin. in freenet, you might not need to use this trick, since you have a 'proxy' between the user's browser and the content. whatever decentralization and encryption tricks unhosted could do inside the browser, can be done much more effectively in the freenet node. also, i guess freenet already solve the issues that unhosted could solve (freedom from monopolies). does that make any sense? Cheers Michiel -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110301/bc7f59c9/attachment.html>
