The idea is quite simple that they produce something similar to a taxi service at lower cost. The lower cost must come from somewhere. It mostly comes from taxi drivers having to pay extra money for driving people around in taxis, and these guys don't want to pay that extra money. For example, my (British) car insurance says that I'm not insured if I drive people around for money. If I do without getting different (more expensive) insurance, then I'm driving without insurance, which could bankrupt me and the passengers in case of an accident, and would get me into all kinds of trouble if caught.
The whole assumption that we should be discussing this for autonomous cars is a bit bizarre. There are millions and millions of cars driven by people, so we should discuss for them first.
And the article is a bit stupid because it forgets a few things: One, a crash with a bigger car is worse _for me_. Second, it's unlikely that two other drivers made mistakes simultaneously, so it would make a lot more sense to crash into the car whose driver caused the problem.
"virtually ANY change is highly disruptive"... you mean like replacing heirarchical menus with a dog's breakfast ribbon?
Before that: Arbitrary removal of menu items that the user hadn't been using in a while. Seems like an excellent idea (removing the clutter), but makes it impossible to find unused items. Until after ten minutes of search, clever users realise or ask someone who realises that Microsoft hides menu items.
My experience is that reading code isn't a very good way to catch bugs, mainly because reviewers tend not to read it as carefully as the person who wrote it. If you want to find bugs, it's more effective to do white/black box testing of some sort.
That depends. Your reading of code can have three possible results: 1. "There are no bugs". 2. "There are bugs A, B, C and D; go and fix them". 3. "I can't understand the code to a degree that I can say it is bug free".
In case 3, the code should be rejected unless it is code handling some really hard problem that needs a better reviewer. The area where the Heartbleed bug happened was in no way difficult, so code that is hard to understand should have been rejected. If that happens, reviews reduce the number of bugs.
In addition: Even good programmers make mistakes. However, good programmers can write code that even with mistakes either works or doesn't work but doesn't have hidden problems.
Rigorous testing is helpful, but I think it's the wrong approach. The problem here was lack of requirements and/or rigorous design.
The real problem is the horrible OpenSSL code, where after reading 10 lines, or 20 lines if you're really hard core, your eyes go just blurry and it's impossible to find any bugs.
There is the "thousands of open eyes" theory, where thousands of programmers can read the code and find bugs, and then they get fixed. If thousands of programmers tried to read the OpenSSL code with the degree of understanding necessary to declare it bug free, you wouldn't end up with any bugs found, but with thousands of programmers gone screaming mad.
This. It is high time that by default C compilers did buffer overrun check.
It has been claimed that due to OpenSSL's own memory management, this wasn't actually a buffer overrun. If you allocate 10 bytes for X, 5,000 bytes for Y, and 50,000 bytes for Z, but your proprietary allocator puts all these items into a 1MB malloc block, then copying 50,000 bytes from X isn't a buffer overrun to the compiler.
The real problem was that the code tried to respond to requests that it shouldn't have responded to. In this particular case, trying to respond could have triggered a buffer overflow, but in other cases, it might not.
This is kind of incompatible with doing all the extra work that coders are often expected to put in, when working in a startup.
You don't actually mean "extra work", you mean "extra hours". Which is not the same. Maximum productivity (not productivity per hour, but absolute maximum productivity) happens around 40 hours/week.
This was not a bug that would have been found in testing. It doesn't _attack_ the software. The software was totally unaffected. You could have a very specific test.for this problem, but if you thought of that test, you might as well have looked at the code and immediately spotted the problem.
Doesn't the master code get stored on Apple's iCloud network for iOS devices? I know it's optional to have it backed up there when using FileVault for OSX. Anyways, all the NSA has to do is subpoena the information from Apple and they're in like Flynn!
Doesn't get stored anywhere. FileVault for MacOS X works slightly different because it has no individual key built into the CPU. When you backup that key with Apple, you have to supply three security questions + answers and it looks like the answers are not stored but just used to encrypt / decrypt the key. Apple states that without the security answers, they are not capable of supplying the code.
Do a little googling... It seems Apple bypasses the OS to read the encrypted data directly, then does a brute-force attack on the passcode. Most people use a 4 digit numerical passcode, and very very few use more than 8 alphanumeric digits so brute forcing is usually a matter of minutes. There are third-party forensics tools that can do the same,
The trick is that only software signed by Apple is able to try out passcodes. When you enter a passcode say 1234, that passcode gets sent to Apple-signed software which then tries it out. Apple can obviously create Apple-signed software that tries any number of keys.
There are two obstacles for this: One, Apple needs a legal search warrant and the actual device. Two, passcode checking is designed to take about 1/10th of a second per key. So 4 digits can be cracked in 15 minutes. 8 digits would take months. 8 digits and letters are uncrackable. br
Third-party forensic tools can't do that unless they can jailbreak your phone, so update the OS to a version that cannot be jailbroken. Third-party tools tend to attack backups, but you can tell iTunes to make encrypted backups. (That also has the advantage that iTunes will backup passwords stored on the phone; it doesn't back them up to an unencrypted backup).
Fact is, you can't read the data on a locked iPhone. You _can_ read the data if you, as the owner, unlock the iPhone, for example for backing it up. But if the NSA gets your locked phone into their hands, there's nothing that they can do. All the data is _always_ read and written using hardware decryption.
In addition, apps can use further encryption on a per-file basis. Mail does that for most files, but apparently not for attachments. Additional encryption means for example that entering the key code is needed again for that kind of file. But files without that additional encryption still can't be read.
What the guy is complaining about is like sending unencrypted data over https, or putting unprotected documents into an unbreakable safe.
This is not correct. First of all, all devices have a life cycle. They wear out, they break, the screen cracks from a fall... with Apple's astronomical customer retention numbers pretty much everyone who owns an Apple device is going to replace it with a new Apple device.
Actually, you can choose to replace a broken iPad with an identical refurbished iPad for a lot less than a new one.
There is, it's why you have to pay a $150 service charge to replace the battery. The planned obsolescence is the lifespan of the battery. Which should be around 2 - 3 years.
You should switch to an iPad. Battery replacement by Apple is $99. Although I haven't heard of many people needing a replacement.
"A person riding a bicycle at 15 miles per hour (24 km per hour) burns 0.049 calories per pound per minute. So a 175-pound (77-kg) person burns 515 calories in an hour, or about 34 calories per mile (about 21 calories per km). A gallon of gasoline (about 4 liters) contains about 31,000 calories. If a person could drink gasoline, then a person could ride about 912 miles on a gallon of gas (about 360 km per liter).
A moped with a 50cc engine can do over 140 miles per gallon at much higher speed. Since fuel consumption is strongly related to the speed, I'm sure you could get more mileage at 15mph, especially if you design a moped for that speed. And most people will have a hard time riding a bicycle at 15mph for any length of time.
Where's the paradox, it's the same in science. Everyone wants to make the new discovery, nobody wants to review and verify them.
Verifying is easy. Checking and finding out that it doesn't work, not because you are too stupid to reproduce the experiment, but because it just doesn't work, that's the hard part. Plus you don't make friends doing that, obviously.
Exactly, because using software that makes it impossible for you to comply with the law means you get a "Get Out of Jail Free" card, right? Just wait until the bankers get ahold of this idea!
But you comply with the law. The law can require a service provider (like Lavabit) to give all the information that they have, even if it means being in breach of contract with their customer apparently. If you can't decrypt the information, then you complied with the law. If you can decrypt information, then you must decrypt it to comply with the law.
It's like two shops, one with a video camera running and one without. The shop with the video camera must hand recordings over to the police if there was a crime in front of the camera. The shop without the video camera doesn't need to do anything, and doesn't have to install a camera just in case someone gets stabbed in front of the shop.
Non removable battery isn't that much of a problem really. I've had plenty of phones (including iphones) and never changed a battery on any of them.
I changed the battery on my wife's Nokia phone. Guess what: Battery life was as bad as before... (nowhere near as good as when the phone was new). So she got a new phone.
That's the excuse that is being trotted out by our lords and masters. In that context, these moves make sense in their eyes. The debate is whether (a) whether the threat is real (b) it's enough to justify the intrusions by the state and (c) whether the state actually achieves anything by these intrusions. All these points are disputable, but it's unfair to dismiss them without consideration.
Fact: If a service provider is capable of giving my information to law enforcement when faced with a legally sound and fully justified search warrant, then they are capable of reading my information without any such warrant. Including information that they have no right or justification to access and that is highly sensitive and could be highly damaging to me if published.
Tried to post a comment on their site without having an account. Got an error 403 (forbidden). In other words, the guys creating their website and/or server software are clueless twats.
And every company wanting to avoid the fate of Lavabit must just make sure that they don't have the capability to decrypt customers' data. That way, the company and the customer are safe from law enforcement. (Hiring a lawyer at the right time also helps, and sending keys to a court in a 4 point font doesn't).
There is no LEGAL licensing restriction that prohibits you from building a Hackintosh. Trying to sell hackintoshes is another matter.
There is - the MacOS X license only allows running the software on Apple branded computers, and there is copy protection (which everyone can get around) which makes this fall under the DMCA.
On the other hand, there is the fact that Apple has never taken notice of anyone building their own Hackintosh. The only time they did take notice was with Psystar, and those guys effectively _forced_ Apple to take action.
Oh really? Do you know how many variations of video cards you get with nVidia and AMD alone? When I had a PC, I can tell you that an updated driver from either of them had a chance of making your video unusable to the point where you had to roll back to a previous driver. Add in drivers for Ethernet, sound, etc and and it's not pure speculation. It's fact. Apple has invested a great deal in customer support. Can you imagine the sheer number of appointments they would have to deal with for hardware problems that they had nothing to do with/ability to fix?
That _would_ be a good reason not to release MacOS X for PCs, but even if all PCs were absolutely 100% compatible to each other, Apple would still not release MacOS X for PCs for the reasons I said - because they make more money from selling Macs than they could make from selling operating systems.
Law enforcement (being allowed to lie) already uses the "we've had noise complaints" or "there was a X crime in the area" bullshit to harass people they have a "hunch" are up to no good.
"Being allowed to lie" means something different. Let's say you plan to smash in a car window. A person you don't know is watching you. The prudent person that you are, you ask them "are you a cop"? The answer is "No", you smash the car window, and the cop arrests you. That's the kind of lie a cop is allowed to make. Now let's say he turned his back on you, and you smashed the window without him seeing you, but he heard you, and there was nobody else who could have done it. Later in court the judge asks him "did you see this man smashing the car window" and he says "Yes". That's the kind of lie he isn't allowed to make.
Hmm, is there any proof of this smell? If not, it is equivalent to hearsay, wouldn't you say?
Hearsay is different. Hearsay happens when I say something outside the court, and obviously I'm allowed to talk a lot of nonsense outside the court, so when someone says in court what they heard me say, that may be evidence that I said it, but it isn't evidence that it is true. Here, the fact that the officer says "I smelled drugs" isn't evidence that there were drugs, but it is evidence that he indeed smelled drugs. And that is all he needs to search the car.
Slashdot Mirror
The idea is quite simple that they produce something similar to a taxi service at lower cost. The lower cost must come from somewhere. It mostly comes from taxi drivers having to pay extra money for driving people around in taxis, and these guys don't want to pay that extra money. For example, my (British) car insurance says that I'm not insured if I drive people around for money. If I do without getting different (more expensive) insurance, then I'm driving without insurance, which could bankrupt me and the passengers in case of an accident, and would get me into all kinds of trouble if caught.
The whole assumption that we should be discussing this for autonomous cars is a bit bizarre. There are millions and millions of cars driven by people, so we should discuss for them first.
And the article is a bit stupid because it forgets a few things: One, a crash with a bigger car is worse _for me_. Second, it's unlikely that two other drivers made mistakes simultaneously, so it would make a lot more sense to crash into the car whose driver caused the problem.
"virtually ANY change is highly disruptive"... you mean like replacing heirarchical menus with a dog's breakfast ribbon?
Before that: Arbitrary removal of menu items that the user hadn't been using in a while. Seems like an excellent idea (removing the clutter), but makes it impossible to find unused items. Until after ten minutes of search, clever users realise or ask someone who realises that Microsoft hides menu items.
My experience is that reading code isn't a very good way to catch bugs, mainly because reviewers tend not to read it as carefully as the person who wrote it. If you want to find bugs, it's more effective to do white/black box testing of some sort.
That depends. Your reading of code can have three possible results: 1. "There are no bugs". 2. "There are bugs A, B, C and D; go and fix them". 3. "I can't understand the code to a degree that I can say it is bug free".
In case 3, the code should be rejected unless it is code handling some really hard problem that needs a better reviewer. The area where the Heartbleed bug happened was in no way difficult, so code that is hard to understand should have been rejected. If that happens, reviews reduce the number of bugs.
In addition: Even good programmers make mistakes. However, good programmers can write code that even with mistakes either works or doesn't work but doesn't have hidden problems.
Rigorous testing is helpful, but I think it's the wrong approach. The problem here was lack of requirements and/or rigorous design.
The real problem is the horrible OpenSSL code, where after reading 10 lines, or 20 lines if you're really hard core, your eyes go just blurry and it's impossible to find any bugs.
There is the "thousands of open eyes" theory, where thousands of programmers can read the code and find bugs, and then they get fixed. If thousands of programmers tried to read the OpenSSL code with the degree of understanding necessary to declare it bug free, you wouldn't end up with any bugs found, but with thousands of programmers gone screaming mad.
This. It is high time that by default C compilers did buffer overrun check.
It has been claimed that due to OpenSSL's own memory management, this wasn't actually a buffer overrun. If you allocate 10 bytes for X, 5,000 bytes for Y, and 50,000 bytes for Z, but your proprietary allocator puts all these items into a 1MB malloc block, then copying 50,000 bytes from X isn't a buffer overrun to the compiler.
The real problem was that the code tried to respond to requests that it shouldn't have responded to. In this particular case, trying to respond could have triggered a buffer overflow, but in other cases, it might not.
This is kind of incompatible with doing all the extra work that coders are often expected to put in, when working in a startup.
You don't actually mean "extra work", you mean "extra hours". Which is not the same. Maximum productivity (not productivity per hour, but absolute maximum productivity) happens around 40 hours/week.
like lack of QA / testing
This was not a bug that would have been found in testing. It doesn't _attack_ the software. The software was totally unaffected. You could have a very specific test.for this problem, but if you thought of that test, you might as well have looked at the code and immediately spotted the problem.
Jesus, it's 30%? I thought it was 10%. Sickening.
You should open a shop and sell everything 10% above what you pay for the goods yourself. People will love your shop, until you go bankrupt.
Doesn't the master code get stored on Apple's iCloud network for iOS devices? I know it's optional to have it backed up there when using FileVault for OSX. Anyways, all the NSA has to do is subpoena the information from Apple and they're in like Flynn!
Doesn't get stored anywhere. FileVault for MacOS X works slightly different because it has no individual key built into the CPU. When you backup that key with Apple, you have to supply three security questions + answers and it looks like the answers are not stored but just used to encrypt / decrypt the key. Apple states that without the security answers, they are not capable of supplying the code.
Do a little googling... It seems Apple bypasses the OS to read the encrypted data directly, then does a brute-force attack on the passcode. Most people use a 4 digit numerical passcode, and very very few use more than 8 alphanumeric digits so brute forcing is usually a matter of minutes. There are third-party forensics tools that can do the same,
The trick is that only software signed by Apple is able to try out passcodes. When you enter a passcode say 1234, that passcode gets sent to Apple-signed software which then tries it out. Apple can obviously create Apple-signed software that tries any number of keys.
There are two obstacles for this: One, Apple needs a legal search warrant and the actual device. Two, passcode checking is designed to take about 1/10th of a second per key. So 4 digits can be cracked in 15 minutes. 8 digits would take months. 8 digits and letters are uncrackable.
br Third-party forensic tools can't do that unless they can jailbreak your phone, so update the OS to a version that cannot be jailbroken. Third-party tools tend to attack backups, but you can tell iTunes to make encrypted backups. (That also has the advantage that iTunes will backup passwords stored on the phone; it doesn't back them up to an unencrypted backup).
Fact is, you can't read the data on a locked iPhone. You _can_ read the data if you, as the owner, unlock the iPhone, for example for backing it up. But if the NSA gets your locked phone into their hands, there's nothing that they can do. All the data is _always_ read and written using hardware decryption.
In addition, apps can use further encryption on a per-file basis. Mail does that for most files, but apparently not for attachments. Additional encryption means for example that entering the key code is needed again for that kind of file. But files without that additional encryption still can't be read.
What the guy is complaining about is like sending unencrypted data over https, or putting unprotected documents into an unbreakable safe.
This is not correct. First of all, all devices have a life cycle. They wear out, they break, the screen cracks from a fall... with Apple's astronomical customer retention numbers pretty much everyone who owns an Apple device is going to replace it with a new Apple device.
Actually, you can choose to replace a broken iPad with an identical refurbished iPad for a lot less than a new one.
There is, it's why you have to pay a $150 service charge to replace the battery. The planned obsolescence is the lifespan of the battery. Which should be around 2 - 3 years.
You should switch to an iPad. Battery replacement by Apple is $99. Although I haven't heard of many people needing a replacement.
"A person riding a bicycle at 15 miles per hour (24 km per hour) burns 0.049 calories per pound per minute. So a 175-pound (77-kg) person burns 515 calories in an hour, or about 34 calories per mile (about 21 calories per km). A gallon of gasoline (about 4 liters) contains about 31,000 calories. If a person could drink gasoline, then a person could ride about 912 miles on a gallon of gas (about 360 km per liter).
A moped with a 50cc engine can do over 140 miles per gallon at much higher speed. Since fuel consumption is strongly related to the speed, I'm sure you could get more mileage at 15mph, especially if you design a moped for that speed. And most people will have a hard time riding a bicycle at 15mph for any length of time.
Where's the paradox, it's the same in science. Everyone wants to make the new discovery, nobody wants to review and verify them.
Verifying is easy. Checking and finding out that it doesn't work, not because you are too stupid to reproduce the experiment, but because it just doesn't work, that's the hard part. Plus you don't make friends doing that, obviously.
Exactly, because using software that makes it impossible for you to comply with the law means you get a "Get Out of Jail Free" card, right? Just wait until the bankers get ahold of this idea!
But you comply with the law. The law can require a service provider (like Lavabit) to give all the information that they have, even if it means being in breach of contract with their customer apparently. If you can't decrypt the information, then you complied with the law. If you can decrypt information, then you must decrypt it to comply with the law.
It's like two shops, one with a video camera running and one without. The shop with the video camera must hand recordings over to the police if there was a crime in front of the camera. The shop without the video camera doesn't need to do anything, and doesn't have to install a camera just in case someone gets stabbed in front of the shop.
Non removable battery isn't that much of a problem really. I've had plenty of phones (including iphones) and never changed a battery on any of them.
I changed the battery on my wife's Nokia phone. Guess what: Battery life was as bad as before... (nowhere near as good as when the phone was new). So she got a new phone.
That's the excuse that is being trotted out by our lords and masters. In that context, these moves make sense in their eyes. The debate is whether (a) whether the threat is real (b) it's enough to justify the intrusions by the state and (c) whether the state actually achieves anything by these intrusions. All these points are disputable, but it's unfair to dismiss them without consideration.
Fact: If a service provider is capable of giving my information to law enforcement when faced with a legally sound and fully justified search warrant, then they are capable of reading my information without any such warrant. Including information that they have no right or justification to access and that is highly sensitive and could be highly damaging to me if published.
Tried to post a comment on their site without having an account. Got an error 403 (forbidden). In other words, the guys creating their website and/or server software are clueless twats.
And every company wanting to avoid the fate of Lavabit must just make sure that they don't have the capability to decrypt customers' data. That way, the company and the customer are safe from law enforcement. (Hiring a lawyer at the right time also helps, and sending keys to a court in a 4 point font doesn't).
There is no LEGAL licensing restriction that prohibits you from building a Hackintosh. Trying to sell hackintoshes is another matter.
There is - the MacOS X license only allows running the software on Apple branded computers, and there is copy protection (which everyone can get around) which makes this fall under the DMCA.
On the other hand, there is the fact that Apple has never taken notice of anyone building their own Hackintosh. The only time they did take notice was with Psystar, and those guys effectively _forced_ Apple to take action.
Oh really? Do you know how many variations of video cards you get with nVidia and AMD alone? When I had a PC, I can tell you that an updated driver from either of them had a chance of making your video unusable to the point where you had to roll back to a previous driver. Add in drivers for Ethernet, sound, etc and and it's not pure speculation. It's fact. Apple has invested a great deal in customer support. Can you imagine the sheer number of appointments they would have to deal with for hardware problems that they had nothing to do with/ability to fix?
That _would_ be a good reason not to release MacOS X for PCs, but even if all PCs were absolutely 100% compatible to each other, Apple would still not release MacOS X for PCs for the reasons I said - because they make more money from selling Macs than they could make from selling operating systems.
Law enforcement (being allowed to lie) already uses the "we've had noise complaints" or "there was a X crime in the area" bullshit to harass people they have a "hunch" are up to no good.
"Being allowed to lie" means something different. Let's say you plan to smash in a car window. A person you don't know is watching you. The prudent person that you are, you ask them "are you a cop"? The answer is "No", you smash the car window, and the cop arrests you. That's the kind of lie a cop is allowed to make. Now let's say he turned his back on you, and you smashed the window without him seeing you, but he heard you, and there was nobody else who could have done it. Later in court the judge asks him "did you see this man smashing the car window" and he says "Yes". That's the kind of lie he isn't allowed to make.
"reasonable" is a very, very difficult word for humans. They like much more the "all or nothing" concept.
It's not difficult for humans. It's difficult for slashdotters.
Hmm, is there any proof of this smell? If not, it is equivalent to hearsay, wouldn't you say?
Hearsay is different. Hearsay happens when I say something outside the court, and obviously I'm allowed to talk a lot of nonsense outside the court, so when someone says in court what they heard me say, that may be evidence that I said it, but it isn't evidence that it is true. Here, the fact that the officer says "I smelled drugs" isn't evidence that there were drugs, but it is evidence that he indeed smelled drugs. And that is all he needs to search the car.