On Wed, 2009-06-10 at 14:55 -0400, Matt Lee wrote:
> Ted Smith wrote:
> 
> > I think that it isn't libre.fm's responsibility to enforce user
> > security. Only the user can make themselves secure or anonymous;
> > attempting to transparently do so will inevitably fail because anonymity
> > and security require work.
> 
> We have a responsibility to do everything we can to not attract subpoenas.
> 
Well, not everything, everything possible or within reason. If you
really want 0% chance of getting subpoenaed, then run the whole thing as
a Tor hidden service and go underground so as to be untraceable. ;-)

Yes, libre.fm has a responsibility to do everything they can to ensure
security and privacy, but again, the nature of a scrobble-ing site means
that every time a user scrobbles, they are reducing their anonymity set.
We can't eat our cake and have it too.
> > In that light I propose that libre.fm listen on the public internet and
> > also through a Tor hidden service (or, to reduce latencies, run a Tor
> > server with a restrictive exit policy that will allow for torified
> > requests to libre.fm to exit the Tor network on libre.fm's node). 
> 
> I don't want to run a Tor node. How else could we do this? Nothing
> stopping people connecting to Libre.fm via Tor.

No, but then if libre.fm is subpoenaed, the MAFIAA will just go after
the Tor node operator (most likely). This way, libre.fm's logs just have
entries from localhost whenever the site is accessed by a Tor user.

There are two ways you can get this result. One is by running a Tor
Hidden Service, and one is by running a specially configured Tor node.

A hidden service is just a Tor client that has a set of standing Tor
circuits that allow for inbound communication. The positive aspect of
this is that we don't have to run a Tor node -- we're only handling our
own traffic. The negative is that this is far more taxing on the Tor
network, since a fully hidden service section involves 12 nodes (versus
four for the other configuration).

The other approach lies in the fact that if a user requests a Tor
circuit to be built with a given endpoint, and the Tor client detects
that that endpoint is running a Tor server, Tor will extend that circuit
from the default three hops to four hops, terminating it on the endpoint
itself. This is better for the Tor network by far, since the node will
function (in whatever configured capacity) as a middleman node. I'm not
sure if it's necessary to configure the endpoint node as a Tor exit, bu
if it is, the exit policy can just disallow anything other than libre.fm
and related servers. 

A single Tor installation can do both of these things simultaneously,
though there isn't much reason to do that.
> 
> > In this case, the onus is on the user for keeping the datastream clean
> > of identifying information (this is a hard thing to do, especially given
> > the concept of "friends" and the fact that libre.fm by nature reduces
> > the anonymity set over time), but assuming they do so, there is nothing
> > that libre.fm can do to produce their identity. All their scrobbles will
> > originate at localhost as far as libre.fm is concerned, and so that,
> > along with whatever other user data they give, is all that could be
> > handed over in the event of a subpoena.
> 
> If we have their email address, their homepage URL, etc... we'd have to
> give all that over as well.
> 
Yes, but if the user is privacy-minded, they won't give you that. If the
user isn't privacy-minded, we can't help them -- privacy measures will
just drive them away.

If they are, however, we can tailor the defaults, the things we ask for,
etc., for that. For instance, if we detect that a user is coming from
the Libre.fm Tor Interface or from a Tor Exit node, we can change the
things required in registration or stored by the site, remove
client-side executing code, stay in HTTPS the whole time, or whatever
else.

> > This has the added effect of making it easy to tell whether or not a
> > user is taking advantage of anonymity software, and so segmenting the
> > userbase into those that noticeably care about their privacy and those
> > that care less. This means that the defaults for accounts created on
> > this interface can be much more locked-down that the defaults for
> > accounts created on the www interface. Also, it would mean that libre.fm
> > would be the first social networking site with a strong commitment to
> > user privacy through anonymity software.
> 
> I think we should make the strong privacy the default for everyone.

People on this list have made clear that strong privacy isn't what they
want. That's completely natural, because security = usability^-1 and
privacy is just another type of security. Personally, I would rather
have libre.fm have my email address / homepage / real name, because I
don't see the point in hiding it if there are other means of getting
that information. If I wanted to be anonymous, I would set up an account
via Tor (and I'd feel _very_ good about doing that if the provider
tailored the experience to that), and if I wanted my data to be private,
I'd run my own instance.

We should definitely make strong privacy accessible for anyone who wants
it -- that's one of the reasons why Tor is such a good solution, because
it completely anonymizes the transport layer as well as whatever else we
do once the user is logged in. All of these other solutions, blocking
unpublished albums, marking them private, not storing email addresses,
etc., are worthless if the user is on a network the MAFIAA has a tap on
(like many American universities, now, or France). If we direct users
who want more privacy through Tor, and encourage its use, we're covering
that and making it clear that libre.fm has a strong commitment to _user_
privacy, not just protecting itself from subpoenas. Whatever privacy
changes to the UI there are should definitely be accessible from either
the www or from Tor, but users that want privacy should be made aware of
the security theater inherent in doing a lot of things on the server
side... but keeping the network traffic itself vulnerable.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Libre-fm mailing list
[email protected]
http://lists.autonomo.us/mailman/listinfo/libre-fm

Reply via email to