That it works even with GPS mode turned OFF on the phone is DIRECT evidence of poor security design.
No, the fact that third parties *found* the back door is direct evidence of poor security design. The fact that the backdoor was there is at least as likely to be an intentional measure for law enforcement purposes as it is to be a mistake. Odds are, when they "fix" this bug, the backdoor will still be there, just hidden a little better.
I would generally agree. If you're talking about data that never leaves the digital domain, you're correct. There's one exception, of course. If you have jitter in the clocking for an ADC, once the analog data is captured wrong, digital timing corrections can't readily correct it, though interpolation could to some degree.
That said, in this case, we're talking about pure digital data, which renders that argument moot. Clearly, any amount of timing jitter introduced in the digital domain can be corrected up until the point where you start getting bit errors, at which point the degradation would be so obvious that you would notice it immediately and you'd say the hardware was defective.
Off the top of my head, I can give you the implementation for 3 versions of quicksort.
Off the top of my head, I can explain to you the basic syntax differences between more than a dozen different programming languages. I can also, typically within just a few minutes of debugging, given a line of input that causes problems, fix a bug in a 44,000 LOC piece of software. With the exception of vacation time, I've never let an single bug in this code base reported by anyone else go unfixed for longer than 72 hours. I know which functions are in which files, and I know almost every major function name by memory, including what all of the dozens of debug switches do in the more complex chunks of code, which sections of code have been modified most recently, which sections of code are most likely to cause particular classes of problems based on historical failures, etc. All that info is being tracked inside my head.
And that's just a small part of what I do for a living. The other 95% of what I do is looking at *other people's* giant multi-thousand LOC software, analyzing the programming interfaces, intuiting how to use them, writing sample code, and explaining how it all works in plain English, all while looking for flaws in those interfaces, watching for security ramifications, considering how developers are likely to use the interfaces, and trying to figure out ways to enhance them to make them more developer-friendly.
In terms of what I do programming-wise, I'm too buried in the bigger picture to even see something as far down in the stack as a sort algorithm. As far as I'm concerned, that's something that I call, and assuming they didn't do something stupid, it should be fast enough. Half the time, that's not even something I call. That's something that something I call calls.
Could I implement quicksort? Sure. That said, I had to look it up in Wikipedia just to remind me which sort algorithm quicksort is. After all these years, that's so utterly unimportant a piece of information that it got paged out to long-term storage, the disk it was on crashed five years ago, and I didn't even notice until this post mentioned it.:-)
Actually, cadmium can be absorbed through the skin, though the rate of absorption is pretty low. Kids wearing it all day on a necklace, however, would be a concern even if you didn't have kids sticking charms in their mouths, which they do....
The bigger problem is that cadmium bioaccumulates very badly. The human body does a terrible job of removing it, with the typical biological half life measured in years. So if you are exposed to significant amounts of cadmium as a small child, a significant percentage of that cadmium is still active in your system well into adulthood.
Explain quicksort? Seriously? That borders on cruel unless they're straight out of college. Those of you who have been out in the workplace more than ten years, raise your hand if you still remember how to write quicksort without looking it up. Heck, half the quicksort algorithms I see published in textbooks have an off-by-one error and don't even work. It's quite possibly the most frequently botched algorithm ever. And you want somebody to explain it cold? You are one sick [expletive deleted].:-D
Besides, there's no useful reason to know quicksort unless you're applying for a job writing sort algorithms. For 99% of the programming jobs, all that really matters is that when you ask them what sorting algorithm they would use to sort a list of 10,000 items, they had better not say bubble sort or suggest implementing their own algorithm (which will invariably end up looking an awful lot like bubble sort). There are plenty of libraries out there for heapsort, quicksort, etc. that are so trivial to use that it makes knowledge of the algorithms at any depth largely unnecessary.
The purpose of teaching those algorithms is not to have people understand the algorithms themselves, but rather to serve as a gentle introduction into algorithmic complexity and the more broadly useful topics of binary trees and other link-structured data. Expecting people to memorize the details of a particular search algorithm is missing the whole point of why we learn about those algorithms in the first place.
Electrically, perhaps, but I'd expect the fissionable material and casing to last many millennia. That's the part that's hard to get. Replace the old explosive charges with explosives of similar yield, replace the electronics with a modern detonator, and replace the alpha emitter if necessary, and you have a nuclear weapon. In short, don't count on a short shelf life protecting anybody.
Wait, how do you compare something that has never been proven dangerous (power lines) to a manufacturing plant knowingly using a metal that is known to be both highly toxic and carcinogenic in children's toys?
Hate to tell you this, but it's not at all uncommon to see high end TV production use camcorders these days. Unless you're doing news, there's rarely an advantage to doing live switching. Why deal with all that unnecessary infrastructure if you don't have to?
Besides, the camcorder in question costs $21,000 and does 1080p. It's pretty clearly targeted to professional production. So yeah, I think that's a pretty likely candidate for 3D porn production....
Regarding the use of two cameras, that doesn't work very well unless you're intentionally trying to exaggerate the stereo effect. For natural-looking 3D imaging, the distance between the centers of the lenses should ideally be about the same as the distance between human eyes. As soon as you think about the constraints this places on the maximum size of the lenses and the cameras in question, you'll understand why I think the $21,000 Panasonic 3D "camcorder" would be a much better choice than trying to jury-rig two pro video cameras together....
At the extremely high end, I'd probably expect somebody to use a rig with two small lenses, some mirrors, and a 70mm camera or similar. I wouldn't expect anything in that order of magnitude expense-wise for porn production....
Oh, and regarding post production, unless you're doing special effects, that should pretty much be a non-issue. Your time code should be in sync between the multiple cameras, so you should be able to just edit one eye, export an EDL, sed the reel numbers if necessary, import it into a new project using the video from the other eye, batch recapture if you haven't already captured it, and render. Not counting the extra capture time, it should be something like five minutes flat, and if you capture in parallel, even that time mostly goes away.
Wasn't there just a story on Slashdot a couple of days ago about Panasonic releasing a new all-in-one 3D camcorder with dual lenses? Using two separate cameras is so 1985.
I remember reading about that iPhone problem. I suspect that it's a bug in the stock firmware for that chipset and that this is another one of those obnoxious flaws in the way the chipset vendors handle patches. As I understand it from talking to some cell phone engineers, when you start out with a chipset, you get a standard copy of the baseband firmware from the chipset manufacturer. I'll call that the baseline version. Patches from clients for cell firmware end up going into a separate tree for that specific client and are not typically propagated back upstream to the baseline, so every phone manufacturer who develops a phone using any given chipset ends up having to find and fix the same set of hundreds of baseband bugs over and over. If that's true, I'm amazed that the cell manufacturers put up with it. That certainly explains why cell phones have so many hundreds (or thousands) of baseband crasher bugs, and it also probably explains why Google is having to relearn all the stuff that Apple just learned a few months ago, and probably Nokia learned a few months before that, and so on.
Sad, really. Everyone suffers because of corporate paranoia and overly strong copyright protection on minor source code patches. Were the firmware an open source project, cellular communications would be in much better shape. Of course, the telecoms are terrified of that because then people would be running rogue baseband firmware, and the tower baseband software probably isn't much more robust than the cell phone baseband software is, so once again, corporate paranoia results in a poor customer experience. And to some degree, the cell companies probably like it this way because it makes it harder for new competitors to build phones that work.
Neither did Somalia, for all practical purposes. Didn't stop the U.S. from helping. Rwanda just got really unlucky in their timing, with the whole genocide happening just a month after the U.S. pulled out of Somalia, which was something of a disaster. And Rwaanda was basically exactly the same situation as Somalia---a civil war between warring factions. The U.S. and the U.N. had just failed miserably at stabilizing the first situation, and were still licking their wounds. Had they failed to learn from that experience and turned right around and made the same mistake, one could rightly have called them insane beyond all hope.
What happened in Rwanda was tragic. Knowing about it and being able to realistically stop it, however, are two different things. In the history of the world, attempts to interfere in a civil war have almost invariably ended badly, usually very badly. That's something that would be good for future political leaders to remember.
True, and worse, this is one of those fundamental flaws ("big bugs") that I mentioned previously, which cannot realistically be fixed in a short time, merely hacked around. The DNS protocol is brain damaged beyond all repair, and all the source port randomization in the world doesn't really change that; it just protects us until the next order of magnitude increase in network speeds, and then we're back where we started again.
That said, one of the reasons the Kaminsky bug was so quickly rediscovered by other researchers was that the fundamental underlying flaw was well understood, IIRC. That's pretty rare as far a security holes go. Usually when there's an underlying flaw that big, it gets fixed or the protocol flops like a lead balloon (were it anything but DNS, that is).
Either way, though, this demonstrated that CERT is an effective way to get things fixed, which I think proves my original point: real security researchers work through CERT or equivalent groups to get vulnerabilities fixed and disclosed in a responsible manner. People who don't are just attention whores.:-)
For those of you who are still skeptical, I had the vial tested by some Physicists from Alamogordo at the Trinity Test Site this year, and in Los Alamos with Geiger counters. It registers as radioactive... but then again, so does a banana. I forget how many rems it gives off, but it was not much higher than normal background radiation, and far lower than may other common things such as a smoke detector.
Wait... is this not much higher than normal background radiation here or the normal background radiation at Trinity Site? Because there is a difference....:-D
That's reason to disclose that there is a flaw, not to disclose what the flaw is. And if you can tell administrators a way to mitigate the problem without revealing the specifics of the problem, then there's no harm in disclosing that information immediately. Handing out the details of the flaw, however, does not benefit anyone unless the product is open source and you provide a patch. Even then, it's better to go through an established process like CERT to get the fix out to vendors so that on the day the fix goes into the public repository, the vendors can already have patched builds available.
Sadly, that seems to be pretty much true. If the fact that they won't actually prevent anything (because they can't scan inside body cavities), can cause DNA damage (by unzipping DNA strands), and are a major privacy violation isn't enough to prevent this multi-billion-dollar waste of taxpayer dollars from happening, nothing we can possibly say or do will prevent it, either. The only way this will stop is if we can convince enough people to stop flying. If these things went in and suddenly people said "screw you" and stopped flying, the airlines would push back on the government and this bullshit would stop. Until it hits the airlines in their pocketbooks---and hard---we will continue to see more and more of this invasive crap happening; the only thing that can stop it is public backlash sufficient to cause people to refuse to fly.
Slashdot Mirror
No, the fact that third parties *found* the back door is direct evidence of poor security design. The fact that the backdoor was there is at least as likely to be an intentional measure for law enforcement purposes as it is to be a mistake. Odds are, when they "fix" this bug, the backdoor will still be there, just hidden a little better.
I would generally agree. If you're talking about data that never leaves the digital domain, you're correct. There's one exception, of course. If you have jitter in the clocking for an ADC, once the analog data is captured wrong, digital timing corrections can't readily correct it, though interpolation could to some degree.
That said, in this case, we're talking about pure digital data, which renders that argument moot. Clearly, any amount of timing jitter introduced in the digital domain can be corrected up until the point where you start getting bit errors, at which point the degradation would be so obvious that you would notice it immediately and you'd say the hardware was defective.
Off the top of my head, I can explain to you the basic syntax differences between more than a dozen different programming languages. I can also, typically within just a few minutes of debugging, given a line of input that causes problems, fix a bug in a 44,000 LOC piece of software. With the exception of vacation time, I've never let an single bug in this code base reported by anyone else go unfixed for longer than 72 hours. I know which functions are in which files, and I know almost every major function name by memory, including what all of the dozens of debug switches do in the more complex chunks of code, which sections of code have been modified most recently, which sections of code are most likely to cause particular classes of problems based on historical failures, etc. All that info is being tracked inside my head.
And that's just a small part of what I do for a living. The other 95% of what I do is looking at *other people's* giant multi-thousand LOC software, analyzing the programming interfaces, intuiting how to use them, writing sample code, and explaining how it all works in plain English, all while looking for flaws in those interfaces, watching for security ramifications, considering how developers are likely to use the interfaces, and trying to figure out ways to enhance them to make them more developer-friendly.
In terms of what I do programming-wise, I'm too buried in the bigger picture to even see something as far down in the stack as a sort algorithm. As far as I'm concerned, that's something that I call, and assuming they didn't do something stupid, it should be fast enough. Half the time, that's not even something I call. That's something that something I call calls.
Could I implement quicksort? Sure. That said, I had to look it up in Wikipedia just to remind me which sort algorithm quicksort is. After all these years, that's so utterly unimportant a piece of information that it got paged out to long-term storage, the disk it was on crashed five years ago, and I didn't even notice until this post mentioned it. :-)
Actually, cadmium can be absorbed through the skin, though the rate of absorption is pretty low. Kids wearing it all day on a necklace, however, would be a concern even if you didn't have kids sticking charms in their mouths, which they do....
The bigger problem is that cadmium bioaccumulates very badly. The human body does a terrible job of removing it, with the typical biological half life measured in years. So if you are exposed to significant amounts of cadmium as a small child, a significant percentage of that cadmium is still active in your system well into adulthood.
It's better than posting them accidentally.
Explain quicksort? Seriously? That borders on cruel unless they're straight out of college. Those of you who have been out in the workplace more than ten years, raise your hand if you still remember how to write quicksort without looking it up. Heck, half the quicksort algorithms I see published in textbooks have an off-by-one error and don't even work. It's quite possibly the most frequently botched algorithm ever. And you want somebody to explain it cold? You are one sick [expletive deleted]. :-D
Besides, there's no useful reason to know quicksort unless you're applying for a job writing sort algorithms. For 99% of the programming jobs, all that really matters is that when you ask them what sorting algorithm they would use to sort a list of 10,000 items, they had better not say bubble sort or suggest implementing their own algorithm (which will invariably end up looking an awful lot like bubble sort). There are plenty of libraries out there for heapsort, quicksort, etc. that are so trivial to use that it makes knowledge of the algorithms at any depth largely unnecessary.
The purpose of teaching those algorithms is not to have people understand the algorithms themselves, but rather to serve as a gentle introduction into algorithmic complexity and the more broadly useful topics of binary trees and other link-structured data. Expecting people to memorize the details of a particular search algorithm is missing the whole point of why we learn about those algorithms in the first place.
Electrically, perhaps, but I'd expect the fissionable material and casing to last many millennia. That's the part that's hard to get. Replace the old explosive charges with explosives of similar yield, replace the electronics with a modern detonator, and replace the alpha emitter if necessary, and you have a nuclear weapon. In short, don't count on a short shelf life protecting anybody.
Wait, how do you compare something that has never been proven dangerous (power lines) to a manufacturing plant knowingly using a metal that is known to be both highly toxic and carcinogenic in children's toys?
I meant in connection with planting the weapons on the plane.
The theory that 9/11 was a controlled demolition is pretty absurd. That doesn't rule out the possibility that it was an inside job, though. After all, according to CNN, box cutters were found hidden under/in seats on planes that were scheduled to fly later that day. Investigators actually suggested at the time that it looked like an "inside job".
I'm puzzled why we haven't seen any arrests.
You're joking, right? It's 1080p. It costs more than my Toyota Rav4. Who do you think it's targeted at if not pros?
Hate to tell you this, but it's not at all uncommon to see high end TV production use camcorders these days. Unless you're doing news, there's rarely an advantage to doing live switching. Why deal with all that unnecessary infrastructure if you don't have to?
Besides, the camcorder in question costs $21,000 and does 1080p. It's pretty clearly targeted to professional production. So yeah, I think that's a pretty likely candidate for 3D porn production....
Regarding the use of two cameras, that doesn't work very well unless you're intentionally trying to exaggerate the stereo effect. For natural-looking 3D imaging, the distance between the centers of the lenses should ideally be about the same as the distance between human eyes. As soon as you think about the constraints this places on the maximum size of the lenses and the cameras in question, you'll understand why I think the $21,000 Panasonic 3D "camcorder" would be a much better choice than trying to jury-rig two pro video cameras together....
At the extremely high end, I'd probably expect somebody to use a rig with two small lenses, some mirrors, and a 70mm camera or similar. I wouldn't expect anything in that order of magnitude expense-wise for porn production....
Oh, and regarding post production, unless you're doing special effects, that should pretty much be a non-issue. Your time code should be in sync between the multiple cameras, so you should be able to just edit one eye, export an EDL, sed the reel numbers if necessary, import it into a new project using the video from the other eye, batch recapture if you haven't already captured it, and render. Not counting the extra capture time, it should be something like five minutes flat, and if you capture in parallel, even that time mostly goes away.
Wasn't there just a story on Slashdot a couple of days ago about Panasonic releasing a new all-in-one 3D camcorder with dual lenses? Using two separate cameras is so 1985.
http://www.prnewswire.com/news-releases/panasonic-unveils-worlds-first-integrated-full-hd-3d-camcorder-at-ces-2010-80854027.html
Are we back to the old joke about the mathematician and the physicist trying to measure a flagpole again?
I remember reading about that iPhone problem. I suspect that it's a bug in the stock firmware for that chipset and that this is another one of those obnoxious flaws in the way the chipset vendors handle patches. As I understand it from talking to some cell phone engineers, when you start out with a chipset, you get a standard copy of the baseband firmware from the chipset manufacturer. I'll call that the baseline version. Patches from clients for cell firmware end up going into a separate tree for that specific client and are not typically propagated back upstream to the baseline, so every phone manufacturer who develops a phone using any given chipset ends up having to find and fix the same set of hundreds of baseband bugs over and over. If that's true, I'm amazed that the cell manufacturers put up with it. That certainly explains why cell phones have so many hundreds (or thousands) of baseband crasher bugs, and it also probably explains why Google is having to relearn all the stuff that Apple just learned a few months ago, and probably Nokia learned a few months before that, and so on.
Sad, really. Everyone suffers because of corporate paranoia and overly strong copyright protection on minor source code patches. Were the firmware an open source project, cellular communications would be in much better shape. Of course, the telecoms are terrified of that because then people would be running rogue baseband firmware, and the tower baseband software probably isn't much more robust than the cell phone baseband software is, so once again, corporate paranoia results in a poor customer experience. And to some degree, the cell companies probably like it this way because it makes it harder for new competitors to build phones that work.
I'm so glad I don't work in telecom. *sigh*
No, really?
Have you seen their coverage maps? They make AT&T look good.
Neither did Somalia, for all practical purposes. Didn't stop the U.S. from helping. Rwanda just got really unlucky in their timing, with the whole genocide happening just a month after the U.S. pulled out of Somalia, which was something of a disaster. And Rwaanda was basically exactly the same situation as Somalia---a civil war between warring factions. The U.S. and the U.N. had just failed miserably at stabilizing the first situation, and were still licking their wounds. Had they failed to learn from that experience and turned right around and made the same mistake, one could rightly have called them insane beyond all hope.
What happened in Rwanda was tragic. Knowing about it and being able to realistically stop it, however, are two different things. In the history of the world, attempts to interfere in a civil war have almost invariably ended badly, usually very badly. That's something that would be good for future political leaders to remember.
It will still be more effective than spending it on millimeter wave scanners, banks, and U.S. car companies.
Generally correct, though in British English, collective nouns can take plural verbs.
http://en.wikipedia.org/wiki/American_and_British_English_differences
True, and worse, this is one of those fundamental flaws ("big bugs") that I mentioned previously, which cannot realistically be fixed in a short time, merely hacked around. The DNS protocol is brain damaged beyond all repair, and all the source port randomization in the world doesn't really change that; it just protects us until the next order of magnitude increase in network speeds, and then we're back where we started again.
That said, one of the reasons the Kaminsky bug was so quickly rediscovered by other researchers was that the fundamental underlying flaw was well understood, IIRC. That's pretty rare as far a security holes go. Usually when there's an underlying flaw that big, it gets fixed or the protocol flops like a lead balloon (were it anything but DNS, that is).
Either way, though, this demonstrated that CERT is an effective way to get things fixed, which I think proves my original point: real security researchers work through CERT or equivalent groups to get vulnerabilities fixed and disclosed in a responsible manner. People who don't are just attention whores. :-)
Won't happen until the first Girls Gone Wild: Airport Style hits the shelves. Then, the s**t's going to hit the fan.
Wait... is this not much higher than normal background radiation here or the normal background radiation at Trinity Site? Because there is a difference.... :-D
That's reason to disclose that there is a flaw, not to disclose what the flaw is. And if you can tell administrators a way to mitigate the problem without revealing the specifics of the problem, then there's no harm in disclosing that information immediately. Handing out the details of the flaw, however, does not benefit anyone unless the product is open source and you provide a patch. Even then, it's better to go through an established process like CERT to get the fix out to vendors so that on the day the fix goes into the public repository, the vendors can already have patched builds available.
Sadly, that seems to be pretty much true. If the fact that they won't actually prevent anything (because they can't scan inside body cavities), can cause DNA damage (by unzipping DNA strands), and are a major privacy violation isn't enough to prevent this multi-billion-dollar waste of taxpayer dollars from happening, nothing we can possibly say or do will prevent it, either. The only way this will stop is if we can convince enough people to stop flying. If these things went in and suddenly people said "screw you" and stopped flying, the airlines would push back on the government and this bullshit would stop. Until it hits the airlines in their pocketbooks---and hard---we will continue to see more and more of this invasive crap happening; the only thing that can stop it is public backlash sufficient to cause people to refuse to fly.