Or even for IRS to subpoena such records directly, it's not like NSA is the only agency in the whole USG that can order relevant documents to be turned over for investigations in their bailiwick. Maybe it would need a warrant instead but it can't be too difficult for IRS to just get it themselves.
They shouldn't be emailing around "highly confidential brokerage account information" in the first place. It should be locked down in some internal system. Poor practice from GS that caused it all in the first place.
Having worked at a similar iBank, I can assure you most people don't give a rat's ass about proper procedures until they're caught. Why it was even possible to send an email to an external address with such an unencrypted attachment is a bigger question. I hope the lucky recipient finds a high bidder for said information.
This is 100% true, but does that mean that they should experience a data breach as a means of teaching them a lesson? Seems like that could create a lot of collateral damage among the affected account holders.
I'm having a hard time getting outraged at either party.
We give companies a hard time for lax security practices. GS recognizes an error and is trying to take steps to reduce the likelihood of a data breach. What's wrong with that?
Google wants to protect its users from unnecessary interference in there email accounts, so it asked for a court order. What's wrong with that?
I'm not outraged, either, but curious. What if this had happened with physical mail? Does it make any difference whether it was read or not? Can the destination account argue and keep it?
There are many interesting questions raised here. It could be interesting to see how it plays out in the end.
Google should be able to tell whether the email has been opened or not, or whether the receiving account is active or has been logged into recently.
It's interesting to think about this email landing in my Gmail inbox. I'm pretty sure I'd reply and inform the sender that they screwed up and ask if they want me to delete it.
In the early 2000's I worked in a school system that used a faux-email system where un-sending messages was completely possible. Any user could un-send messages that no recipients had read, which was _great_ as a user. Only sys-admins could un-send read messages. The only time I remember the latter happening was after someone got fired and flamed their way out the door. It was a bit chilling if you did read their messages before all evidence of their outburst erased by the invisible hand of the sys-admins.
The VA's internal system also had "email" like this (before email was widely used), where we could unsend messages.
Fun fact: The VA's system was called Decentralized Hospital Computer Program (DHCP). When that acronym was overloaded by Dynamic Host Configuration Protocol, they changed it - to VistA. Either they had really bad luck picking names, or were very prescient.
Frankly I've never understood why email doesn't work this way, it looks backwards to me. As long as the recipient hasn't read the email the sender should have the right to delete it. Even if the client has already delivered the email in the recipient's inbox there should be a way for the SMTP/IMAP server to notify the client and remove it.
Even Whatsapp works this way: once you've sent a message, you can't unsend it. The message is first relayed to their servers and then relayed to the client, but even if the recipient isn't online and the message is only on the server, deleting it only removes it from your conversation. You'd think that in 2014 we would have addressed these kinds of flaws.
> "there should be a way for the SMTP/IMAP server to notify the client and remove it."
As long as the protocol requires the client to obey a command to delete, it's not going to work.
With such a protocol, nothing is stopping me from choosing to disregard any messages to delete already received (and downloaded) messages. In fact, I'd probably have the client highlight them for me if they got a "delete this" request. There's probably something good someone is trying to hide in that message.
If I recall correctly, Twitter had a similar issue with their API. They have a method to delete a Tweet, but the Twitter client has to honor the delete client-side since it has a cache of tweets it has seen.
Of course, in a closed environment like Twitter, Twitter can choose to revoke a non-compliant client's API keys if they don't follow the rules. Not so much with email.
> Frankly I've never understood why email doesn't work this way
Because internet email is mostly designed as a highly fault-tolerant low-trust network, so the basic design is unauthenticated forwarding, so once its sent, there's no generally-applicable way to prove that you are the sender to ask for it to be deleted. Inside something like a particular Exchange server, email can be implemented that way (and basically is), and that works because its a single centralized database with client authentication.
It seems to vary though; you can configure Outlook to not obey message recalls, although that might be at the discretion of an admin group policy. Either way, my last DoD network allowed you to avoid deleting emails based on recall requests, which was a very nice feature (or policy omission, not sure).
1) Possession is 9 points of the law was the original quote - it's just been bastardized over the years.
2) If it's "okay" for your machine to receive and keep the misdirected email message, how is it "not okay" for someone sending a correctly directed message asking your MUA to remove the message? Your MUA allows the behavior; you allow it by use of that MUA; no access control mechanisms were broached. To look at it literally, all email is "reaching into your machine to suit the sender".
> Possession is 9 points of the law was the original quote - it's just been bastardized over the years.
Its not that much of a bastardization, as a modernization -- the original seems to have been "possession is 11 points in the law (and they say there are but 12)", which was decimalized from 11 and 12 to 9 and 10, sometimes used with the "9" alone and the last part omitted, and later simplified to 9/10. The original sense of the statement is preserved, which is why I wouldn't call it a "bastardization".
This is off topic but I found out the hard way that then you delete a google docs account all documents you shared with others are deleted from their list of documents.
I suppose on the one hand something like that is a solution for gs.
On the other hand, while I understand the model, I'm not 100% it's the right one.
I use GPGTools when sending sensitive client information, to avoid situations like this.
GS has zero excuses, they could very easily code a Microsoft Outlook version of it that is seamlessly integrated. Instead they fail at proper risk management and rely on government intervention, sound familiar?
Do you also use encryption when sending information internally to a colleague? That's the situation here: it was an internal email accidentally sent to GMail instead of Goldman Sachs.
I would be extremely surprised if GS didn't have a system like other investment banks that popped up an ugly and obvious "you are sending an external e-mail. Are you sure?" dialog when sending to non-internal e-mail addresses.
I've worked for two of GS's competitors. Any email with confidential information (internal or external) has to be encrypted and signed. Standard operating procedure. I assume it is at GS too and this fella, like most folks on the investment side, just didn't give a hoot about the SOP.
Some firms have email triggers that tell you when you're sending something outside the firm to minimize those accidents (and to make the employee carelessness associated with any remaining accidents clearer).
Not sure why this was downvoted. If you're in an outlook/exchange integrated environment, you only have to click "encrypt/sign this". It's almost transparent to the user and in addition it would raise an error for the original sender. (saying the key for user blah@gmail.com cannot be found)
And how would it help to automatically encrypt internal e-mails when an e-mail accidentally gets an external delivery address because someone fat-fingers?
You can set up the encryption so that it requires a verified public key. If you mistype an address, you won't have their public key, and can't encrypt the message to them.
Yes, I understand (on a superficial "don't actually use it on a day-to-day basis, but have encrypted e-mails before" level)
I am imagining this program that looks through your To: field for recipients in your address book that have shared their public key with you. If it finds any, those people get a copy sent to them which is encrypted and only they can read...
Now what happens if you accidentally try to send mail to someone not in your address book?
I guess hopefully you get a big popup that says "Warning: mail will not be encrypted!" Maybe not?
I've used the command-line tools to encrypt files and send encrypted attachments. It's nothing like "automatic" and it's certainly not an envelope for the whole message.
Understandably GS is not a very sympathetic figure, but in general I don't think it's unreasonable to wish for an email "undo" if you fat-finger the recipient address and realize it immediately.
Microsoft Exchange has that feature, exposed in Outlook. The fun thing is that IIRC it sends a special email to trigger it. So if the recipient is not using an Exchange server, he sees both emails.
A reply to the email with a single line saying "recall", IIRC. I got one of these from a business partner years ago... it was intended as an internal email between them, not as a response to us. It was kind of hilarious. I was very tempted to reply "no" :)
If you don't realize you did it in a few seconds you're still shit out of luck, though. I imagine most people won't realize they sent it to the wrong person until they're notified of the other party not receiving it, or there's an unusual length of reply time. I wonder how people would feel about emails being undoable until the other party opens it.
I assume the email forgot to include the standard legal disclaimer and "delete-if-unintended-recipient" footer notice? Would that actually protect them if that was present on the email?
Those things don't do a darn thing. I've Googled it extensively and the only justification I can find is: "Why NOT include it? It does no harm and it might help."
I'm yet to find a single legal case where an email signature made or broke the case. It strikes me more as legal mumbo jumbo voodoo at this point than anything of merit.
Not least of all as a contract is between two parties, the recipient cannot be auto-magically placed into a contractual position just by receiving the email.
That would be like me sending a snail mail letter to someone with the words "By reading this mail you agree that all your stuff is now mine" and pretending like any court in the world (any country) would take that "contract" seriously.
That's essentially what these signatures do. Try to set up a contractual arrangement with one party "agreeing" to that arrangement just through the virtue of receiving an email?
Bruce isn't adding very much here.