> Updatable keys are a security vunerability. If someone's key is
> compromized, their original content can be removed by updating the content
> with a "hacked by foo" message in its place.
let me be very blunt: if your key is comprimised, your are already quite
fucked on the current network. seriously.
here is my esseitial problem with time replacement keys in 25 words or
less: the "time" part. I don't know how often I'm going to update my
site, if I did, I'd just use a DBR.
this being said, your idea does have some merit, not the least of which is
that you can do it without any changes to FNP.
> Also, how does the fact that this "defeats the purpose of implenting
> updatable keys" make it "no better than most of the ideas going around for
> editions right now"?
I am forced to assume that you incorrectly phrased the question. either
that, or you havn't tried to run a freesite ;). But I will answer it with
aquestion:
what's different about TRK's to progressivly checking each previous time
periods DBR url if today's isn't found?
> Good updating needs several qualities:
>
> 1. Minimal requests (preferably no more than 2: redirect and data)
agreed
> 2. Minimal request length (requests that must go the full HTL are
> undeseriable)
agreed, at least for browsing, and provisionally agreed for FNP traffic
internally.
> 3. No "maintenace" or broadcast requests (they just waste network bandwidth)
I'd like to avoid this, but reality has a funy way of, well, getting in
the way of what I want to see ;)
> 4. Granular update interval
a granular update interval is exactly what we want to avoid!
> 5. Persistence of old data (for security reasons)
this is an interesting point, although I don't believe that the reason is
security reasons - like i said above, if your key is comprimised, you are
already fucked while freenet has no key revokation.
(someone one suggested to me that if someone inserted a key called
'.revoke', and fred/fproxy checked for that, that'd do it, but it can't be
that simple :-p)
> 6. Ability to find the most recent version of a site if it isn't maintained.
this is, indeed, the whole point
> 7. Works well with both popular and unpopular sites
yeah, this one is important.
> So here's a comparison:
>
> 1. Updatable Keys and regular editions only need 1 request, while DBRs and
> TRKs need 2. No big difference here, although regular editions need to do a
> lot of requests to find the most recent version.
>
> 2. Updatable Keys fall short on this (at least all the ideas i've seen).
> TRKs only go the full HTL if the author has not updated their content after
> the time they said they would.
like i said, the big issue is that I don't know how often i'm going to
update - remember that you would have to keep requesting over and over if
I don't insert the site each day, because if I *did* insert, it will take
some time and many people requesting to propagate to your part of the
network anyhow.
my question above about DBR's with auto-old-retrieve vs. TRK's is relevent
here.
> 3. All of the good ideas i've seen for updating don't need maintenance or
> broadcast requests. This is probably because any idea that does need them
> is a bad one.
so 'idea that needs maintenance' is always bad in your world. i believe
you said that already ;).
> 4. Updatable Keys and regular editions can update whenever they want. DBRs
> are required to update at specific intervals. With TRKs, the interval can
> be changed, and the author can specify a 0-time interval so that it always
> gets the most recent content (although this would make requests suffer from
> problem #2)
. o O ( or fred could just get the old DBRs progressivly until it finds
one, and we're at the same point, no? )
> 5. Updatable Keys get iffy at this. Some people want to do away with the
> old version while other people want to keep them. I think that the network
> should be left up to decide wether or not to keep the old data.
insert your the keys you want in your keyspace. my keyspace is mine.
> 7. Some updatable key ideas have a problem with this. DBRs have a problem
> with it too because single-day keys that are still pointing to old data
> don't get a good foothold in freenet for unpopular sites. Regular editions
> and TRKs improve reliability over time. (Although TRKs will take longer if
> it's past the last estimated update time, they will still be reliable)
ironically, i have far, far, far more luck getting DBR sites which
*havn't* changed, that is, pointing to old data, than DBR sites which
change.
> So the only problem with TRKs that they really suffer with is #2, but even
> then they only do a full request until after the estimate update time.
i think you severly underestimate this problem.
- from fish with love
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
