-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Toseland schrieb:
> On Wednesday 23 January 2008 23:41, Michael T?nzer wrote:
>> Please see the following discussion:
>>
> http://archives.freenetproject.org/thread/20080115.204804.97aa6904.en.html#20080115.204804.97aa6904
>> David Sowder schrieb:
>>> The node should do it's own tests first and then ask the user.  The node
>>> has a pretty good idea if it is externally accessible.
>> That is the easy to do stuff, but can't be determined on "install time",
>> therefore we should do it in the config page, maybe we could do an
>> useralert in the way "Your node has detected, that it meets the
>> requirements for a seednode. More information on becoming a Seednode can
>> be found at ${link}. Would you like to become a seednode? [Yes] [No]
> 
> Is it important to not ask the user if they're not eligible? We can always 
> ask 
> them and then not include ourselves because we're not.

That is probably the better solution, but that's not the hard problem to
solve. The main point is, we can know whether we're eligible. How we
implement the option whether to act as a seednode is irrelevant if we
don't have a solution to our main problem: the harvesting itself.

>>> The seednodes.fref file should probably some random subset of the total
>>> pool, once we have a auto-harvesting, possibly giving the same client
>>> the same random subset for some period of time.  The entries in
>>> seednodes.fref should probably auto-expire after some time period, once
>>> we have auto-harvesting, relying on the seednodes themselves to
>>> "re-announce" to the central location.
>> If we give away just a subset of the database, we have to make 100% sure
>> that at least 5 of the Seednodes on the subset are up and working.
>> There is also no way of keeping an attacker from requesting the subset
>> more than once in order to get an almost complete list.
> 
> Except by only giving the same 20 nodes to the same IP address? Of course the 
> problem with this is what if some of them aren't working?

If we always give the same 20 we still have to make sure that at least 5
of them are working. And AFAICS it's not possible to effectively limit
it to one computer (we probably don't want to limit it to one IP because
that can easily cheat by reconnecting and getting a new IP (most ISPs
allow that) or if it is a more powerfull attacker just use another IP in
our pool - and if we are a normal user and there are no 5 working
seednodes on our subset, we can't easily get another subset and will get
annoyed --> uninstall freenet).

So if we want to limit the given refs to a subset of our database, we
have to ensure, that they are working. These checks are expensive. And
as there are ways to cheat this subset thingy, we could just globally
limit the seednode.fref to a subset of our database, so there's no way
for attackers to cheat on it (you can't get another subset) and we don't
have to make the expensive checks that often. This is exactly what I
described in my proposal (well, one of the corrections of it).

regards
Neo at NHNG
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmMZNPUBAMhFf+J4RAskEAKCmk+ftZEdQQmKQSPC+E5F4CbSgSQCdGQvl
CYybZhuj4T0daiUeeuevhEo=
=ymLD
-----END PGP SIGNATURE-----

Reply via email to