Comment Agreed. (Score 1) 204
And there are a bunch of similar applications for which you might want to be able to verify that the mail's only going where it should, and that it won't stick around as a legal record longer than you want it to.
And there are a bunch of similar applications for which you might want to be able to verify that the mail's only going where it should, and that it won't stick around as a legal record longer than you want it to.
This approach to special-handling-required email is pretty common - if the recipient has the right software (client / app / browser extension / whatever), their email client can read it directly, otherwise they have to use a web link to the provider's server. The more secure and scalable versions store only keys of some kind on the server, and include the encoded or encrypted message in the email, the simpler but less scalable and less secure ones keep it on the server and just include a link in the email.
Disappearing Inc did that back in 2000 for a self-destructing email application, and I've seen similar things for encrypted mail (e.g. Voltage Secure Mail) and other applications (often marketed as "Data Loss Prevention" or whatever), mostly for corporate users.
And yeah, if I get email from some random stranger saying "You've received a Whiffly-Mail Message, Click Here to Download", it's going in the spam bucket, but if I get it from somebody I regularly deal with I'm fairly likely to open it. Can't be much worse than opening a Microsoft Word document from a stranger. And of course, if it's from Paypal or SomeBigBank or Microsoft Technical Support, it gets junked as well.
Yes, you could implement it by storing the message contents on a server, but the non-LOL version that Disappearing Inc implemented back in ~2000 sent the encrypted message to the recipient, and only kept the key on the server. If you had a client at the recipient's end, it would fetch the key, otherwise you'd paste it into an SSL form on a web browser that would decrypt it. DI would delete the key after whatever business rules you liked (typically N days, or read-N-times, or "recipient clicks Delete", or sender clicks "Ooops.", etc.)
Does this keep the whole message on the server or just the keys? Hopefully the latter, because it's more secure, but I don't know.
Back in 2000, a company called Disappearing Inc. made a presentation to the Bay Area Cypherpunks meeting about their product, which was pretty similar except that back then most people used real email clients instead of webmail. When the guy walked in, and we were expecting him to be pushing some kind of snake oil, he started out by saying that their threat model was to let cooperating people have some guarantee that their email would go away when they wanted it to, not to keep uncooperative people from doing that because you just can't stop screenshots / cameras / sender saving a copy / etc. and anybody trying to sell you that is selling snake oil. And suddenly he had a friendly audience, instead of one that was going to beat him up, because he'd defined a problem that could be believably solved, which was cool.
So the trick is that the file's in an encrypted format, and Disappearing Inc's server keeps the keys and a delete date for them, and if the sender and recipient are both using their product, the reader program/plugin/etc. fetches the key from DI's server; if not, you drop the file into an SSL-encrypted web form on DI which decrypts it for you. When the delete date hits (or earlier, if the file's set for read-only-once), DI deletes their copy of the key, so the recipient's mail box now has an encrypted binary blob file with no decryption key. Yes, if the server gets compromised, it's all toast. Yes, if the recipient's email client or browser is compromised at the time they read it, it's all toast. But if nobody's trying to subpoena or crack the message until after the key's deleted, then it's too late to recover old messages, though you can always try to attack new ones.
It was a nice system, and they stayed in business a couple of years before getting bought by somebody who got bought by somebody and disappearing into dead-dot-com-space. Similar systems have been sold by various other companies, often under category names like "Data Loss Protection".
If you wanted to do a "no forwarding" version, you'd do it by setting rules on who could access it, whether by IP address or some ID in the reader plugin or delete-after-one-read or whatever.
Yeah, it was a cute name. The folks running it had a clue, knew what they could and couldn't realistically do.
Not necessarily, HP 3Par 20850 scales to 4 PB of SSD (raw, 15+ PB with dedupe) and 3.2 million sub 1ms IOPS, and 75GB/s of throughout but one LUN is still limited to 16TB because not enough customers need more than that it one logical disk to change underlying code.
I meant to say it's seen as unfair by the line workers.
Dress codes make a slight amount of sense when the company has a requirement that many employees must wear uniforms. It's not fair to say, "you people who stand in front of customers all day must wear a blue shirt, green tie, and khaki pants" but then say, "you people are in the main office, so you're exempt from dressing like a dork." Some of the line workers resent it. Management can then decide if they want to settle the matter by subjecting everyone to a dress code.
Of course HP doesn't require line workers to wear uniforms, so that's not the case here. This is just another stupid and capricious management decision by a company that's become famous over the last decade for having the most incompetent management of any (formerly) major corporation. HP's executives have been so bad it's easy to imagine an evil Michael Dell offered HP's board of directors one hundred million dollars -each- to sabotage HP into oblivion. (Hey, it makes a lot more sense than any other reason for imposing a dress code on engineers.)
Good point. First, IANAAEE (I am not an automotive electrical engineer) so much of this is speculation, but not all of it. I do think small, hardware firewalls ("data diodes") could help prevent a lot of these problems. I also agree with you in that I don't think the direct access is necessary, but I think it might loop around in such a way that the holes end up being present anyway.
Consider: the crash message from the airbag sensors, which is on the high speed engine control bus (ECB) goes to the door locks. The door locks are on the low speed bus (security network), but bridge both networks. A data diode could stop messages from the door locks from flowing back to the high speed ECB. The door locks, ignition key, and immobilizer are all on the security network. The ignition key talks to the immobilizer. Finally, the immobilizer talks to the ECU, which is on the high speed ECB.
The security network is supposed to be isolated from the cabin comfort network (where the infotainment system, navigation system, and cell phone stuff are.) But the crash signal has to travel to the cell modem somehow, so another component has to allow messages from the ECB to the cabin bus. Plus, some of these cars have "remote start via cell phone", so something still has to enable messages from the cell modem to travel to the immobilizer. How do they get to the security network? (Bigger question: do the Chryslers even have a security network, or do all low speed messages share a common bus?)
If everything were perfect, the immobilizer would be the only potential spot for the bridge; and because the immobilizer's entire job is to prevent the engine from starting unless all the security is perfectly aligned, it seems like the natural place where the engineers would focus their security attention to isolate the low speed bus from the ECB. But obviously not everything's perfect.
It seems like they should have a set of dedicated data protection devices that would be similar in concept to a traffic signal's conflict monitor, somehow hard-wired with a rule that allows only whitelisted messages from the modem to go to the immobilizer.
Want a more adventuresome automotive experience? Go to India. During the three weeks I was there, our driver's car was struck more times by more vehicles and pedestrians than I've seen in my 35 years of driving in the US.
The drivers are worse than you can imagine. "Keep left" is more of a guideline than an actually obeyed rule; "keep center" seems to be the observed behavior. The few traffic police I saw were standing in small gazebo-like boxes in intersections - they were not driving interceptors or squad cars. Peddlers and beggars wander among cars slowed down on the roads, selling umbrellas and toys, and asking for handouts. Fuel tankers have signs lettered across the back: "KEEP BACK 25 FEET", but nobody pays attention. Lane markers are apparently nothing more than wasted white paint decorating the road. On the road in front of you you may encounter a farmer with a pony cart, bicycles, pedestrians, elephants carrying loads, and yes, the occasional unattended cow.
And the honking! Seriously, India, WTF is up with the continual honking? You can drive a full week in many cities in the USA without hearing a single car horn.
We saw all this on every single trip, including a 2AM drive from the airport.
An inattentive driver would cause an accident within a split second; this may be why minor accidents and collisions are so common.
Consider the safety network, which has data from the crash sensors, rollover sensors, seatbelt sensors, and seat occupancy sensors, and mixes all of that data together in a set of rules that instantly trigger the correct airbags and seatbelt pre-tensioners. It also needs to connect to the infotainment system to take over the car's data or phone connection to send a message to emergency services. In turn it may also get data from the navigation system to report location information. It may trigger an unlock of the car doors to assist bystanders in rescuing the occupants, and it may shut off the engine to prevent further injury. It may talk to the signalling systems to turn on the 4-way flashers to help first responders find the car. The car door lock system is part of the security bus, which talks to the engine immobilizer, responsible for talking to the ECU to start and run the car. All of those data feeds that seem like they could be isolated have real operational needs to come together in multiple devices.
The rules in a car are exponentially more complex than ever before, and they're increasingly vital for safety; not just comfort or entertainment. Consider how many lives have been saved because their airbags deployed, and the emergency responders were able to dispatch an ambulance in time to save a crash victim from dying. Now consider how many people have died from crashes directly induced by CANBUS hacking.
The safety systems of today are doing their jobs better than ever, which is the topmost goal of the engineers. Also consider the safety systems need to guarantee reliable operation to work for the first time ever in an actual crash. If they can layer on system security without compromising occupant safety, they will, but not at the expense of crash survivability.
Sounds tasty (except for the "Oh, right, I don't eat it" part
No trolling intended here - the word "Politicians" is right in the title.
The Ashley Madison crack is happening now, after several months of heavy campaigning by various US Feds and Congressmembers and their UK counterparts (like Tory Prime Minister David Cameron) who all want to ban encryption or make us put magic back doors into all our crypto systems so they can eavesdrop on conversations instead of "going dark", their term for "not getting to increase our surveillance capabilities quite as fast as we want."
With 37 million names in the database, it wouldn't be surprising if at least some of them are the same people trying to deny the public's right of privacy, and they ought to get spanked publicly about their political hypocrisy, as opposed to just getting spanked privately if that's what they were looking for.
Oh, yeah, if you've got a desktop PC, putting an RS232 card in it works a lot more reliably. We don't have many of those around (and the ones we do are antiques that have serial and often even parallel ports), and mostly have either good laptops (really convenient in a lab full of racks) or old laptops with dead batteries that still work ok when plugged in.
That's pretty much how the higher speeds work also - they negotiate 300, and if that works they signal (argh, I've forgotten if it's digitally over the 300 baud or analog tones) the higher speeds they can accept, and then send tones to see if the line will carry the sound quality needed for the higher speeds to work.
I had a while back in the 80s when one of my home phone lines could handle 2400 but the other (which used to be ok) stopped syncing at 2400 and would only do 1200. Tried to tell the phone company that it needed fixing, they asked what it sounded like, and "}i}}}}ii}}i}i" wasn't an answer they knew what to do with, so they said "sorry, your residential line isn't data rated." Eventually it degraded to the point I could call up and tell them it sounded like [LOUD STATICKY NOISES], and they came and fixed the drop line where it was rubbing against a tree branch.
The moon is made of green cheese. -- John Heywood
