Lars Weber ([EMAIL PROTECTED]) said: > mike burrell <[EMAIL PROTECTED]> wrote: > > anyway, i was thinking further about how to regain this "plausible > > deniability". unfortunately Hurd doesn't offer namespaces a la Plan9, as > > that would make things easier. i guess you could just have the Freenet > > translator run as its own user, and run the data store with o-r (but still > > o+w and o+x) permissions. i don't know if "it would be kind of annoying to > > change the permissions" would count as "plausible deniability" in the legal > > sense :), but i'm sure paranoid people (or people living in China, etc. for > > that matter) could figure something out. > > If the freenet system itself allows content in the datacache to be > identified then a freenet translator should IMHO simply allow listings, > too. If there is a problem with this then I don't think it's the > translators authors job to fix.
yes, from a technical stand-point, the best solution would be to just provide clear listings of the datastore. even with the current "reference" implementation of Fred, one can obtain a listing via a dictionary attack (it's a bit of work, but it is do-able). from a legal stand-point, though, some people might not like that. of course different translators could be used in conjunction with the Freenet translator so to obfuscate the datastore from other processes (if that's what the user wants). i'm not sure there are even any lawyers on the Freenet project, though, so all this worrying about legal "plausible deniability" could be misplaced :). > > anyway, it all kind of fits into my philosophy i guess. for a while people > > have realized that not all forms of code re-use can be implemented > > practically with pipes (and even shared memory to a point). "components" a > > la CORBA seemed a bit ugly, as they're kind of opaque to the user (which > > makes them not as flexible as they could be) and vaguely un-Unix-like. i > > figure if lots of stuff gets exported to virtual filesystems, though, we get > > all the benefits of code re-use, and plus get to continue on working in > > traditional Unix form :). > > After thinking this over from scratch again it really starts to make > sense. Until now I've mostly seen translators as useful from an end users > point of view only, but seeing it your way a http-translator (caching or > not) would also seamlessly integrate into and extend the development > platform itself. well, especially in the land of Unix, the line between user and developer is sometimes fuzzy. plus, code re-use saves on hard-drive space and RAM-space, which is definitely pro-user ;) > As for caching, maybe it would be possible to provide the networking and > the caching functionality by different translators. This way the httpfs- > and ftpfs-translators would simply use a cachefs-translator for caching. > (And maybe even a freenet translator could simply use cachefs to manage > it's datacache!?) There might pop up other uses for a cachefs in the > future, but I don't know if there can be several translators on the same > node. several translators on the same node would be immensely useful, especially if you could sort of 'pipe' a node from one translator to another. there are certainly other uses for cachefs (though maybe it would need a different name). one thing i thought of was an FS sort of like Microsoft Windows' Recycle Bin (except much cleaner). instead of 'rm'ing a file, you 'mv' it into a trash directory -- if the trash FS is full, then in it (silently) deletes the oldest file on there. i actually have something kind of like this on my GNU/Linux machine, where i have a crontab entry that deletes the trash daily, but a TrashFS would be much cleaner. of course, anything that caches could make great use of it. but, i think if we were to get this thing working well and quickly, the proper order of operation would be: (1) get squid working under the Hurd (has this even been done yet?) (2) turn it into a translator (3) slowly work at getting it to export a human-usable datacache (4) once that's working, take out squid's conventional non-human-usable datacache (5) work at trying to separate network code from cacheing code and eventually break it into two translators i know that the Hurd (or most of its developers) is more design-focused than implementation-focused, and a clean break between cacheing and networking would be the best design to use, but i'm maybe a bit impatient. and seeing how squid already exists, and works very well, and has decided to lump http, ftp and cacheing code all into one big program, i think that's where development should start. it's the path of least resistance :) anyway, i'll see if i have any time after Christmas. i've got the Hurd installed, but i can't get networking working with it right now ("ls /servers/socket" requires a hard reboot -- not good). once i get some new blank CDR's, i'll get the latest Debian Hurd ISO and re-install it and then see if i can get any useful work done :) -- /"\ m i k e b u r r e l l \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED] X AGAINST HTML MAIL, / \ AND NEWS TOO, dammit _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd