Slashdot Mirror
That Was Fast: Leahy Drops Warrantless E-mail Surveillance Bill
Presto Vivace writes "Under the right conditions, online activism can be very effective. U.S. Senator Patrick Leahy has already abandoned his warrantless e-mail surveillance bill we discussed this morning. 'The Vermont Democrat said today on Twitter that he would "not support such an exception" for warrantless access. ... A vote on the proposal in the Senate Judiciary committee, which Leahy chairs, is scheduled for next Thursday. The amendments were due to be glued onto a substitute (PDF) to H.R. 2471, which the House of Representatives already has approved. Leahy's about-face comes in response to a deluge of criticism today, including the ACLU saying that warrants should be required, and the conservative group FreedomWorks launching a petition to Congress -- with over 2,300 messages sent so far -- titled: "Tell Congress: Stay Out of My Email!""
Translation, "I thought nobody would notice."
The truth is that all men having power ought to be mistrusted. James Madison
Whenever this stuff can't get through Congress it just ends up in a Friday night EO dump. Is this one important enough for Black Friday? We'll know by Monday.
try convincing nongeeks and nontinfoilhaters to use double public key encryption for all of their communication be it email chat or voip. they will fight it tooth and nail because it "more complicated" translated requires one additional click per message maybe a couple keystrokes for your password.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
No problem! We can just simplify the process by setting up a large number of so called "certificate authorities", who we will trust implicitly and pay yearly fees for little chunks of math! Nothing could possibly go wrong, and we can have a comforting little padlock symbol for noobs...
According to this, Leahy claims CNET was incorrect in its original article and that he never supported the warrantless wiretapping. When he tried to clarify this stance, CNET comes out with this article saying that he backtracked because of the backlash caused by their article. Not going to make the judgment call on which side is right, but it should at least be noted that there are two sides to the story.
When the ACLU and a conservative group are loudly on the same side of something, you know whatever it is is bad.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Duh. That's because a self-signed certificate delivered over the Internet from a random web site provides no protection whatsoever against a man-in-the-middle attack.
Now that it was shot down from being in the open, it will reappear in a unrelated bill, buried under 1000's of other layers so it wont be noticed until its too late.
---- Booth was a patriot ----
We could have fixed this whole privacy thing from the beginning, but for whatever reason we didn't.
There was a time when people read E-mail using local clients. Freeware programs such as Thunderbird and Pegasus Mail were common.
The issue could have been addressed by fiat from any one popular software package. It would only have required:
1) For each user, generate a default public and private key on install
2) Add a field to the protocol requesting the recipient's public key if they have one
3) Add a field advertizing the sender's public key
4) Add a button on the interface for "Prevent others from reading the content"
Done right, that's all it would have taken.
The protocol allows for experimental fields which can be ignored if the client doesn't understand, and there is already a mechanism for "delivery confirmation" which could be adapted for "public key confirmation". It would have taken very little to have the client intercept the public key response, process it, and not bother the user about it.
The mouseover for the button could have said "use encryption if the recipient has a compatible client".
At the time, this would have been a feature that mainstream clients didn't have (Outlook, Exchange, &c), so it would have been a selling point for open source. It would have led people to encourage the recipient to change to a more secure client. There would be an incentive to make other packages compatible, and soon the feature would be everywhere.
All of this could have been implemented transparently for the naive user, with a more sophisticated interface for advanced users who needed more control.
But for some reason we didn't do that, and now everyone reads their E-mail online. We didn't make this a de-facto standard, and now we've missed our chance. (I've often wondered if the browser could automatically encrypt/decrypt the content of specific named text blocks from specific sites such as gmail. Then the content could be encrypted online, but show cleartext to the user.)
We have the means and expertise to fix some of these problems, all it takes is the will to do it.
It does if you'd bother to look at the fingerprint and verify it's the same as last time. Which the browsers should do, but they don't because it cuts into their CA root key inclusion fees.
and pass a retroactive legalize anyway deal like they did with FISA abuse.
The issue could have been addressed by fiat from any one popular software package.
Thus solving it for users of one package.
Yes, solving it for one package. As mentioned in the post, there would be an incentive for other packages to implement the scheme in order to be compatible. As mentioned in the post. Perhaps enough incentive to form a Tipping point.
2) Add a field to the protocol
Which protocol? SMTP? POP? IMAP? UUCP?
The protocol allows for experimental fields
Same question.
Which one do you think? Do you need a complete spec, or will just an outline do? Google is your friend.
The mouseover for the button
Oh, this would solve the problem only for the people with GUI mail clients.
Did you really think I was advocating implementing this only on GUI clients?
The point was to get enough naive users into the system to make it a de-facto standard. Most naive users use a GUI client, so starting there would put the solution before a wide audience quickly.
could have said "use encryption if the recipient has a compatible client".
Sorry. How does my email client know what email client YOU are using and whether it supports this? Is there a new protocol you are proposing where one client asks another prior to sending an email? What happens if the recipient is offline?
If you have the public key for the recipient, then they have a compatible client. If you don't, you send the message in the clear and request the public key.
Really, this isn't rocket science - the first message I receive from the recipient would contain their public key. My first message to them would be in the clear, but would provoke a public-key sendback which my client would silently process.
(I've often wondered if the browser could automatically encrypt/decrypt the content of specific named text blocks from specific sites such as gmail. Then the content could be encrypted online, but show cleartext to the user.)
If you are limiting yourself to defining "email" as "gmail accessed via a web browser", you simplify the problem considerably. Of course Google could store all your email in an encrypted form and send you a javascript (if you have a js enabled/capable broswer) applet that decodes it on your system. If you send them your public key, they could even encrypt the stuff they store on their disks as it came in for you, if it wasn't already. You still have the problem of how you make sure every system you use to access that email has the key kept locally, and what happens for people who have gmail forwarded to some place else.
So, yes, the problem is rather trivial if you force everyone and everything through one mail server and ignore the huge diversity in protocols used to transport email and the kinds and types of clients/servers used to do it.
The protocol doesn't matter, since the message body can contain any text.
You could, for instance, encode public keys as part of the body of any message by wrapping it in a field delimiter which the client could pick out. If your browser isn't compatible, then the recipient would see the public key encoding as text.
This isn't so different from digital signatures, which are encodings of binary data attached to the bottom of a document body. I'm only suggesting that a similar method be used to attach the sender's public key, and have the client make note of the public keys as it gets them.
The sender uses the recipient's public key if it has one. Otherwise, it sends in the clear. The first messages will be in the clear, and encoded for all subsequent messages.
Really, this is not rocket science. Take a moment to think things through.