help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: [Help-gnunet] finding files & database management


From: Benjamin Kay
Subject: Fwd: Re: [Help-gnunet] finding files & database management
Date: Fri, 12 Mar 2004 22:31:41 +0000
User-agent: KMail/1.6


----------  Forwarded Message  ----------

Subject: Re: [Help-gnunet] finding files & database management
Date: Friday 12 March 2004 10:24 pm
From: Benjamin Kay <address@hidden>
To: address@hidden

On Friday 12 March 2004 06:55 pm, Krista Bennett wrote:
> Well... I suppose it's possible to automate some sort of external record
> of what you've inserted under various keywords and have it point to the
> top block of the file so that you could continuously reindex that block
> with different keywords. That might be something useful to have.
>
> That's really so hard, methinks; as an aside, the problem with doing
> that is that for the person using such a method, there is then a
> concrete record of content you've inserted. From a "plausible
> deniability" standpoint, you then open yourself up to trouble, as
> there's not only a concrete record of what you've inserted into the
> network, but a pointer to the file itself - if I insert something I
> don't want attributed to me (for example, my dissertation drafts :),
> it's probably not smart for me to intentionally retain a record. It
> doesn't hurt the network, just me, but it's just something to think about.
>
> This isn't a problem for the network in any sense, and I suppose it's no
> different than you keeping track of such stuff on your own.

I don't really care too much about plausible deniability. I encrypt my
harddrive. With that out of the way, records of what I've indexed and how
would be really useful to me. I don't really care about records of what I've
inserted since, if I inserted it instead of indexing it, I may actually be
going for that plausible deniability thingy.

> As I said above, unless I'm forgetting something vital, it could be made
> possible to add to the keyword list given a reference to the top block.
>
> Now, to actually "modify" the description, that's a bit more of a
> problem, and that has something to do with the censorship-resistant
> nature of the network. If I insert the same file 100 times under the
> same keyword, given that the filename of the highest block in the
> content tree is a function of the keyword, it should overwrite my local
> copy of that top block.
>
> (Is that right Christian, or did you and Igor do something tricky and
> new I'm forgetting about?)
>
> So in that case, you can "modify" the description by reinserting the top
> block with the same keyword as before but a different description as
> long as the only copy of that block is on your machine.
>
> On the other hand, if that keyword block has migrated for any reason,
> you can't do a darned thing about the already existing keyword blocks
> that are out on the network. Nor should you be able to; if I insert my
> dissertation under the keywords "Kristas_dissertation" and the
> description "Draft copy of dissertation on stuff and things - do not
> take internally without consulting a physician", I don't particularly
> want anyone else to go through the network and change the description to
> "Important government dossier on weapons of mass destruction - use in
> government press briefings" for every single keyword block out there. So
> once it's out in the network, it stays there until more important
> content comes along and it fades away.
> So, again, the short answer is that it could be done by just
> "reinserting" the top block alone with a new keyword or description, but
> if that top block has migrated, you're stuck with the two versions in
> the network.

Of course. But modifying the description could be beneficial to users who see
the description off of my node or off of a node that migrated the content
after the description change.

> Unless you keep this externally (i.e. you keep a record of every keyword
> you've indexed) somehow, no; again, this is intentional. Part of what
> makes the AFS portion of GNUnet work is that you retain plausible
> deniability; this means that if someone goes to your machine and says
> "hey, we're going to confiscate your machine, search it, and destroy it
> because you have nude pictures of Dick Cheney on it", you can honestly
> say you had no way of knowing they were there short of brute force
> searching for nude pictures of Dick Cheney. (??!??!!)
>
> Furthermore, all of the blocks you've got stored look the same to
> GNUnet, keyword-indexed or not, so unless you have the keywords
> somewhere, you can't do a reverse-lookup.

Ugh! I can't even see the keywords/descriptions on indexed files? It did
 occur to me that if I keep a list of all files I've indexed (which GNUnet
 does for me) and if I put the filename as one of the keywords (which
 libextractor does for me) then I can see the description by searching GNUnet
 for the filename. But I don't think that will show me the keyword. Is there
 a way to see the keywords if you, say, have the URI of the file you're
 looking for (as this would solve the problem)?

> > Along the same lines, is there a way to reindex a downloaded file
> > without, well... reindexing it? I'm guessing that on nodes with content
> > migration enabled, downloaded content gets inserted into the migration
> > database. Perhaps there is a way to make it permanent on that node (index
> > it) without wasting all that time manually reindexing it? And is it
> > possible to reindex such files under their original descriptions and
> > keywords?
>
> Hrm... I'll let Christian handle that one. I'm probably just not parsing
> your question the way you intend it :)
>
> I've probably confused you more than I've helped, but the case
> sensitivity thing and having some sort of external indexing utility
> sound like plausible (and fairly easy-to-implement) features to me. If
> I'm feeling ambitious this afternoon, maybe I'll even do something about
> it.

OK. I'll clarify. I download a file. I have content migration enabled. So
 when I downloaded that file, there's an awfully good chance it got inserted
 into my node as migrated content. If that's the case, it would be really
 nice to be able to tell GNUnet to reindex the file (so it doesn't fall off
 my node and so I have a record of it) without wasting all that time indexing
 it manually and making up new keywords.

And the million dollar question: how to I get GNUnet to overwrite that first
index block in the database (as this seems to be how descriptions and
keywords may be modifyed)?

Thanks for your help,
-Benjamin Kay

-------------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]