On Tuesday 01 Mar 2011 17:44:33 Michiel de Jong wrote: > 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.
Right. Unless there is a way to provided a restricted API that is useful and yet doesn't allow most of the dirty tricks. Which might be possible, and would likely be based on identities. > > 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. Hmmm, true... > > also, i guess freenet already solve the issues that unhosted could solve > (freedom from monopolies). > > does that make any sense? Yeah. Thanks. > > Cheers > Michiel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110304/b3f3588f/attachment.pgp>
