The human brain runs on about twenty watts. The computational power required to match it is barely imaginable.
AlphaGo required megawatt-hours of energy to learn to play Go well enough to beat Lee Se-dol. But how much did Lee Se-dol's brain consume in the ~20 years that he spent learning, not to mention the energy expended by the brains of his opponents (remember that much of AlphaGo's education was from playing against itself)? Supposing Lee Se-dol spent 2000 hours per year on Go for 20 years, that's about 800 kWh, plus some more for the energy expended by his opponents. AlphaGo's education required more energy input than Lee Se-dol's, but it's probably an order of magnitude more, maybe two. Not three or four. Switching from general-purpose to special-purpose hardware will probably get us to the same order of magnitude.
That said, my guess is that you're right that we're still a long way from physics-imposed limitations. My guess is that current technology would already be capable of building something vastly more efficient than a human brain... if only we knew what to build. We're learning.
So for a self-driving car to work, there are two choices: either figure out how to make better maps, or create a much smarter car than the one they have now.
Or, option 3, only self-drive in known areas. Yes, this will somewhat limit the vehicle's utility, but not very much, and it would know whether there's a potential problem as soon as you set the destination.
I can't decide who Google is trying to help with this.
You're overthinking this. Google is trying to do exactly what it says it's trying to do: Make Gmail more secure for Gmail users. After investing a lot in making its own servers use encryption for every communication, inside and outside, it really bugs Google engineers that they then have to send plaintext to other mail servers whose administrators don't care enough about security to install SSMTP. Then someone realized that Google has an avenue to pressure other mail providers to step up and that Google can highlight the effort it's put into security at the same time. Win/win: Google makes the world better and looks good doing it.
Why are you looking for some deeper reasons, when the obvious and plainly-stated ones perfectly explain the move?
(Disclosure: I'm a Google security engineer, though I'm speaking only for myself. If you want an official company position, look at press releases or contact PR.)
Complaining about lack of TLS on the connection is about encrypting the link, not the email. Certainly, email in transit really must be encrypted. But the email itself still sits in the clear on the ISP or email provider's server unless otherwise noted. That's still a problem.
Clearly, email in clear at the ISP is vulnerable if the ISP is hacked, and to employees of the ISP, etc. But unencrypted e-mail in transit is vulnerable to many people at many locations all along the connection path. End-to-end encryption is better, than encryption only on the wire but it's much better than plaintext on the wire.
So along the lines of what i would have called zeroing memory. I just have my doubts they use this. Even $10 per devices ends up being quite a lot of price difference, or profit loss.
$50 Android phones have RPMB. I see no reason Apple wouldn't use it.
Statistical cherry-picking is a great concise explanation of the problem. I wish I'd used it. What happened here is almost worse than cherry-picking, though, since it seems to have been more clueless than targeted. It appears that what Glassdoor did was run the numbers, sort by gender gap (ignoring questions of sample size) and then shout about the one that came out on top. It would actually be very surprising if none of the small categories turned out to show some extreme behavior.
Really, what's more interesting is some of the other high-disparity jobs that do have a sufficiently-large sample size to make you think there's a chance that the data is good. Such as "C Suite" (870 reports, 27.7%), "Pharmacist" (904 reports, 21.8%) and "CAD Designer" (1044 reports, 21.5%). A gender gap among pharmacists seems particularly surprising to me.
Though you still have to keep in mind that this is all subject to really significant bias, since the data is all self-reported by self-selected people.
Coding, at least if you include the full range of what software developers do, is a very creative profession. Yes, it also has elements of extreme detail orientation which some people think is not consistent with creativity... but have you ever talked to an artist about the details of their work? They obsess to a degree that makes my eyes glaze over, probably much the way they'd glaze if I went on about the criticality of code organization and naming.
This is a terrible summary, though in this case the fault lies with Glassdoor's summary of their own data, rather than slashdot.
If you look at the details in the appendix, you'll see that their sample size for the "Computer Programmer" title was only 138, as compared to 2330 "Software Architects", 3525 "Front-end Engineers", 13461 "Software Engineers", 2199 "Programmer Developers", etc. All of those other job categories had much lower gender pay gaps in the 4-6% range. That's still too large, but it's much better than 28%.
So what really happened here was that the report analyzed based on self-reported job titles and it so happened that a very rarely-used title, computer programmer, with a small sample size, just happened to have an extreme gender pay difference. Personally, I wonder what kind of company calls their people "computer programmers". In my 25 year career I've had a variety of titles, including "Software developer", "Software engineer", "Software architect", "I/T specialist", "I/T architect", "Software team lead", etc. with various other tags attached like "junior", "senior", "consulting" and so on. I have never, ever had "computer programmer" as my official title, and never known anyone else with that title either.
True, but I have no doubt that Google's team could automate it and make it smooth, if it can be done. Macbooks will Netboot, so from there it's just a matter of writing a good script. Unless random component differences mean that some units just won't work, because they contain some piece of hardware for which there are no good drivers.
So you're claiming that a company who specializes in helping government break into phones and do a forensic analysis on phones would rather take a meager bug bounty than potentially earn millions by aiding government spying and investigation? Yes that makes perfect sense. Do these NYT authors know that NASA is hiring rocket scientists?
While you're right, that doesn't change the fact that Apple is foolish for not running a bug bounty program. It's not a question of engaging in a "financial arms race", it's about creating an incentive for external researchers to help you improve your product. You can spend $250K annually to hire one good researcher who will spend all of his time exploring a small number of attack vectors, or for the same amount of money you can get the benefits of the part-time work of dozens of good people exploring a large number of attack vectors. The latter will be a lot more effective. Or you can spend, say, $5M annually to hire your own large team and probably find more bugs internally than are reported externally... but you will still get many more, and very cheaply, if you offer a bounty.
Vulnerability research isn't a simple matter of X person hours yield Y benefit. It depends tremendously on the avenues explored and the clever ideas the researcher has... and even the best researchers have, individually, a limited number of clever ideas and novel approaches. More (qualified) eyes are better, even if each pair is looking less.
Bug bounties are also a really good practice just to sweep up all of the low-hanging fruit. If you offer $10K, you'll get all of the vulns that would sell to reputable buyers for that much or less, and those that would sell for two or three times that much to shady buyers. You won't get the $100K or $1M bugs, sure, but you'll still get very good value for your money.
I wonder if Apple doesn't have another concern, though, which is that perhaps they don't want to make iOS too secure. While they don't want to offer a legitimate way to root their devices, they may also not want to completely shut out the fairly large minority of iOS users who jailbreak. So they may want to leave some low-hanging fruit. That would be harder if all of that low-hanging fruit were consistently reported through an official channel. I'm obviously speculating here, and probably completely off base.
(Aside: I think it's going to be interesting to see what happens in the Android world over the next couple of years, because SELinux, monthly patch cycles, verified boot and a few other security improvements are moving us to a state where many Android devices -- perhaps nearly all of them from first tier OEMs -- will be unrootable. Some of them are there now. Will this provoke people to buy unlockable devices (e.g., Nexus), or will it encourage them to switch to iOS so they can jailbreak?)
(Disclaimer: I work for Google but I'm speaking only for myself. Any correspondence between my views and official company positions is coincidental, and probably means that the company should re-think.)
When I worked at the Google help desk in 2008, the powers to be were talking about moving away from the Lenovo laptops because they suspected that the Chinese government were putting a backdoor into the BIOS. When I did contract work for a Google data center in 2011, the only laptops I saw were MacBook Pros from Apple.
Google still uses PC laptops from a couple of vendors, as well as Macbooks and, obviously, Chromebooks. Employees pick which they want. They can pick a PC laptop with Linux or Windows, a Macbook with OS X, or a Chromebook. The most common choice is the Macbook, not due to security concerns, but because people really like Apple hardware. If Linux were offered on Macbooks, there probably wouldn't be any PC laptops around. As it is, those who want to run Windows (rare) or a regular Linux system (not ChromeOS), have to go with the PC. Those who like or are willing to live with OS X get a Macbook, and those who only need/want a browser go the Chromebook route (which is actually pretty popular).
(I'm typing this on my Google-issued Macbook, which I wish was running Ubuntu or Debian, but I make do with OS X)
According to the court documents, the entire purpose of cracking this phone is to determine if charges need to be brought against other people. In other words the intent IS to use this in a criminal trial if such cooperation is found on the phone.
Your second sentence doesn't follow from your first. Yes, they're (allegedly) looking for conspirators. But information on the phone could identify conspirators without providing evidence against them that can be used to convict them. For example, it could just contain their e-mail addresses or phone numbers. That would be useless in court, but useful to investigators who would then look into the identified individuals and seek to gather evidence. With or without a tight chain of custody, information on the phone would be useful in obtaining search warrants.
The FBI and half the world has been arguing both sides of this. The FBI says in court documents they absolutely need this to find out if there are other conspirators. In public they talk about needing the ability to combat terrorism. Both arguments are lies, this is about precedent and always has been.
Oh, absolutely. And once they realized they were going to lose and the precedent was going to go against them, they decided on the current strategy to save face. Next they'll announce that Cellebrite cracked the phone but there was nothing useful on it.
MWM has it, SGI's 4Dwm had it, CDE (Common Desktop Environment, used by Sun and others) had it.
MWM may have had tearable menus first, not sure, but the first place I saw them was on NeXTstep, in 1990. One of many good ideas that Apple discarded when they turned NeXTstep into OS X.
How do you maintain chain of custody of the evidence if you hand it over to a company that's not governed by our laws?
That's not a problem, for at least two reasons.
First, chain of custody doesn't matter unless you want to use the information recovered as evidence in a trial. If you just use it to generate leads which you then use to find other suspects and evidence, then it's irrelevant if chain of custody was maintained.
Second, chain of custody is easy to maintain. Location and nationality don't affect chain of custody. What matters is that you have a documented chain and can prove that custody was maintained and access was controlled at each step. Worst case is that employees of the Israeli company may have to fly to the US and testify in court to substantiate the chain of custody, and to explain how they extracted the information. I'm sure the company would be happy to do that if the FBI paid them to (which would be an additional fee).
You think? The DMCA does try to ban circumvention of security measures that are used to protect copyright, but I don't think that's the case here. The DMCA doesn't ban general breaking of security.
We continue to print $1 paper bills LONG after it's been successfully proved by other Western commercial societies that 1-unit, 2-unit, and even 5-unit coins make far more sense.
Ugh. I don't like paper cash, but I hate coins. On the rare occasions I use cash, when I get coins in change I generally give them back, drop them in the "penny cup", or look for a beggar to give them to. I just don't want to carry the heavy, jingly things. At least US coinage is small and relatively lightweight. Dealing with the larger, heavier and generally more-used coins in other countries is one of my least favorite parts of international travel.
Slashdot Mirror
The human brain runs on about twenty watts. The computational power required to match it is barely imaginable.
AlphaGo required megawatt-hours of energy to learn to play Go well enough to beat Lee Se-dol. But how much did Lee Se-dol's brain consume in the ~20 years that he spent learning, not to mention the energy expended by the brains of his opponents (remember that much of AlphaGo's education was from playing against itself)? Supposing Lee Se-dol spent 2000 hours per year on Go for 20 years, that's about 800 kWh, plus some more for the energy expended by his opponents. AlphaGo's education required more energy input than Lee Se-dol's, but it's probably an order of magnitude more, maybe two. Not three or four. Switching from general-purpose to special-purpose hardware will probably get us to the same order of magnitude.
That said, my guess is that you're right that we're still a long way from physics-imposed limitations. My guess is that current technology would already be capable of building something vastly more efficient than a human brain... if only we knew what to build. We're learning.
Next thing you know we'll be outlawing stupid, flippant and ignorant.
That's not possible - Congress always exempts itself from laws!
That's why "flippant" was included. Congress is very staid and serious about their stupidity and ignorance.
So for a self-driving car to work, there are two choices: either figure out how to make better maps, or create a much smarter car than the one they have now.
Or, option 3, only self-drive in known areas. Yes, this will somewhat limit the vehicle's utility, but not very much, and it would know whether there's a potential problem as soon as you set the destination.
I can't decide who Google is trying to help with this.
You're overthinking this. Google is trying to do exactly what it says it's trying to do: Make Gmail more secure for Gmail users. After investing a lot in making its own servers use encryption for every communication, inside and outside, it really bugs Google engineers that they then have to send plaintext to other mail servers whose administrators don't care enough about security to install SSMTP. Then someone realized that Google has an avenue to pressure other mail providers to step up and that Google can highlight the effort it's put into security at the same time. Win/win: Google makes the world better and looks good doing it.
Why are you looking for some deeper reasons, when the obvious and plainly-stated ones perfectly explain the move?
(Disclosure: I'm a Google security engineer, though I'm speaking only for myself. If you want an official company position, look at press releases or contact PR.)
Complaining about lack of TLS on the connection is about encrypting the link, not the email. Certainly, email in transit really must be encrypted. But the email itself still sits in the clear on the ISP or email provider's server unless otherwise noted. That's still a problem.
Clearly, email in clear at the ISP is vulnerable if the ISP is hacked, and to employees of the ISP, etc. But unencrypted e-mail in transit is vulnerable to many people at many locations all along the connection path. End-to-end encryption is better, than encryption only on the wire but it's much better than plaintext on the wire.
So along the lines of what i would have called zeroing memory. I just have my doubts they use this. Even $10 per devices ends up being quite a lot of price difference, or profit loss.
$50 Android phones have RPMB. I see no reason Apple wouldn't use it.
Statistical cherry-picking is a great concise explanation of the problem. I wish I'd used it. What happened here is almost worse than cherry-picking, though, since it seems to have been more clueless than targeted. It appears that what Glassdoor did was run the numbers, sort by gender gap (ignoring questions of sample size) and then shout about the one that came out on top. It would actually be very surprising if none of the small categories turned out to show some extreme behavior.
Really, what's more interesting is some of the other high-disparity jobs that do have a sufficiently-large sample size to make you think there's a chance that the data is good. Such as "C Suite" (870 reports, 27.7%), "Pharmacist" (904 reports, 21.8%) and "CAD Designer" (1044 reports, 21.5%). A gender gap among pharmacists seems particularly surprising to me.
Though you still have to keep in mind that this is all subject to really significant bias, since the data is all self-reported by self-selected people.
Methinks people are confusing chain of custody with illegal search.
That could well be. I've certainly seen that mistake made before.
Coding, at least if you include the full range of what software developers do, is a very creative profession. Yes, it also has elements of extreme detail orientation which some people think is not consistent with creativity... but have you ever talked to an artist about the details of their work? They obsess to a degree that makes my eyes glaze over, probably much the way they'd glaze if I went on about the criticality of code organization and naming.
Can anyone else make sense of this?
See the appendix, and my post explaining what went wrong with their analysis of their data.
This is a terrible summary, though in this case the fault lies with Glassdoor's summary of their own data, rather than slashdot.
If you look at the details in the appendix, you'll see that their sample size for the "Computer Programmer" title was only 138, as compared to 2330 "Software Architects", 3525 "Front-end Engineers", 13461 "Software Engineers", 2199 "Programmer Developers", etc. All of those other job categories had much lower gender pay gaps in the 4-6% range. That's still too large, but it's much better than 28%.
So what really happened here was that the report analyzed based on self-reported job titles and it so happened that a very rarely-used title, computer programmer, with a small sample size, just happened to have an extreme gender pay difference. Personally, I wonder what kind of company calls their people "computer programmers". In my 25 year career I've had a variety of titles, including "Software developer", "Software engineer", "Software architect", "I/T specialist", "I/T architect", "Software team lead", etc. with various other tags attached like "junior", "senior", "consulting" and so on. I have never, ever had "computer programmer" as my official title, and never known anyone else with that title either.
True, but I have no doubt that Google's team could automate it and make it smooth, if it can be done. Macbooks will Netboot, so from there it's just a matter of writing a good script. Unless random component differences mean that some units just won't work, because they contain some piece of hardware for which there are no good drivers.
So you're claiming that a company who specializes in helping government break into phones and do a forensic analysis on phones would rather take a meager bug bounty than potentially earn millions by aiding government spying and investigation? Yes that makes perfect sense. Do these NYT authors know that NASA is hiring rocket scientists?
While you're right, that doesn't change the fact that Apple is foolish for not running a bug bounty program. It's not a question of engaging in a "financial arms race", it's about creating an incentive for external researchers to help you improve your product. You can spend $250K annually to hire one good researcher who will spend all of his time exploring a small number of attack vectors, or for the same amount of money you can get the benefits of the part-time work of dozens of good people exploring a large number of attack vectors. The latter will be a lot more effective. Or you can spend, say, $5M annually to hire your own large team and probably find more bugs internally than are reported externally... but you will still get many more, and very cheaply, if you offer a bounty.
Vulnerability research isn't a simple matter of X person hours yield Y benefit. It depends tremendously on the avenues explored and the clever ideas the researcher has... and even the best researchers have, individually, a limited number of clever ideas and novel approaches. More (qualified) eyes are better, even if each pair is looking less.
Bug bounties are also a really good practice just to sweep up all of the low-hanging fruit. If you offer $10K, you'll get all of the vulns that would sell to reputable buyers for that much or less, and those that would sell for two or three times that much to shady buyers. You won't get the $100K or $1M bugs, sure, but you'll still get very good value for your money.
I wonder if Apple doesn't have another concern, though, which is that perhaps they don't want to make iOS too secure. While they don't want to offer a legitimate way to root their devices, they may also not want to completely shut out the fairly large minority of iOS users who jailbreak. So they may want to leave some low-hanging fruit. That would be harder if all of that low-hanging fruit were consistently reported through an official channel. I'm obviously speculating here, and probably completely off base.
(Aside: I think it's going to be interesting to see what happens in the Android world over the next couple of years, because SELinux, monthly patch cycles, verified boot and a few other security improvements are moving us to a state where many Android devices -- perhaps nearly all of them from first tier OEMs -- will be unrootable. Some of them are there now. Will this provoke people to buy unlockable devices (e.g., Nexus), or will it encourage them to switch to iOS so they can jailbreak?)
(Disclaimer: I work for Google but I'm speaking only for myself. Any correspondence between my views and official company positions is coincidental, and probably means that the company should re-think.)
I'm typing this on my Google-issued Macbook, which I wish was running Ubuntu or Debian, but I make do with OS X
I'm surprised that Goobuntu doesn't run on a Mac.
Me too. I don't have any plausible theories as to why that isn't an option.
A coworker was running Mint on his work MBP, but I think he's running QubesOS now.
I didn't mean to say it's not possible to run Linux on Macbooks, just that it's not allowed/supported at Google.
When I worked at the Google help desk in 2008, the powers to be were talking about moving away from the Lenovo laptops because they suspected that the Chinese government were putting a backdoor into the BIOS. When I did contract work for a Google data center in 2011, the only laptops I saw were MacBook Pros from Apple.
Google still uses PC laptops from a couple of vendors, as well as Macbooks and, obviously, Chromebooks. Employees pick which they want. They can pick a PC laptop with Linux or Windows, a Macbook with OS X, or a Chromebook. The most common choice is the Macbook, not due to security concerns, but because people really like Apple hardware. If Linux were offered on Macbooks, there probably wouldn't be any PC laptops around. As it is, those who want to run Windows (rare) or a regular Linux system (not ChromeOS), have to go with the PC. Those who like or are willing to live with OS X get a Macbook, and those who only need/want a browser go the Chromebook route (which is actually pretty popular).
(I'm typing this on my Google-issued Macbook, which I wish was running Ubuntu or Debian, but I make do with OS X)
According to the court documents, the entire purpose of cracking this phone is to determine if charges need to be brought against other people. In other words the intent IS to use this in a criminal trial if such cooperation is found on the phone.
Your second sentence doesn't follow from your first. Yes, they're (allegedly) looking for conspirators. But information on the phone could identify conspirators without providing evidence against them that can be used to convict them. For example, it could just contain their e-mail addresses or phone numbers. That would be useless in court, but useful to investigators who would then look into the identified individuals and seek to gather evidence. With or without a tight chain of custody, information on the phone would be useful in obtaining search warrants.
The FBI and half the world has been arguing both sides of this. The FBI says in court documents they absolutely need this to find out if there are other conspirators. In public they talk about needing the ability to combat terrorism. Both arguments are lies, this is about precedent and always has been.
Oh, absolutely. And once they realized they were going to lose and the precedent was going to go against them, they decided on the current strategy to save face. Next they'll announce that Cellebrite cracked the phone but there was nothing useful on it.
MWM has it, SGI's 4Dwm had it, CDE (Common Desktop Environment, used by Sun and others) had it.
MWM may have had tearable menus first, not sure, but the first place I saw them was on NeXTstep, in 1990. One of many good ideas that Apple discarded when they turned NeXTstep into OS X.
GnuStep has tearable menus, as does WindowMaker.
Part of this involves designing and building their own servers.
Others do. Not so much for security, I think, as for cost management and optimizing data center operations.
The DMCA doesn't ban general breaking of security.
You might be confusing facts with feelings..
Nope. I can point you to the relevant text if you like.
The DRM effectively prevents access to the firmware binary code
Not the code that needs to be bypassed.
Modifying the code in memory is also an exercise of the copyright owner's exclusive right to prepare derivative works.
Assuming they have to modify it, which isn't necessarily the case.
How do you maintain chain of custody of the evidence if you hand it over to a company that's not governed by our laws?
That's not a problem, for at least two reasons.
First, chain of custody doesn't matter unless you want to use the information recovered as evidence in a trial. If you just use it to generate leads which you then use to find other suspects and evidence, then it's irrelevant if chain of custody was maintained.
Second, chain of custody is easy to maintain. Location and nationality don't affect chain of custody. What matters is that you have a documented chain and can prove that custody was maintained and access was controlled at each step. Worst case is that employees of the Israeli company may have to fly to the US and testify in court to substantiate the chain of custody, and to explain how they extracted the information. I'm sure the company would be happy to do that if the FBI paid them to (which would be an additional fee).
Devices like this have been around for a bit and is one possibility: http://blog.mdsec.co.uk/2015/0...
I believe the weakness that made that device possible was fixed in iOS 9, so it wouldn't be useful.
apple can pull some DCMA BS and sue them.
You think? The DMCA does try to ban circumvention of security measures that are used to protect copyright, but I don't think that's the case here. The DMCA doesn't ban general breaking of security.
We continue to print $1 paper bills LONG after it's been successfully proved by other Western commercial societies that 1-unit, 2-unit, and even 5-unit coins make far more sense.
Ugh. I don't like paper cash, but I hate coins. On the rare occasions I use cash, when I get coins in change I generally give them back, drop them in the "penny cup", or look for a beggar to give them to. I just don't want to carry the heavy, jingly things. At least US coinage is small and relatively lightweight. Dealing with the larger, heavier and generally more-used coins in other countries is one of my least favorite parts of international travel.