Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Haystack and informed consent—A legal/philosophical response to Jacob's concenrs

Ryan Calo rcalo at stanford.edu
Sat Sep 11 17:03:51 PDT 2010


Babak,

It is not enough to defend informed consent.  The devil is (no  
surprise) in the details.  We have an informed consent regime here in  
the U.S. with respect to consumer privacy.  It is an appalling  
failure.  Not only does no one read privacy policies, a recent study  
out of Berkeley and Penn shows that a majority of people see the  
words "privacy policy" and mistakenly believe that the company has a  
"policy of privacy" and hence cannot do specific things like share  
their information with others.

I'm willing to concede that an Iranian dissonant will be more much  
motivated to read a disclaimer than an American consumer given the  
stakes.  But I doubt Iranians are any less bounded in their  
rationality, to borrow a term from Herbert Simon.  Thus, for  
instance, the well-documented optimism bias may lead Iranians to  
misjudge the likelihood that they personally will be the target of a  
government investigation.  Or they may use the heuristic of U.S.  
approval (or its appearance) to judge the service safe.  Etc.

In short, we'd need to know a lot more about the form and extent of  
Haystack's notice and consent mechanism to judge its efficacy---and  
hence, I would argue, its ethical defensibility.

Ryan



M. Ryan Calo

http://ssrn.com/author=1042410
http://twitter.com/rcalo

On Sep 11, 2010, at 1:16 PM, Bram Cohen wrote:

> In terms of what the potential risks are to users and whether those  
> users understand them, I think it's important to make clear what  
> risks we're talking about. There's the chances that the user will  
> be caught with software in their possession, which I think common  
> end users understand just fine. Then there's the potential  
> consequences of being caught with the software, which I suspect  
> potential users understand reasonably, and in many cases better  
> than we outsiders do.
>
> Finally, there's the chances that an adversary will be able to  
> track back to a user based on their network traffic alone. That's  
> the one which I think end users don't understand at all, and where  
> highly technical issues matter a lot. I suspect that the best  
> possible defense one can conduct here is fairly weak, but it still  
> be done as effectively as possible, which Haystack currently does not.
>
> Going over my preliminary notes on the system as a whole, I think  
> the biggest mistake Haystack has made so far is actually a very  
> high level one regarding choice of users. By restricting the  
> userbase to a small number of high-value users, Haystack has  
> potentially made it easy for Iranian authorities to identify a  
> small number of high-value users just by virtue of the fact that  
> they're using Haystack. A much more prudent approach would be to  
> discourage the people who are already very at risk from using the  
> tool until there are a decent number of people using whose primary  
> legal risk is that they're using the tool at all, and are otherwise  
> uninteresting to the authorities. For example, Tor has thousands of  
> users in Iran right now, making running it at all reasonably non- 
> suspicious. It definitely is easy for the iranian firewall to  
> identify tor users, because they're all going through a relatively  
> small number of IPs which bridges are on. Whether those IPs aren't  
> blocked out of incompetence or a desire to maintain the ability to  
> identify Tor users is very unclear.
>
>
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
>
> Should you need to change your subscription options, please go to:
>
> https://mailman.stanford.edu/mailman/listinfo/liberationtech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20100911/d01b6b4e/attachment.html>


More information about the liberationtech mailing list