Ian Clarke wrote:

> I have yet to hear an explanation for what problem so-called "client
> side subspaces" are supposed to address.

Allowing individual users to make policy decision on what they read, as
opposed to publishers making global decisions on what can be
distributed.

> Some months ago I made the snapshot updating scripts insert the latest
> snapshot into Freenet under the key "Freenet-snapshot-DDMMYYYY" where
> DDMMYYYY was the date for the insert.
[...]
> This issue is not addressed by client-side subspaces since someone could
> simply remove the subspace-checking from their Freenet client, and
> insert a fake Freenet snapshot for tomorrow.  While most people (those
> with a normal Freenet client) will be able to request this, it will
> still prevent the Freenet snapshot script from inserting tomorrow's
> correct snapshot.  Because of this the functionality of server-side and
> client-side subspaces are *NOT* the same.  Client-side subspaces are
> open to abuse, and therefore IMHO are not very useful.

I'm not for a moment suggesting we should rely on client-side checking
of insertions.

Yes, you're perfectly correct in stating that keys are guessable in a
client-side subspace.  

Clients would either need to use some form of iterative guessing of
KHKs, or insert & request based on keys which include a signature as
part of the key component.  Again, this comes down to a matter of
efficiency.  Maybe it sucks, I dunno.  Maybe there's a better way of
doing it.  But I'm talking about requirements here, not implementation.

> Wrong, it is not a question of efficiency, it is the simple fact that
> client-side subspaces DO NOT DO WHAT SUBSPACES ARE SUPPOSED TO DO which
> is to protect a subset of Freenet keys from unauthorized insertion of
> data.

This is exactly my point: I think there is some disagreement as to what
subspaces are supposed to do.

IF subspaces are supposed to prevent unauthorised insertion THEN
server-side subspaces are the solution.

IF subspaces are supposed to allow readers to choose their own
moderators THEN client-side subspaces are the solution.

All I'm suggesting is that you decide on the requirements first, then
implement something that meets those requirements. 

-- 
zem at zip.com.au   F289 2BDB 1DA0 F4C4 DC87 EC36 B2E3 4E75 C853 FD93
zem.squidly.org  "..I'm invisible, I'm invisible, I'm invisible.."

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to