--- Martin Stone Davis <[EMAIL PROTECTED]> wrote: <big snip>>
I'm having a lot of trouble coming up with a good solution. Thoughts?
Here are some:
1) For your own personal requests your node could cache at 100% in a special cache which isn't
used to handle other people's requests, but pcache your own requests in the public one just like
normal.
This opens you up to securtiy issues, if your drive is compromised, but these could be dealt with "loopback crypto" or an extension of fred which would ensure the stores contents would be lost if the machine looses power (or maybe require a passphrase to restart).
Given that my local store allocation is large enough that pcacheing has not been triggered, is this any different from my solution #1 (which I discredited)? Even if the drive is not compromised, it suffers from the same problem that solution #2 suffers, as I showed in my hypothetical.
2) There's an ongoing arguement about maybe caching with a higher probablity things in your spec. This may protect against some timing attacks since:>
a) I'll have reason to request and cache such data anyway, if it's in my spec.
b) I'll have an excuse to throw away such data quickly if it's outside my spec.
Not sure how that works exactly, but again, if my store allocation is so large that my pcacheing is nowhere near being triggered, wouldn't that be no different from what we have today? Maybe I completely misunderstand what you are saying here. Please explain.
3) Don't run such "SLUTY" nodes that do it with everyone. If you connect only to people you haveHmm. Interesting. But how do you build "real trust" in a way that neither the RIAA nor AAIR could fake trustworthiness?
real trust in and they do the same, you'll be pretty safe. Of coarse doing this is some work, and
one mole could compromise his neighbors.
Freenet's topology must be like a random graph or small world; this is thought to be true of social networks which should give rise to such trust based nets. However, that's all theory and no practice as far as I know.
Yes, that would certainly strengthen inserter/requestor anonymity at the time of insertion/requesting, but doesn't it still allow for probing the DS?4) Inserter/requestor anonymity can be improved with another layer of onion style routing. For example I pick n nodes, I build a chain up only talking to the first one. Each node gets a symetric key and the last node acts as my proxy for insertion an deletion. In order for them to link it to me all n nodes have to be compromised.
You can improve this buy making a few of these chains and using each one for a particular peice of hashspace and connecting them to nodes which might be specailized in the area (or let them become so).
I believe Toad mentioned doing this for maybe just two hops or so.
Agreed.
Yes Brandon is right; we need to focus on getting the system working well first. But this is good stuff to think about.
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
