[GNUnet-developers] AGPL is up to us, says RMS

[carlo von lynX]

It is up to us to decide whether we want GNUnet to be easily 
abusable like Android, or offer at least Affero style protection 
to its users. I raised the worry and Christian first asked RMS 
for an opinion before we'd bring it here. After some debate, RMS 
concluded that he'll leave it to us to decide as we are the
experts on the advantages vs the disadvantages of AGPL applied
to GNUnet, while he says no obvious hindrance.

The threat scenario is as follows: imagine we do indeed establish
a secure mail system (pEp) or an entire distributed social network
(secushare) running over GNUnet, and indeed start nibbling at
Google's or Facebook's leadership in the respective areas.

For purveyors of insecure devices such as iPhones, Windozes and
many Androids it would make sense to offer access to the big new
social networking hype via the cloud. pEp's or secushare's effort
would be seriously damaged if the fastest user experience of
GNUnet comes Google-branded.

Imagine if encrypted telephony like provided by gnunet-conversation
ends up being a thing that is included into Siri. "Siri, call up
Christian Grothoff." Christian would have no way to know that the
gnunet-conversation is actually being gatewayed in the cloud and
all of the communication is going directly into XKEYSCORE.

If cloud-based gnunet nodes are obliged to provide a link to
their actual source code, we can devise ways to exclude them from
the network and disincentivate SaaS business models. If they do
use vanilla gnunet codebases indistinguishable from legitimate
nodes, we can devise ways that proprietary apps cannot be inter-
faced with gnunet.

Christian had a technical worry, that it would be troublesome
for each GNUnet node to offer a download of its source code. But
the license text actually speaks of *users* of that GNUnet node. The
"Corresponding Source" does not need to be advertised to surveillance
authorities, ISPs or other by-standers. It also does not need to be
shared with GNUnet nodes that we don't trust, since we are not letting
them use us. It only needs to be "prominently offered" once we intend
to communicate with a node and let its users use us, maybe because we
want to reach out for a specific person on it.

This is interesting for the DHT use case for example. If a gnunet node
is being used exclusively for DHT lookups, then we don't need to share
our source code with that node since there is no user on that node
using us. That node however must share its source code string with us,
since we have a user who is making that DHT lookup.

I would assume that once a trust relationship has been established to
consider an outside entity a "user" rather than malware, the node can
then offer an http or gnunet-fs link to the respective source code
implementation in form of a simple text string on the suitable network
layer. The hash code is sufficient to obtain the correct source. AGPL
does not require each device to provide the files physically itself.

In the case of secushare, that could be very high: after the negotiation
of a "friendship" (or generally, the authentication of somebody being a
specific human). Only then contacts begin to legitimately be "users" of
a contact's node.

In the case of several other gnunet services, people may need to be
considered "users" even if they anonymously make use of routing or
file sharing services, so the source code identificator string would
become available once it is likely there is a "user" and we intend to
offer services to them.

So the ideal placement of this feature may even vary according to the
choice of services being run. Should the distributed social network
become all-encompassing, then we simply do not need to offer anonymous
services to strangers, bots and malware. We can offer anonymous
services to known humans instead. Not all interactions among gnunet 
nodes do however qualify as "users using services". Things like network
size estimation are automatic and excempt from the AGPL requirement.
We can declare that some protocols are NOT intended for users to
actively use but rather intended to do their job automatically.
Revocation is an obvious candidate for that.

Surveillance authorities can be assumed to participate. They can
find out which versions are running on the DHT. They can request version
strings from inbetween nodes in a CADET circuit whenever they are
granted a circuit to somewhere. They can however be banned from the
network by the logics of game theory that you implemented in gnunet-fs
and such. And they can be refused the version string of a node that
isn't accepting their CADET connection, for example if it is a private
person's node and the authority doesn't know the shared secret needed
to establish the circuit.

So what is an accurate threat evaluation here? Authorities can scan 
backbone nodes for source code versions. They can not do so with end
user nodes. Also, it isn't obvious to me if authorities can correlate
node version strings with physical IP traffic – would they actually
be able to draw a picture of gnunet nodes if only a subset of them
has a known IP number?

I am of the impression that the danger of experiencing a google
gnunet cloud is a much greater threat than having some heavy duty
backend servers expose their version strings.

If the person you are trying to reach out for is sitting with her
smartphone in my dining room, I am fine that your CADET may pick
a route passing through *my* smartphone. But if you're an authority
scanning the network, you shouldn't even know of our smartphones.
Imagine a GNUnet with a billion participants. Isn't it reasonable
to expect that "user" nodes on the edges of the routable universe
will become less likely to be selected for CADET routing, or is it
something that we have to code later?

In any case, after the analysis so far I would highly recommend
to switch to Affero GPL ASAP to disincentivate the SaaS-ification
of GNUnet later in human history and instead start discussing the
possibility of a RAGPL (Reproducible AGPL) or a DGPL (Distributed
GPL).

"Reproducible" means a legal requirement for all binaries derived
from the code to be deterministically reproducible from source 
code, this way creating a technical and legal hindrance to 
shipping binary backdoors via Linux distributors, Google Android
and others. I brought this up at the FSFE anniversary celebrations
and I think it sparked some discussion there.

Keep rocking the CADET, folks.

Btw, secushare prototype in the making!


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/