On Jan 16, 2009, at 2:43 PM, Volodya wrote:
Robert Hailey wrote:
On Jan 15, 2009, at 4:47 PM, Matthew Toseland wrote:
Why would we want to route the request to a node that isn't optimal
for the
key? And anything that probes for the existence of a key obviously
is bad.
Forgive my ignorance, but why is any kind of probing obviously bad?
My whole point is that we probe (maybe two or three) peers to find
out
the optimal path, and pick the one with the least latency for a
realtime
request.
If a node receives such a request, and it has it in it's datastore,
the
latency is transfer time, otherwise it is the (best) downstream time
plus transfer time. In either case you add to the time-claim that
time
expected to finish other realtime requests queued in front of it.
I think toad_ is talking about privacy considerations here. Somebody
can use
this to prove the datastore of a sigle peer. However, i don't
understand what is
the different between this and actually requesting the data and
measuring the
time yourself for the attacker. If there isn't any difference then
there is no
*extra* problem.
- Volodya
Remarkable... that makes it seem like "slowness=privacy" &
"freenet=slow"...
But in thinking about it... it actually makes it more secure in that
sense, because the remainder of the request would be 'streamed'
through several nodes as usual, so the best an attacker could
determine by a latencyEstimate()~=linkSpeed() is that the requested
node either has it in it's datastore OR has a bandwidth to peers
higher than yours OR has at least one good peer with a clear low-
latency queue.
What's more, if a node was sufficiently busy-enough to have an
attacker be able to measure it's latency estimate between datastore
and remote requests, then surely it would also be busy enough to have
multiple lowlatency requests therefore confounding that measurement
(making datastore requests look remote, I might add).
Or if a node was sufficiently idle for an attacker to be able to "feel
out" requests to various uris, adding a small random latency (average
link to a peer), would both easily confound that and might buy our
node props for getting requests ahead of schedule.
--
Robert Hailey
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
