Ed Felten: Why Email Services Should Be Court-Order Resistant 183
Jah-Wren Ryel sends this excerpt from Ed Felten at Freedom to Tinker:
"Commentators on the Lavabit case, including the judge himself, have criticized Lavabit for designing its system in a way that resisted court-ordered access to user data. They ask: If court orders are legitimate, why should we allow engineers to design services that protect users against court-ordered access? The answer is simple but subtle: There are good reasons to protect against insider attacks, and a court order is an insider attack. To see why, consider two companies, which we’ll call Lavabit and Guavabit. At Lavabit, an employee, on receiving a court order, copies user data and gives it to an outside party—in this case, the government. Meanwhile, over at Guavabit, an employee, on receiving a bribe or extortion threat from a drug cartel, copies user data and gives it to an outside party—in this case, the drug cartel.
From a purely technological standpoint, these two scenarios are exactly the same: an employee copies user data and gives it to an outside party. Only two things are different: the employee’s motivation, and the destination of the data after it leaves the company."
Re:The real subtle reason. (Score:4, Interesting)
Even if you make something impossible, you still have to convince the court that it's impossible in order to avoid being locked up for 13 years on a contempt charge.
Which means the court can use the mere threat of a perpetual contempt sentence to coerce you to make things easier for them ahead of time...just in case.
Extending the model (Score:4, Interesting)
Imagine that one wishes to prevent subversion by drug cartels but honour (or appeal) court orders. This is the problem that public libraries have dealt with since their creation. Someone always wants to know what person X has been reading, in hopes of using it against them....
Library software is normally written to preserve privacy, and discard the record that "X has book Y" when the book is returned. It can be written this way because several of the countries where it is sold require privacy as part of their legal system. Purchasers in other countries get privacy as a side-effect.
Countries prohibiting privacy would require a special version for a quite limited market, and the library software companies aren't motivated to deal with them: just doing an internationalization/localization to get into a small market is hard enough!
When an individual library is served with a court order, they can honour it by doing a lookup once a day and writing X's new books down on a piece of paper. As this doesn't scale, and is also a credible cost, the willingness of courts to order it is reduced, and the damage to privacy is limited.
Applying this to email, one wishes to keep routing data only until a message is delivered to the next host and we get a "250 OK" from SMTP. If a court wishes to collect that metadata, they can station an officer with a laptop at the ISP and gobble up the packets routed to/from him. This is onerous, and in Canada at least requires a "wiretap warrant", which the courts restrict more than ordinary search warrants.
The person wishing to provide this kind of information to a drug cartel has the same hard task, and is also more likely to be detected by the ISP.
To oversimplify, we're keeping far too much information about email: an author or vendor should take notice of the privacy laws of their preferred markets and discard debugging/diagnostic information at the end of a successful delivery. If they wish to cover themselves against customer complaints, they might send delivery notices that the customer can read or filter out at their convenience.
--dave