> Date: Mon, 21 Aug 2000 22:15:15 -0500 > Subject: Re: [Freenet-dev] A clear point by point comparison of the metadata > formats > From: "Scott G. Miller" <scgmille at indiana.edu> > > > Why is this an issue? > > Why even separate private data into metadata and data? > Because it allows for complicated metadata to be retrieved separately from > the data for speed. For example, you can 'stat' a freenet file by issuing > a request for the metadata only section of a document. The node returns > only "Metadata-length" bytes of the document.
So the question is (using the example of a redirect message): On a metadata "stat" request, do we want the client to redirect the metadata request to the actual redirect-referenced location or just get the metadata from the redirect? If we want the client to redirect the stat then the redirector belongs in the stat-reply (aka metadata section, tigglytops section (or something like that), etc.). If we don't want it to redirect the stat then the redirector belongs in the non-returned "data" section of the message. On a stat, we are guaranteed to get back metadata. Whether or not it is in the agreed-upon FNP style all depends on how well behaved the inserting clients were when sticking things in there in the first place. There is nothing stopping other "unofficial" clients from setting metadata-length==data-length but not using FNP (with good or bad intentions). Good programming practice would be able to handle this properly. This entails some validity checking of the returned metadata to see what format it is in rather than parsing it *assuming* it was FNP because those two values were the same. On another note ... what validity checks for the stat-reply is there? Can an intermediate node swap the contents of the encrypted stat-reply or is a signature being generated on just the metadata portion too? I know that this stuff will still be encrypted but it should have the same protections as the rest of the data. An evil node swapping redirects with knowledge of the encryption key could cause some havok (not to mention redirect requests to keys it knows its node is close too) Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
