help-gnunet
[Top][All Lists]
Advanced

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

Re: [Help-gnunet] Measures Against Abuse not a topic of FAQ


From: Jan Eichstaedt
Subject: Re: [Help-gnunet] Measures Against Abuse not a topic of FAQ
Date: Wed, 12 Oct 2016 13:29:44 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0

Hello LRN, hello list,

I really appreciate your technical view and, of course, the GNUnet
Project is mostly about technical issues. My question, however should be
seen as an exemption. What some deem an philosophical question really
might define GNUnet's scope.

Even before asking how to prevent inhumane deeds (I avoid the terms good
and bad, when I can, as laid out in the foregoing conversations), the
question is whether or not to prevent inhumane deeds. Your line of
arguments seems to me that if GNUnet's current infrastructure is not
supporting to prevent anything then a discussion about preventing
inhumane deeds is obsolete.

IMHO goals come before means. GNUnet's infrastructure is a means to an
end, too, that must be defined beforehand. Who knows? Perhaps most
contributors of the GNUnet Project choose to not prevent anything from
being done. Only after they have decided to prevent something, it would
become relevant to ask further how to prevent it including to change the
infrastructure.


Best Regards,
Jan


On 10/10/2016 09:23 PM, LRN wrote:
> On 11.10.2016 3:26, Jan Eichstaedt wrote:
>> Dear Stefan,
>>
>> As far as I have read, people here have very different opinions and
>> preferences. I still have no idea about the stance of the majority of
>> the active project members.
>>
>> All the specifics and even the bold idea of a self-government are
>> distracting, because here on the help-gnunet list the objective is
>> simply to find an answer to my initial question. Obviously I'm not the
>> one who can answer this.
>>
> 
> Not a core GNUnet developer, but here's my take on this, from the technical
> standpoint.
> 
> GNUnet is an infrastructure for storing and transferring information. It
> has multiple mechanisms for doing so, the most well-known ones are blocks
> (what is used for actual file-sharing) and DHT (used for many things). The
> following is *mostly* about block transfer mechanism (i'm not very familiar
> with DHT).
> 
> Therefore, GNUnet can only do anything about transferring/storing information.
> 
> A GNUnet node can see information being transferred to/from it, it can do
> that transfer and store that information, or refuse to do so. That's it.
> The power GNUnet nodes have is only related to information, and is limited
> to themselves. One GNUnet node can't affect another GNUnet node directly.
> 
> This can be used for the following:
> 1) Finding who is transferring/storing a particular bit of known information.
> 2) Preventing a particular bit of known information from being
> transferred/stored.
> 
> And both are only possible if GNUnet nodes voluntarily do that (there's no
> central authority that can coerce them into doing that), and, most
> importantly, the "known" word used above means that the information that
> needs finding/stopping must be found out somehow (found out *precisely*,
> you can't do keyword filtering or anything like that), and then
> disseminated among GNUnet nodes that willingly participate in the effort of
> finding/stopping it.
> 
> Thus i see the following problems:
> 1) If information is being transferred in secret, it can't be found out,
> and thus can't be stopped. Secret transfers are perfectly possible and are
> a reasonable technique for some threat models. It requires a number of
> nodes working together and sharing some kind of secret piece of information
> (a hash, a non-trivial keyword) established prior to their communication,
> or have a way to secretly communicate outside of GNUnet.
> As long as all participants keep the secret, the information that they
> transfer can't be decrypted and singled out as something that warrants
> attention.
> 
> 2) If information is found out, then there's the matter of deciding whether
> it should be stopped or whether its source should be identified (which, by
> the way, requires immediate action; if you wait too long, information can
> be spread across the network, and you'll never find the originating node;
> again, a very tight group of conspiring nodes can disseminate information
> through the network in complete secrecy, then make it more widely known;
> this can be countered only by having total surveillance over the network,
> i.e. storing all information transfers on all nodes for later analysis,
> which is expensive and no one will do that for you). Who gets to decide
> that? The best thing i can come up with is a Web of Trust-like model where
> each node gets a censorship list from some other, trusted (actually
> trusted) nodes. This may or may not be done inside GNUnet, i'm not sure.
> 
> 3) Because information must be known precisely for it to be stopped, simply
> salting it will break any attempts at censorship. As long as there's a way
> for the "bad" nodes to find out the new hashes without tipping off the rest
> of the network (or the parts of it that decide what should be censored),
> this is simply an unwinnable game of whack-a-mole (see (1)). Also, this
> will make censorship lists grow exponentially - again, making it
> impractical for participating nodes to censor information. Or the
> censorship lists must be very short-lived.
> 
> As long as "bad" nodes behave themselves, it's not possible to prevent them
> from communicating, because "badness" of information they transfer can only
> be determined when information is decrypted (for which the decrypting node
> must be clued in) and when that information is evaluated by humans (because
> AI does not exist, yet). This is intentional, because "bad" is subjective
> (as pointed out previously on this thread).
> 
> 
> 
> _______________________________________________
> Help-gnunet mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-gnunet
> 




Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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