On Fri, Oct 27, 2006 at 06:23:09PM +0200, bbackde at googlemail.com wrote: > On 10/27/06, toad <toad at amphibian.dyndns.org> wrote: > > > >So Frost already assigns each file a unique identifier, being its > >SHA-256? Interesting. The purpose being presumably to support multiple > >filenames and MIME types for the same file? I mean, exactly why is it > >beneficial to index them by SHA-256 rather than by key? > > - independency from node and maybe changing CHK keys *g* > - take load from node by computing SHA inside Frost JVM > - SHA computation does not need an expensive encode > - SHA is verifyable with external tools
:) Well, any external keys may not be "clean" CHKs. They might even be files inside containers etc. Although not if they are big files. So if you want to cleanly support externally originated keys you may need to support multiple keys per SHA-256. > > >If you save it, then > >a) You have to figure out the filename. > >b) You have to figure out the MIME type. > >c) You aren't warned when the operating system auto-detects the MIME > >type, launches Adobe Acrobat and reports back to the Bad Guys. > > > >Really, having a MIME type is better. > > > >Having said that, pretty much all filesharing is inherently insecure > >even over Freenet, because most interesting file formats allow for > >web-bugs. :( > > a) is done by Frost, user can choose one of the filenames the uploaders used > b) and c) true, but this is the todays situation for most apps. the > file extension determines the content type. I suppose so - at least on Windows. > I see no need for mime > types there. Except in browser they are not used or remembered > anywhere. Once the file is on your filesystem only the extension and > the content is needed. Correct me if I'm wrong, but at least this is > true for windows. I don't know if ext3 saves any mime type for a > file.... It doesn't at the moment, but desktops often detect by contents, and may save MIME types (as well as thumbnails) in extended attributes or a database in the near future. Having a proper MIME type allows freenet's filtering to work. This is especially nice with HTML downloads. You can queue on the global queue a particularly stubborn freesite, and when it's eventually downloaded (in future it will tell you via an event on the homepage or via an RSS feed or something), you can click on it on the queue page and safely view it. Same with images, audio, video if you have enough temp space (although we don't filter audio/video at present). > > >> For me the download of binaries > >> from freenet is the same as FTP, emule, bittorrent, ... you get a > >> octet stream and thats it. No need for mime types here. For html, yes. > >> Needed because intented to be shown in browser directly... > > > >I'm not convinced of the need for such a sharp dividing line. > > Its no need, but thats the current situation... Well, Freenet already straddles the border between filesharing and web browsing, I suppose that's my point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061027/a9a6d1bf/attachment.pgp>
