On Friday 05 June 2009 17:53:28 Juiceman wrote: > On Fri, Jun 5, 2009 at 10:20 AM, Matthew > Toseland<toad at amphibian.dyndns.org> wrote: > > 9. Inserts of data which is not predictable by an attacker should be > > encouraged, where this is reasonably possible. There are strong arguments > > that the need to heal splitfiles is critical to good performance. Hopefully > > this will be reduced when we have Bloom filter sharing. If an insert is > > indistinguishable, there is a good chance of its remaining reasonably > > anonymous, even on opennet; bursts are a threat, and can perhaps be covered > > relatively easily. In traffic terms, an insert is similar to an answered > > request, unless you can trace it across the network and show that it is > > longer than a request. So at normal or higher, unless the user overrides a > > specific setting, we should seriously consider severely limiting the > > bandwidth usage of inserts. In practice, we already do this, by treating > > our inserts just like any other requests from any other peer. > > I think MHK's will greatly improve splitfile reliability. Any chance > this can make it into 0.7.5?
No. > > > > > 10. Favouritism: How much can we prefer our own requests to others, in > > terms of what is feasible for the network as a whole, and in terms of what > > is safe? At the moment, we don't favour our requests at all, except that we > > generally take into account the fact that they won't generate any output > > usage (which can be a big factor, since usually input bandwidth is way less > > than output bandwidth). IMHO this is an open question. If we favour our own > > requests too much, opennet peers will drop us, darknet peers will refuse to > > answer our requests by reciprocity for us not answering theirs (assuming we > > implement this, which imho is a good idea eventually), and peers we do have > > will know our requests are local. IMHO the above reasoning does allow for > > us to use excess capacity for our own requests, this is bursting; in other > > words, as a starting point, if there are requests to send from other peers > > and local requests to send we treat them equally (implying for example that > > we don't consider far more of our queued requests than theirs), but if > > there are no requests to send and there is the capacity to send some more, > > we can send our local requests, unless we are on darknet, doing a > > non-identifiable insert, and are very worried about our security. > > > > DOCUMENTATION/ATTITUDE/GOALS CHANGES: > > > > 1. Opennet security sucks. Really, it does. It may be better than some of > > the alternatives, but it isn't vastly better. But IMHO we have the > > potential to achieve fairly interesting performance on opennet - not > > instant results, but fairly good throughput and reachability for rarer > > content. > > 2. Unpredictable inserts can be reasonably secure even on opennet, provided > > precautions are taken and the attacker isn't too powerful. > > 3. It is a good idea to have stuff downloading constantly, although > > downloading stuff you don't need will slow down the network at large. > > Would a list of keys we've transferred (either requested or forwarded > for a peer) in the past "x" hours and randomly re-requesting some > during periods of low downloads help to disguise traffic? Perhaps, but at a performance cost, especially given the below. > > For that matter, perhaps a queue for splitfile healing that inserts > random healing CHKs, or do we already do this? We do insert a lot of healed CHKs. > > > Bloom filter changes mean it won't be cached on your node, but it > will be cached by reasonably nearby nodes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090605/440e36dc/attachment.pgp>
