carlo von lynX transcribed 9.1K bytes: > 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/ > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
Okay, since no one replied so far: I share the concerns and my wishful license is one where the sourcecode must additionally be reproducible. Even though I commited very little in core code, but more on the system side and currently in fixing up the documentation: I support the change to AGPL3. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
