Ah, but the tamper evident seals are on the actual item. Not the package. And if customs wants to look at the item, they can easily retrieve the photographs hosted on the manufacture's site. And if they match the tamper evident, randomized seal, then drug hiding is ... not very likely ... unless of course, you wish to believe that the drugs were stashed at the time of manufacture. The reason for sending the photograph to the customer prior to shipping is to prevent a TLA from breaking the seal, tampering, replacing the seal, then forcing the manufacturer to change their web site with a new set of photographs of the new seals.

Seems to me that unless the law prohibits it, tech companies will need to start using tamper evident packaging. Then it won't matter if the NSA, CIA, FBI or other 3 letter agencies intercept the product during shipping. Perhaps glitter embedded in varnish painted over critical screws/fasteners, then photographed from various angles and posted to a web page, or emailed to the customer prior to shipping. Then if the item is intercepted the 3 letter agency will have a rather ... difficult ... time bypassing those seals such that careful examination upon receipt against the photographs received earlier won't reveal any tampering.

Typical misconception of GPL. You are required to share any code modifications /IF/ you distribute the modified executable. If your changes are for your use only, feel free to keep 'em to yourself.

Although to be honest, if I had mod points, I would have rated fizzer06's comment as +1 Funny.

incompleteness theorem. And as some earlier posters' stated, the correction is simple. Simply look again. The 2nd image collected will be different from the previous and if the NN is correct, will resolve to the correct interpretation.

I'm pretty sure that the $5 million policy is for accidents caused by the vehicle while testing. AKA.... Unproven technology. Once all the tests have been passed, the insurance requirements for the general public would be more in line with the the insurance requirements for non-autonomous vehicles. And I suspect that since the autonomous vehicles would have a lower accident rate, the insurance premiums would be lower as well.

Let's see now.

Aggressive driver going well over the speed limit cutting in front of me.... Don't really see that as a problem if the autonomous car is doing the speed limit. Yes, there's an interval where the car is too close for safe following, but the aggressive driver fairly rapidly increases the gap. (after all, you did state "going well over the speed limit"). As for failure to signal? I somehow doubt that the programming and sensors for the autonomous car will even notice turn signals. It will however notice the car shifting towards the side of the lane and will likely assume that the car will continue its sideways motion. Given the reaction speed of computer, a lot of the problems caused by aggressive drivers will pretty much go away.

Random - That's the impression a HUMAN driver would have. A better term for "random" would be "unpredictable". And since the autonomous vehicle would be monitoring the relative location of nearby vehicles, people, and other objects the main criteria is "will that object with its current velocity and potential acceleration impact this vehicle?"

Unsafe - Just another aspect of your "random" comment. Please see above response.

Fails to signal - As mentioned, turn signals are not considered a reliable source of data. They are meant as advance warning to us rather slow humans. Stick with the physics based solution.

Well, the vandalism aspect can be "solved" by the simple means of on board video cameras. And since entry to the taxicab would most like require some form of ID prior to the doors unlocking, you could be pretty darn sure as to the identity of the passenger. And the "official" rational for the camera? Why, it's to gauge the customer's reactions to the advertisements. After all, that lets the system present advertisements that the customer finds more receptive.

George Orwell didn't go far enough. Google is correcting that mistake.

And now the reason for the autonomous car research by Google is revealed. Somehow, I suspect that the laws prohibiting moving video and flashy graphics will go away, or stop being enforced once autonomous vehicles are common place.

You might want to look up some of Niven's laws. In particular, your issue seems to be with #17...

There is no cause so right that one cannot find a fool following it.

Didn't pay a whole lotta attention to the constitution and the culture at the time. I'll tell you in nice simple words.

At the time the constitution was written and the 2nd amendment passed, that allowed the common citizen to have the exact same weaponry as the military of the era.
Gun? Sure thing.
Cannon? Yup. That too.
Warship? If you can afford it, go for it.

Hmm... Sounds like the police having the same restrictions as random people, including criminals to me. You might want to study up on history again.

Look at the GIT entry. It was entered Dec 3, 2013. A few months earlier than "end of last month". Also the disclaimer on the GIT entry means that the bug could have been discovered even earlier, so the Dec 3 date is merely a "no later than" boundary on the discovery date.

Might want to check the GIT report again. To quote: ... which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings. ...

Notice that the bug permitted an easy denial of service attack. And with more effort a privilege elevation.

The GIT entry for the bug was entered Dec 3, 2013. So that means at a minimum, the bug was known of and not fixed for 5 months. That's a bit excessive for 'A bug this serious only comes out once every couple years' kind of bug. I'll agree that 5 months is a lot shorter than 5 years, but it's still far too long.

EM emissions in what is effectively a huge Faraday cage? I don't think so.
The ebook lockdown is intended to prevent ex-filtration of security information. I'm rather surprised at the rather restricted number of titles they provide. And it seems that they could have designed it to permit updating of the contents while on shore. Say perhaps with a special loader that cryptographically signs the new content and the actual data transmission path being near field interactions. If such devices were only available at shore bases, it would be cumbersome, but would still allow for the updating of contents while preserving the security aspects of the readers.

Indeed, you could use it for the session key. But then again, the rate in which the random bits needs to be generated isn't anywhere near the 1 Mbit/sec rate. After all, how long does it take to generate 256 bits? As for OTP, getting the bits to the receiver is as mentioned earlier "The Real Problem". But contract that issue with the quote "And applications? Secure credit card transactions are only the beginning. A quantum random number generator that works at 1 Mbps can also secure emails and even phone calls." from the fine article. That quote certainly implies that we're talking about a megabit per second of information being encoded and securely transmitted. Which once again leaves the question "How are the random bits sent to the other party?" Heck, even if you use that method solely for the generation of session keys, that session key needs to be securely transmitted. Usually via public key encryption. Which in turn becomes the limiting factor in the overall security.

So what's the use of a 1mbit/sec random number generator again?