On Sunday 13 Feb 2011 21:30:13 Michiel de Jong wrote: > On Sat, Feb 12, 2011 at 8:32 PM, Matthew Toseland <toad at > amphibian.dyndns.org > > wrote: > > > I wonder if we could build a usable sandbox based on Unhosted principles, > > i.e. an app can download and upload data specific to its user, and can talk > > to other users. We could even provide a confirmation mechanism per-user for > > more paranoid users, which could smoothly integrate into the app's UI if we > > are really good, including CAPTCHA-based introductions ... hmmmm, there > > could be something in this ... might need API changes though, how do you > > deal with introductions now? > > Unhosted only defines that you use 'some' discovery mechanism to find 'some' > user-specific web service. The two user-specific web services we have > defined so far, are a per-user key-value store, in which anyone who the > key-name is able to read its value, and per-user message queues, in which > anyone is able to send a message to anyone. > > Each application can then decide to implement its own concept of friendship > and introductions, and not display any messages from strangers.
The app will need to decide which users' web services to fetch from. > > > Such principles may be valuable to Freenet even if we have to break > > compatibility with Unhosted... Thoughts? > > Right now, we only have one resource discovery mechanism, and that is based > on email addresses. So one big difference between unhosted and freenet right > there is that all data is per-user. There has been talk about > content-addressable resources, for instance for supporting the DHT of > Seeks-project, but it is as yet hard to oversee freeloading problems that > this could bring. > > I think we should be very aware of what we're trying to achieve when we > consider combining unhosted and freenet. I think that would be doing freenet > in the browser, right? I heard of the Veiled project which tried to do > (something like) this two years ago, but it seems that HP have taken down > the link? > http://www.cio.com/article/498566/HP_Researchers_Say_Browser_Based_Veiled_Make_Darknets_a_Snap > > Does anyone know what happened there? What issues did they encounter? We > might learn a lot from them there. We could find out, and see if we can > resume or redo that project, maybe. Okay, we've clearly gone off in different directions. 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. 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 ... > > > 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/20110224/a74f6ad1/attachment.pgp>
