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

[LRN]

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).

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org

0x6759BA74.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature