Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Third-party data sharing leaves discretionary wiggle room #25

Open
mdekstrand opened this issue Aug 24, 2012 · 7 comments
Open

Third-party data sharing leaves discretionary wiggle room #25

mdekstrand opened this issue Aug 24, 2012 · 7 comments
Labels

Comments

@mdekstrand
Copy link

The third-party data sharing, while definitely better than average, leaves discretionary wiggle room that seems unnecessary. In general, I much prefer to see services be on the free-speech and strong privacy ends of various spectra.

Is there a reason why the relevant section of the ToS cannot be replaced by something to the following effect:

App.net will only share your personal information under the following circumstances:

  • With companies and organizations providing services on our behalf (e.g. hosting services...), in the course of using their services.
  • If we are acquired...
  • When we are legally compelled to do so.

The last bullet point sets the bar high - data is only shared with law enforcement, plaintiffs, etc. when it is legally mandatory, e.g. a valid subpoena or warrant - but that's where I think it is best for it to be. I can understand if liability requires it to be a bit lower, but would like to see a good explanation of why that is the case (and have the bar absolutely as high as it can be).

@mdekstrand
Copy link
Author

For an example of a top-notch privacy policy in this respect, see the one for prgmr.com: http://prgmr.com/privacy.txt

@berg
Copy link
Member

berg commented Aug 26, 2012

Would you mind looking at the new privacy policy and determining how best we can fit this into the document?

@mdekstrand
Copy link
Author

New policy is much clearer. Points 2 and 3 are the portions particularly relevant to this concern.

Language like “government request” or “protect … from harm” are red flags for me. The government may make many requests. Perhaps it places too much liability or other legal burden on app.net to try to accurately distinguish the valid and compulsory requests from “because we [the feds] think we can” requests, but I would rather see the service impose strong protections on what little private data it does collect from users. Something to the effect of “to comply with warrants, subpoenas, gov't requests, etc. when we have a good-faith belief that such compliance is required by law” may allow enough room to err on the side of compliance, while still saying that app.net won't turn over data every time someone with a badge says “please”. Also, “government requests” doesn't say anything about what government. What if Syria asks? In my mind, I want the following established prior to any governmental information disclosure:

  • The request is pursuant to a valid warrant, subpoena, or other compulsary procedure.
  • The warrant or subpoena has sufficient jurisdiction to compel response (assuming app.net is US-based, my understanding of that is that any government request must go through appropriate international channels to get a US court to issue a warrant/subpoena, or to have the active assistance of US law enforcement).
  • Ideally, if the warrant is accompanied with a gag order, that such a gag order is appropriate for the case at hand (a la Twitter suing to lift gag orders), but this probably gets expensive fast.

While in my ideal world, app.net would give itself as little permission to share personal information as it can legally get away with, I understand what I have outlined above may not be a practical legal reality. I am not a lawyer. Further non-policy clarity from app.net on how it intends to use the leeway it gives itself could be helpful.

Protect from harm opens up CISPA-style (and worse) disclosure on seemingly-arbitrary basis, but might be sufficiently harmless if it's things like disclosing the billing address of someone making (non-satirical) threats of mass violence. Clarity, and if appropriate further restriction on data use, could help here. Perhaps a second document explaining the various elements of the privacy policy and why they are needed? Tarsnap does this to great effect.

Finally, the new version drops the clarity that, if app.net is acquired, the acquiring company will be bound by these terms. It would also be helpful to state, if it is true, that potential investors or purchasers will be bound with respect to any data they see during negotations, and something about the contractual obligations of third-party vendors.

@choofnagle
Copy link

Hi, do consider including an emergency exception, to give app.net the ability to release information in its discretion if something terrible happens. Federal wiretapping and privacy laws contain emergency exceptions to allow information in exigent circumstances, such as a kidnapping, where a service provider's data could reveal the location of the victim, etc.

@mdekstrand
Copy link
Author

@choofnagle That should be covered by the current doc's "protect from harm" language, and still may be admissible under clarified language.

I would like app.net to be very careful about the kinds of permissions they give themselves. While in principle, participating in a kidnapping investigation by disclosing IP addresses is good and noble, what standards are to be used when deciding what kinds of investigations to participate in? What protection is there against coercion and pressure? It could be that a privacy policy can't provide much protection (in which case I would like to know that).

The current U.S. law enforcement climate is one of asking for - and receiving - large swathes of information little regard for due process or rule of law. I want to see more services oppose rather than comply with that regime.

It is also possible to oppose it in places other than the privacy policy. For liability (or other legal) reasons, it may well be that the kind of open language currently in place is basically necessary. I can likely accept that, if I am (A) told that it is true (or at least that this language is being inserted with great thought, deliberation, and legal reason, and not just because everyone else does it) and (B) @daltonc and @berg communicate clearly that they have a high bar for compliance. Twitter is actually setting a pretty good example on this front when they go to court to get gag orders lifted.

In general, a companion clarification/intent document (or inline “why this is here” comments) could go a long ways.

@mdekstrand
Copy link
Author

A further concern on @choofnagle's suggestion of an emergency exception: what constitutes an emergency? Who decides? Kidnapping seems to be a fairly clear case, as do immediate plots to bomb a building.

But what about organizing a protest or demonstration?

@choofnagle
Copy link

Perhaps then this is an opportunity to limit the language on harm you mention. It currently reads,

To enforce applicable user agreements or policies, including our Terms of Service; and to protect App.net, our users or the public from harm or illegal activities;

This actually has some wiggle room. For instance, economic harms could qualify as events that could trigger a release of data. A protest could be illegal. Perhaps a change to:

To enforce applicable user agreements or policies, including our Terms of Service; and to protect App.net, our users or the public from physical harm or illegal activities dangerous to human life;

You concern about how this can be interpreted is important. One way to address it is to give hypothetical examples of the kinds of emergencies/harms that could serve a guideposts. Under such an approach, the language might look like:

To enforce applicable user agreements or policies, including our Terms of Service; and to protect App.net, our users or the public from physical harm or illegal activities dangerous to human life, such as when a crime is in progress and data held by App.net could protect another person from physical harm;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants