I'd like to summarize some recent points from this thread that I think
are very important, just to confirm my understanding:

1) Sending content type (and other kinds of content-describing metadata)
in the clear would allow strategies of traffic analysis that are
contrary to the Freenet philosophy.  IOW, one could see that Bob is
looking at lots of porn or that Alice is trafficking heavily in MP3s.  I
agree wholeheartedly with this point and I'm glad it was raised.

2) Storing metadata separately from the data it describes doesn't work
very well, because the metadata could/would end up on different servers
and have different patterns of access, so most of the time you'd end up
in a situation where either the metadata or the data would be present,
but not the other.  And it would also be inefficient: two
requests/inserts where there should be one.

I'd like to add:
3) Stuffing metadata in the trailing segment leads to a data reuse
problem.  If my client dumps a bunch of extra headerish-type fields in
front of the actual data, no other client can use that data unless it
understands those headers too.

I see a few solutions to these problems:
A) Standardize a format for metadata in the trailing segment.  To quote
Brandon:
>
> I think the format for the information in the trailing field should be
> just like in a message, that is fields following by a trailing field.
>
That sounds good to me; the only thing clients would have to understand
is where the real data begins.

B) Encrypt important metadata in some way and put it in Storable fields
in the real header.  Perhaps based on the original key, so seeing the
hashed key wouldn't be enough to decrypt the metadata, but anyone with
the real key could do it (forgive me if that's not good enough, I'm no
cryptologist).

C) Define a separate header section (someone used the unappealing phrase
"body-header" earlier) that's encrypted somehow, but distinct from the
trailing segment, so nodes can deal with it independently of the
trailing segment.

The advantage of methods B and C is that they would support a
header-only request, whereas A could not, because the metadata would be
in the trailing segment which can't/shouldn't be looked into by nodes.



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

Reply via email to