On Wednesday 16 April 2008 02:33, Florent Daigni?re wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-15 18:06:02]: > > > Is it better to report actual CHKs, or block numbers? Maybe we should do both? > > We would only need block numbers for selective reinsertion (the next logical > > step), although there isn't really any good reason not to report CHKs. > > > > Heh... are you sure about that ? > > A few months ago you changed "when" the top-level-block is inserted to > make correlation attacks more costy... and here you don't object to a > patch leaking its informations ? The purpose of the patch is clear: they > want to insert "some key others clients can find" containing both "a > description of what is going to be inserted -aka a filename-" and "the > reference to the blocks composing it -their URI" so that other clients > can pre-fetch it. Isn't it all you need to make correlation attacks > possible? You know which file is going to be inserted: provided you've > already got it (which is likely if we are talking of some copyrighted > content and you're running after people infringing your copyright) > you can pre-compute the URI of its blocks and track who is inserting > them.
Hmmm, fair point. I had assumed it was for selective reinsertion. As nextgens points out, it is essential that the blocks not be identifiable before the insert has finished, otherwise an attacker can *dramatically* improve the rate at which he can move towards the original insertor. > > > What about request resuming / finding blocks in the datastore? On starting a > > request, we turn off SimpleProgress notification, because most of the time > > the request is being resumed from the datastore and therefore we would send > > vast numbers of SimpleProgress messages referring to blocks we have already > > downloaded. > > > > This should be dependant on a Verbosity flag. > > > > Also, your diff is empty. This might be a kmail problem on my end though... > > It's a problem on your end. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080416/6d95a6aa/attachment.pgp>
