Back when my niece was a young teen, she and her school friends used Facebook, but would wipe out their profiles every year and build new ones with new pseudonyms. Protected their privacy that way, and automatically fixes the "erase dumb stuff you said as a kid" problems.
There is this piece of Cat 5 that isn't remotely hackable. Unless it's tapped, or if someone puts an inductor on it, or if they use TDR to estimate the length of the wire to figure out the distance between routers and discover where the Intrusion and Detection Systems are located.
What a hopeless article. Yes, real quantum computing would be cool, and D-Wave has been doing quantum-y things with investor money for a decade or so, and scientists have developed improved more standard kinds of quantum computers to the point that they can now factor 21, surpassing the record of factoring 15 that held for a few years, and maybe sometime in the future quantum computers will be as far advanced beyond that as today's rockets are beyond the ones Goddard had on paper a century ago or his early flying models 90 years ago, or maybe not (or maybe both at once, because YOU CAN DO THAT with quantum.)
But like most articles about quantum stuff in the popular press, and 99.9999% of content about it in the New Age business, it follows the paradigm of
1. I don't understand quantum!
2. I can imagine really cool things that I don't understand how to make!
4. PROFIT! , err, Therefore, quantum is how to make really cool things I want! QED!
Quantum physics isn't a Simple Matter Of Engineering like rocketry (and there are reasons for the phrase "Rocket Scientist" - rocketry's also more than just a S.M.o.E, no matter what you remember from those Heinlein stories you read as a kid about building spaceships in your back yard.) Mathematics and physics breakthroughs don't just happen because you really really want them to or because you pour lots of money into the engineering (though especially for the physics, that really helps.)
And yes, D-Wave might be on to something, or they might be pursuing a dead end, and we'd learn valuable things by helping them do either one, if they publish enough detail about their work, and maybe they can build quantumy computers that are useful for real-world problems even if you can't use them to run Shor's Algorithm to crack factoring-based crypto. But just because rocketry was at sort of a cusp a century ago, and lots of other technologies have gone from "not ready/usable yet" to "useful" that doesn't mean that quantum computing is one of them; lots of other technologies have gone from "not ready/usable yet" to "old obsolete dead ends."
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