The ruling doesn't ban the no fly list, it merely requires the government to make a suitable appeal process for those who are on the list. So you may expect the list to still be in use for quite a while. Additionally, Judge Brown is only on the Oregon district. So her ruling only applies to Oregon (however, it will be used as a precedent in other districts). All in all, it's still a very good ruling, but there's still a long ways to go.
In a nutshell, the Post Office has a customer base of only about 400 companies. The actual American public is lost in the noise as far as the Post Office is concerned.
Interesting article, however, I suspect the editors are a bit mistaken. I strongly suspect that Mr Delaire is NOT using TIG welding in his machine, but instead is using MIG welding. Also I have to wonder if Mr Delaire is aware of http://hardware.slashdot.org/s... If not, he may be able to save a bit of effort and time by building upon the work someone else has already done.
You might want to do a bit of math before making such a statement. 700TB is a very large amount of data. And in order to do that in a week, would require quite a bit of data transfer bandwidth. To wit:
700,000,000,000,000 / 7 days = 100,000,000,000,000 / 24 hours = 4,166,666,666,666 / 3600 seconds = 1,157,407,407 bytes per second.
Do you really write 1.157GB/second every second for a week? And if so, what data interface are you using? I'd really like to know since SATA 3.0 can only handle 600MB/second. Perhaps you're using SATA 3.2 which does have the required speed?
Now in an environment using multiple drives, you can get to the 700TB mark much more rapidly with much lower per drive bandwidth. But then again, that's not the test criteria. They are testing how much endurance individual SSDs have.
Do you make it something that attaches to the outside of the skin for power (ie: a small battery)? Or cut the person open whenever the battery starts flaking out? If the latter, we have new members of the zipper club instantly.
Seems that such a device would be an ideal candidate for inductive coupling. Both for charging and data transmission. The device would consist of two parts. One part implanted into the body, and a second part held on the skin over the implant. That would avoid a semi-permanent skin penetration acting as an infection risk.
Not everyone is comfortable with public speaking. What you're complaining about is what is called "verbalized pauses" and almost all untrained speakers suffer from it to a degree or two when speaking publicly. Training, and practice with public speaking tends to eliminate that.
Unfortunately, that isn't likely to be true. A lot of Type I diabetes is, at its root, an autoimmune disease. The immune system goes crazy and kills off the islets of langerhans. So let's say you do get a grown pancreas from your own cells and have it transplanted. Well, your immune system then proceeds to kill of the islets of langerhans and you're back at square one.
Gee. Send the data in the clear along with an encryption key so it's stored at the remote site in an encrypted form. There's no way that a NLS will allow for the interception and disclosure of the key is there?
Frankly, that "solution" is a rather poor one at best and far too likely to give the customer a sense of security while in reality their data is totally accessible.
The comment on not using aerodynamic down force is rather telling. Only reason I can think of for not doing so is that if they did, it would consume power that could otherwise be used for more speed. And since motive power isn't being supplied through the wheels, traction isn't all that important. I do wonder if steering will be entirely via the wheels, or if they're using aerodynamic means.
It does address the issues you mentioned. As for the tool chain (compiler, linker, loader, etc), that is addressed by making them diverse. The term 'compile' means the entire chain from source to binary which includes the entire tool chain. As for the CPU issue, there's nothing in the source that mandates that you must create a binary for the same CPU as you're executing on. So do DDC on multiple CPU families (Intel, ARM, PPC, etc) and compare the final results. And the beauty of DDC is you can do it even if the tools you're using have been compromised. The only requirement is that the tools not be compromised in EXACTLY the same way. Any difference in the actual behavior of the tool chain will result in a difference in the output to be compared. If you're extremely paranoid, there's nothing preventing you from executing the tool chain inside an emulator to bypass any issues you might have with microcode.
You just might want to look 'Diverse Double-Compiling' as a method of countering the attack described by Ken Thompson in 'Reflections on Trusting Trust'. A paper on DDC is at http://www.acsa-admin.org/2005...
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.
I call it the aggressive, psychotic driver who makes random, unsafe lane changes, fails to signal, and swoops across several lanes of traffic while doing well over the speed limit.
Lemme see your driverless car handle that, then we'll see.
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.
As far as the automotive portion of this, they've overlooked a pretty critical detail: With the exception of navigation and car-control, the driver cannot be in a position to view moving video or flashy graphics--it's explicitly illegal to design a car in such a way that such garish distraction could catch the driver's eye at a critical moment.
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.
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.
Slashdot Mirror
The ruling doesn't ban the no fly list, it merely requires the government to make a suitable appeal process for those who are on the list. So you may expect the list to still be in use for quite a while. Additionally, Judge Brown is only on the Oregon district. So her ruling only applies to Oregon (however, it will be used as a precedent in other districts). All in all, it's still a very good ruling, but there's still a long ways to go.
solved using this. You might want to look at https://www.techdirt.com/artic...
In a nutshell, the Post Office has a customer base of only about 400 companies. The actual American public is lost in the noise as far as the Post Office is concerned.
Interesting article, however, I suspect the editors are a bit mistaken. I strongly suspect that Mr Delaire is NOT using TIG welding in his machine, but instead is using MIG welding. Also I have to wonder if Mr Delaire is aware of http://hardware.slashdot.org/s...
If not, he may be able to save a bit of effort and time by building upon the work someone else has already done.
You might want to do a bit of math before making such a statement. 700TB is a very large amount of data. And in order to do that in a week, would require quite a bit of data transfer bandwidth. To wit:
700,000,000,000,000 / 7 days = 100,000,000,000,000 / 24 hours = 4,166,666,666,666 / 3600 seconds = 1,157,407,407 bytes per second.
Do you really write 1.157GB/second every second for a week? And if so, what data interface are you using? I'd really like to know since SATA 3.0 can only handle 600MB/second. Perhaps you're using SATA 3.2 which does have the required speed?
Now in an environment using multiple drives, you can get to the 700TB mark much more rapidly with much lower per drive bandwidth. But then again, that's not the test criteria. They are testing how much endurance individual SSDs have.
Do you make it something that attaches to the outside of the skin for power (ie: a small battery)? Or cut the person open whenever the battery starts flaking out? If the latter, we have new members of the zipper club instantly.
Seems that such a device would be an ideal candidate for inductive coupling. Both for charging and data transmission. The device would consist of two parts. One part implanted into the body, and a second part held on the skin over the implant. That would avoid a semi-permanent skin penetration acting as an infection risk.
Not everyone is comfortable with public speaking. What you're complaining about is what is called "verbalized pauses" and almost all untrained speakers suffer from it to a degree or two when speaking publicly. Training, and practice with public speaking tends to eliminate that.
Unfortunately, that isn't likely to be true. A lot of Type I diabetes is, at its root, an autoimmune disease. The immune system goes crazy and kills off the islets of langerhans. So let's say you do get a grown pancreas from your own cells and have it transplanted. Well, your immune system then proceeds to kill of the islets of langerhans and you're back at square one.
Gee. Send the data in the clear along with an encryption key so it's stored at the remote site in an encrypted form. There's no way that a NLS will allow for the interception and disclosure of the key is there?
Frankly, that "solution" is a rather poor one at best and far too likely to give the customer a sense of security while in reality their data is totally accessible.
The comment on not using aerodynamic down force is rather telling. Only reason I can think of for not doing so is that if they did, it would consume power that could otherwise be used for more speed. And since motive power isn't being supplied through the wheels, traction isn't all that important. I do wonder if steering will be entirely via the wheels, or if they're using aerodynamic means.
It does address the issues you mentioned. As for the tool chain (compiler, linker, loader, etc), that is addressed by making them diverse. The term 'compile' means the entire chain from source to binary which includes the entire tool chain. As for the CPU issue, there's nothing in the source that mandates that you must create a binary for the same CPU as you're executing on. So do DDC on multiple CPU families (Intel, ARM, PPC, etc) and compare the final results. And the beauty of DDC is you can do it even if the tools you're using have been compromised. The only requirement is that the tools not be compromised in EXACTLY the same way. Any difference in the actual behavior of the tool chain will result in a difference in the output to be compared. If you're extremely paranoid, there's nothing preventing you from executing the tool chain inside an emulator to bypass any issues you might have with microcode.
You just might want to look 'Diverse Double-Compiling' as a method of countering the attack described by Ken Thompson in 'Reflections on Trusting Trust'. A paper on DDC is at http://www.acsa-admin.org/2005...
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.
I call it the aggressive, psychotic driver who makes random, unsafe lane changes, fails to signal, and swoops across several lanes of traffic while doing well over the speed limit.
Lemme see your driverless car handle that, then we'll see.
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.
As far as the automotive portion of this, they've overlooked a pretty critical detail: With the exception of navigation and car-control, the driver cannot be in a position to view moving video or flashy graphics--it's explicitly illegal to design a car in such a way that such garish distraction could catch the driver's eye at a critical moment.
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.