Twenty years ago the global birth rate was still rising and we had no way to know when or where it would peak. Now we know that it has peaked and is declining. Unless something changes to cause it to increase again, or unless we make significant increases in human longevity, the predictions are now on much more solid ground than they have been in the past.
I just checked my GalaxyS3, it says "software backed", so I guess it's not implemented on at least S3's.
I'd like to see people using hardware-backed credential storage as a factor when purchasing devices. It would actually take very little consumer pressure to make all devices provide it.
You can be certain that all current and future Nexus devices will.
Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology.
Yes, this is correct. The Android crypto HAL (keymaster) can be provided by any "secure" device, but at present I believe all of them use TrustZone, at least on ARM devices (Intel has something similar, but it's not the same).
But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits.
Sure they can. The benefit, though, is that the secure world code can and should be dramatically smaller and simpler than the non-secure world, and therefore amenable to much deeper security auditing. This is actually no different from what Apple does with their security chip... which still runs software written by people and can have exploits. There are some security benefits to being on a truly separate CPU, but that doesn't change the fundamental fact that exploits are always possible.
What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games.
The same issue applies to separate CPUs, and the same countermeasures apply as well, though I'll absolutely grant that it's a harder problem on a virtual secure CPU.
And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it.
All the devices I'm aware of provide a real hardware RNG. The cost is negligible, in fact it would probably cost more to remove it from the SoC designs than to leave it in. However, that still leaves open the question of how good the hardware RNG is. For the next generation of keymaster I'm trying to define some requirements around how it's used that should mitigate many possible weaknesses, and I'm also defining a mechanism that apps can use to inject some entropy of their own, in case they don't trust the RNG (assuming they have a place to get entropy). Note that injected entropy is required to be securely mixed into HW-generated entropy, so it should not be possible to inject data that actually decreases the available randomness, nor to manipulate the outputs, unless the attacker can also manipulate/predict the HW RNG.
The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.
TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.
Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple.
Thanks for the insightful response.
Also, there's more to security than disk encryption.
Vastly, vastly more. It's one very small piece of a large, complex and ever-shifting puzzle. With respect to mobile device security I think it's actually one of the less-important pieces, because the set of problems it solves is pretty narrow. It gets a lot of press and discussion because it's easy to understand.
What happens when we get to a point where we just don't need everyone to work in order to provide the goods and services people want?
You assume there is a limit to the goods and services people want. I don't think there's any evidence that such a limit exists. Much of what the developed world spends its money on today would, a few decades ago, have been considered either pure frivolity, or just inconceivable. I see no reason that trend will not continue. I know a guy who makes a great living helping other people buy cars, kind of like a real estate agent, but for vehicles. You would think that the Internet, with the wealth of information it makes available to anyone who wants to research what car to buy, would make his job redundant, but in fact it is what has made his business successful. Personalized attention from a human who not only knows the area but is capable of understanding your needs and tastes, and of making you feel good about his understanding of your needs and tastes, is what has made him successful. And note that his clients are not wealthy; he doesn't even know that much about the luxury car segment.
Rather than everyone just becoming unemployed, I think we'll find more and more specialized and arcane uses to which to put all of that freed-up labor. And for my evidence... I'll just point to the economic shifts caused by every technological advance in history, and all of the people throughout history who have made your argument and been consistently wrong.
I can't confirm that L is using hardware security for disk encryption. Elenkov decided that we are in his analysis, but you'll have to read his words to decide if you believe it.
However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".
The biggest question I have is the part about Google incorporating hardware-based security since Google controls the software, not the hardware. Are they now dictating that for Android to run a specific hardware protection setup must exist on the devices?
Not a specific hardware protection setup, no. Android defines an abstract API to hardware-backed crypto services, called keymaster, which device makers have to implement. They can implement it in whatever way they like, though AFAIK all of them currently use ARM TrustZone. And not all of them do implement it. If you'd like to find out if your device does go to Settings, then Security, then scroll down to the section on "Credential Storage" and see if it says "Storage type" is "Hardware-backed".
Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.
This is true, of course, but it should also be remembered (as Elenkov explains in detail) that Android's encryption features aren't new, they exist in hundreds of millions of devices already deployed. And, L isn't really "vaporware". If you want you can go download it now, though not in its final form. Elenkov's evaluation was based on real code running on his device.
I should make clear where I stand here: I'm an Android security engineer. I work on the hardware-backed crypto infrastructure (the infrastructure that Elenkov says is used in disk encryption for L).
If you'd like me to compare Android and iOS encryption, I'm glad to: Apple's is better. Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS. One thing Android has done better is to encrypt the entire user data partition. With iOS8, Apple has (probably) addressed the issues it had there. I can't talk about future plans, but I will say that I'm not yet satisfied with Android's disk encryption. It's good, but it can and should be better. I'm not sure we can ever match Apple in this area, since Apple has the luxury of focusing on a single device and has complete control of the hardware. But we can get closer.
Different context. The talk is about using incentives to try to motivate better/faster/higher/whatever solutions. It focuses people on trying to optimize for the incentive.
But Google isn't doing that. Google is enabling people to work on something interesting and impactful instead of doing something mundane, like flipping burgers or some other student-type summer job.
What if I just want to write code that doesn't make a difference in the world? Why does everything have to make a difference in the world? Isn't it enough that you experience pleasure from solving complicated problems?
Why not do both, if you can? They're not mutually exclusive. There's also a third benefit you can get: money. The ideal is to work on problems that are interesting, pay well, and make the world a better place.
That's what Google is trying to achive here: solve interesting problems that have an non-negligible impact on the world, and to motivate people to solve them they're offering cash.
Instead, we'll probably breed right up to the edge of capacity and then die in billions when something unexpected happens.
No, we won't. The developed world is already zero or negative in population growth. Even better, it appears that this fact is primarily caused not by a cultural decision to have fewer kids, but by economics. It appears that the primary determining factors in the growth rate of a society are health and wealth: If children are likely to survive, people don't feel the need to breed lots of replacements, so they have fewer kids and invest more in them. Also, if people are wealthy and have a high standard of living, then maintaining that standard of living for a small family is much easier than for a large family.
So, the developed world is already not growing in population -- much of Europe is negative, and the US is at zero growth when you remove immigration -- and the developing world is rapidly getting healthier and wealthier. In fact, the numbers show that we've already passed "peak child", meaning the year in which the most new babies are born, and the birth rate is already beginning to decline, globally. The population is still growing because right now the world's population is heavily weighted toward the young, with almost half of the population under 25. But with about two billion people being born in each new generation, and a lifespan of approximately five generations, it appears that we're on track to peak at about 10B people, before we start declining.
That's if we don't change anything, of course. What we know for sure is that things will change, but we don't know what.
It is not the same problem. DRM has to be secure against the machine it runs on. That is impossible. Secure software has to be secure at some perimeter (network socket, IPC interface, etc.), but anything inside this perimeter is assumed to be trustworthy. Secure software _is_ possible.
Obfuscation also has to be secure against the machine it runs on.
"Recent additions" to a language over 20 years old... Sorry, not for me.
Why not? Why would you refuse to use tools that are available?
In other words, yes, an expert programmer may make some fancy use of a feature, but he'd also be able to do the same with plain C.
No.
C++ allows an expert (ish) programmer to ensure that he doesn't make mistakes, which he could not do in C. Even experts make mistakes, particularly during maintenance of code written years earlier.
Meanwhile, it remains very easy for a bad programmer to unwittingly introduce enough memory copying
There are very simple practices that avoid this. The most important is that by default all classes should have copying disabled. Exceptions must be deliberate and documented. I find that, as compared with C, this risk is more than offset by the near-elimination of memory leaks and dangling pointers which are provided by application of some other simple C++ conventions.
As long as Comcast and Time Warner are competing with each other, Netflix can say "Well Comcast only charged us this much, can you lower your price?" to Time Warner.
And Time Warner will say "How nice that Comcast is giving you a break. But if you want access to our customers -- which you cannot get from Comcast -- then this is the price."
Competition only exists when customers have a choice of suppliers for the same good, or goods that are substantially interchangeable. In this case, Comcast is selling access to one set of users and Time Warner is selling access to a different set. Netflix wants and needs access to both, so it can't trade one off against the other.
Software obfuscation confronts exactly the same core problem as DRM: The goal is to both provide information, in usable form, and not provide the same information, to the same recipient, at the same time. That's impossible. So in both cases all you can do is to try to raise the bar, make it harder to extract the convenient form of the information, but "mathematically proven security properties" must be forever out of reach.
Unless maybe they define "obfuscation" differently than I do.
You can also circumvent ads with AdBlock. Google doesn't try to do anything about that (and they easily could, especially on Chrome). In addition, you can make the ads much less effective even without blocking them by opting out of ad personalization and analytics tracking. Google not only doesn't try to stop you from doing that, they provide and maintain tools that specifically enable you to do it.
Yes, Google wants to trade services for the opportunity to show you ads, and even wants to make the ads more useful to you and more lucrative to Google by making them for things you're actually interested in. But if you don't want that trade, Google wants to give you the opportunity to opt out.
Also... that's not the only way Google makes money. Google also makes money when you buy stuff on the Play store, which is why they have no problem with CM users installing and using Play... quite the opposite, in fact.
Their whole business model depends on you running their spyware apps.
Actually, most of their Android business model depends on you buying stuff on Play. I won't quote any numbers because I'm not sure if Google releases them, but Google's cut of app, movies, music and book sales is getting to be pretty significant. Google also makes plenty from mobile advertising, of course, but that doesn't really depend on you using Google's apps, since, as I understand it, most of the advertising revenue comes from (a) mobile search and (b) advertising embedded in third-party apps (AdMob).
Oh, and do you have any evidence that Google's apps spy on you? I know that they don't. Google search history is tracked, same as on desktop, but you can opt out of that either through Google's opt-out tools, or by switching to a different search engine. Location tracking is entirely under your control. Gmail is used for targeted advertising, if you use gmail. And... that's it. Oh, maybe Google+ is mined for keywords, but I don't think so, and in any case you can just not use Google+.
(Disclaimer: I'm a Google engineer, but I'm speaking for myself.)
That was my first thought. Google either wants to kill it or neuter it.
Actually, from what I see Google takes care to ensure the CM and similar efforts can continue to grow and thrive. This is why all Nexus devices are unlocked or unlockable, and why Google encourages OEMs to keep their devices open, too (with limited success).
I'm skeptical of the article's claim that Google was interested in acquiring CM. I just don't see the point... CM's whole value to Google is because it's independent, both of Google and of other parties in the ecosystem (OEMs, carriers, etc.).
(Disclaimer: I'm an Android engineer at Google, but I'm speaking only for myself.)
and will the binaries of that compiled C++ be 100% portable? no?
Sure they will, just as much as binaries compiled from C source. If you're writing libraries which are distributed in binary form (or used as shared libraries), then you have a bit of a portability challenge, but only a bit: You just have to make sure that all of the entry points follow C conventions. This may be an unfortunate restriction, but it's a restriction that applies to C as well.
I disagree, particularly if you include a bit of light template metaprogramming. C++ can enable the compiler to reject bad code which no C compiler could ever know is bad. One example, though a fairly heavyweight one, is that described in Barton and Nackman's "Scientific and Engineering C++". The authors construct a system that enables the compiler to do dimensional analysis on arbitrary expressions involving physical values. There is zero run-time cost, and the infrastructure they create ensures that any attempt to, for example, assign the product of a mass and a velocity value to a force variable will fail to compile. That's a simple example, but their system handles expressions of arbitrary complexity.
I have found the ability to extend the compiler's diagnostic abilities in that way to be tremendously valuable in system code. Recent additions to the specification, especially static assertions, make C++ even more powerful in this regard.
Beyond that, I deeply disagree that the tighter abstractions and automated bookkeeping that C++ provides aren't useful to systems programmers, however experienced. I've seen far too many little mistakes caused by forgetting some detail that could easily have been automated in a C++ program.
Slashdot Mirror
Yes. Twenty years ago the maximum was 9 billion.
Twenty years ago the global birth rate was still rising and we had no way to know when or where it would peak. Now we know that it has peaked and is declining. Unless something changes to cause it to increase again, or unless we make significant increases in human longevity, the predictions are now on much more solid ground than they have been in the past.
How many 60" TVs can you fit into your house? How many cars in your garage?
How many horses can pull your wagon?
Your questions all have the same implicit assumption, that technology and society will remain as it is now... and that is clearly not true.
I just checked my GalaxyS3, it says "software backed", so I guess it's not implemented on at least S3's.
I'd like to see people using hardware-backed credential storage as a factor when purchasing devices. It would actually take very little consumer pressure to make all devices provide it.
You can be certain that all current and future Nexus devices will.
Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology.
Yes, this is correct. The Android crypto HAL (keymaster) can be provided by any "secure" device, but at present I believe all of them use TrustZone, at least on ARM devices (Intel has something similar, but it's not the same).
But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits.
Sure they can. The benefit, though, is that the secure world code can and should be dramatically smaller and simpler than the non-secure world, and therefore amenable to much deeper security auditing. This is actually no different from what Apple does with their security chip... which still runs software written by people and can have exploits. There are some security benefits to being on a truly separate CPU, but that doesn't change the fundamental fact that exploits are always possible.
What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games.
The same issue applies to separate CPUs, and the same countermeasures apply as well, though I'll absolutely grant that it's a harder problem on a virtual secure CPU.
And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it.
All the devices I'm aware of provide a real hardware RNG. The cost is negligible, in fact it would probably cost more to remove it from the SoC designs than to leave it in. However, that still leaves open the question of how good the hardware RNG is. For the next generation of keymaster I'm trying to define some requirements around how it's used that should mitigate many possible weaknesses, and I'm also defining a mechanism that apps can use to inject some entropy of their own, in case they don't trust the RNG (assuming they have a place to get entropy). Note that injected entropy is required to be securely mixed into HW-generated entropy, so it should not be possible to inject data that actually decreases the available randomness, nor to manipulate the outputs, unless the attacker can also manipulate/predict the HW RNG.
The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.
TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.
Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple.
Thanks for the insightful response.
Also, there's more to security than disk encryption.
Vastly, vastly more. It's one very small piece of a large, complex and ever-shifting puzzle. With respect to mobile device security I think it's actually one of the less-important pieces, because the set of problems it solves is pretty narrow. It gets a lot of press and discussion because it's easy to understand.
Exactly. That's a big part of it. Huge.
What happens when we get to a point where we just don't need everyone to work in order to provide the goods and services people want?
You assume there is a limit to the goods and services people want. I don't think there's any evidence that such a limit exists. Much of what the developed world spends its money on today would, a few decades ago, have been considered either pure frivolity, or just inconceivable. I see no reason that trend will not continue. I know a guy who makes a great living helping other people buy cars, kind of like a real estate agent, but for vehicles. You would think that the Internet, with the wealth of information it makes available to anyone who wants to research what car to buy, would make his job redundant, but in fact it is what has made his business successful. Personalized attention from a human who not only knows the area but is capable of understanding your needs and tastes, and of making you feel good about his understanding of your needs and tastes, is what has made him successful. And note that his clients are not wealthy; he doesn't even know that much about the luxury car segment.
Rather than everyone just becoming unemployed, I think we'll find more and more specialized and arcane uses to which to put all of that freed-up labor. And for my evidence... I'll just point to the economic shifts caused by every technological advance in history, and all of the people throughout history who have made your argument and been consistently wrong.
Did you read my post?
I can't confirm that L is using hardware security for disk encryption. Elenkov decided that we are in his analysis, but you'll have to read his words to decide if you believe it.
However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".
The biggest question I have is the part about Google incorporating hardware-based security since Google controls the software, not the hardware. Are they now dictating that for Android to run a specific hardware protection setup must exist on the devices?
Not a specific hardware protection setup, no. Android defines an abstract API to hardware-backed crypto services, called keymaster, which device makers have to implement. They can implement it in whatever way they like, though AFAIK all of them currently use ARM TrustZone. And not all of them do implement it. If you'd like to find out if your device does go to Settings, then Security, then scroll down to the section on "Credential Storage" and see if it says "Storage type" is "Hardware-backed".
The documentation for the current version of the hardware crypto API is at https://source.android.com/dev...
Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.
This is true, of course, but it should also be remembered (as Elenkov explains in detail) that Android's encryption features aren't new, they exist in hundreds of millions of devices already deployed. And, L isn't really "vaporware". If you want you can go download it now, though not in its final form. Elenkov's evaluation was based on real code running on his device.
I should make clear where I stand here: I'm an Android security engineer. I work on the hardware-backed crypto infrastructure (the infrastructure that Elenkov says is used in disk encryption for L).
If you'd like me to compare Android and iOS encryption, I'm glad to: Apple's is better. Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS. One thing Android has done better is to encrypt the entire user data partition. With iOS8, Apple has (probably) addressed the issues it had there. I can't talk about future plans, but I will say that I'm not yet satisfied with Android's disk encryption. It's good, but it can and should be better. I'm not sure we can ever match Apple in this area, since Apple has the luxury of focusing on a single device and has complete control of the hardware. But we can get closer.
Can we hold android to this standard?
I would hope so. I do.
Offering incentives to solve problems is actually detrimental though: https://www.youtube.com/watch?...
Different context. The talk is about using incentives to try to motivate better/faster/higher/whatever solutions. It focuses people on trying to optimize for the incentive.
But Google isn't doing that. Google is enabling people to work on something interesting and impactful instead of doing something mundane, like flipping burgers or some other student-type summer job.
What if I just want to write code that doesn't make a difference in the world? Why does everything have to make a difference in the world? Isn't it enough that you experience pleasure from solving complicated problems?
Why not do both, if you can? They're not mutually exclusive. There's also a third benefit you can get: money. The ideal is to work on problems that are interesting, pay well, and make the world a better place.
That's what Google is trying to achive here: solve interesting problems that have an non-negligible impact on the world, and to motivate people to solve them they're offering cash.
Instead, we'll probably breed right up to the edge of capacity and then die in billions when something unexpected happens.
No, we won't. The developed world is already zero or negative in population growth. Even better, it appears that this fact is primarily caused not by a cultural decision to have fewer kids, but by economics. It appears that the primary determining factors in the growth rate of a society are health and wealth: If children are likely to survive, people don't feel the need to breed lots of replacements, so they have fewer kids and invest more in them. Also, if people are wealthy and have a high standard of living, then maintaining that standard of living for a small family is much easier than for a large family.
So, the developed world is already not growing in population -- much of Europe is negative, and the US is at zero growth when you remove immigration -- and the developing world is rapidly getting healthier and wealthier. In fact, the numbers show that we've already passed "peak child", meaning the year in which the most new babies are born, and the birth rate is already beginning to decline, globally. The population is still growing because right now the world's population is heavily weighted toward the young, with almost half of the population under 25. But with about two billion people being born in each new generation, and a lifespan of approximately five generations, it appears that we're on track to peak at about 10B people, before we start declining.
That's if we don't change anything, of course. What we know for sure is that things will change, but we don't know what.
the lack of that proprietary spyware is the main reason to use it.
Cite? Specifically, do you have any evidence that GApps spies on you?
It is not the same problem. DRM has to be secure against the machine it runs on. That is impossible. Secure software has to be secure at some perimeter (network socket, IPC interface, etc.), but anything inside this perimeter is assumed to be trustworthy. Secure software _is_ possible.
Obfuscation also has to be secure against the machine it runs on.
Isn't that why Dice bought slashdot?
Sure. But Dice could not have gotten slashdot's customer base by buying, for example, MySpace.
"Recent additions" to a language over 20 years old... Sorry, not for me.
Why not? Why would you refuse to use tools that are available?
In other words, yes, an expert programmer may make some fancy use of a feature, but he'd also be able to do the same with plain C.
No.
C++ allows an expert (ish) programmer to ensure that he doesn't make mistakes, which he could not do in C. Even experts make mistakes, particularly during maintenance of code written years earlier.
Meanwhile, it remains very easy for a bad programmer to unwittingly introduce enough memory copying
There are very simple practices that avoid this. The most important is that by default all classes should have copying disabled. Exceptions must be deliberate and documented. I find that, as compared with C, this risk is more than offset by the near-elimination of memory leaks and dangling pointers which are provided by application of some other simple C++ conventions.
As long as Comcast and Time Warner are competing with each other, Netflix can say "Well Comcast only charged us this much, can you lower your price?" to Time Warner.
And Time Warner will say "How nice that Comcast is giving you a break. But if you want access to our customers -- which you cannot get from Comcast -- then this is the price."
Competition only exists when customers have a choice of suppliers for the same good, or goods that are substantially interchangeable. In this case, Comcast is selling access to one set of users and Time Warner is selling access to a different set. Netflix wants and needs access to both, so it can't trade one off against the other.
Software obfuscation confronts exactly the same core problem as DRM: The goal is to both provide information, in usable form, and not provide the same information, to the same recipient, at the same time. That's impossible. So in both cases all you can do is to try to raise the bar, make it harder to extract the convenient form of the information, but "mathematically proven security properties" must be forever out of reach.
Unless maybe they define "obfuscation" differently than I do.
You can also circumvent ads with AdBlock. Google doesn't try to do anything about that (and they easily could, especially on Chrome). In addition, you can make the ads much less effective even without blocking them by opting out of ad personalization and analytics tracking. Google not only doesn't try to stop you from doing that, they provide and maintain tools that specifically enable you to do it.
Yes, Google wants to trade services for the opportunity to show you ads, and even wants to make the ads more useful to you and more lucrative to Google by making them for things you're actually interested in. But if you don't want that trade, Google wants to give you the opportunity to opt out.
Also... that's not the only way Google makes money. Google also makes money when you buy stuff on the Play store, which is why they have no problem with CM users installing and using Play... quite the opposite, in fact.
Fuck off and die.
What an eloquent, informative response! I salute you, sir.
Their whole business model depends on you running their spyware apps.
Actually, most of their Android business model depends on you buying stuff on Play. I won't quote any numbers because I'm not sure if Google releases them, but Google's cut of app, movies, music and book sales is getting to be pretty significant. Google also makes plenty from mobile advertising, of course, but that doesn't really depend on you using Google's apps, since, as I understand it, most of the advertising revenue comes from (a) mobile search and (b) advertising embedded in third-party apps (AdMob).
Oh, and do you have any evidence that Google's apps spy on you? I know that they don't. Google search history is tracked, same as on desktop, but you can opt out of that either through Google's opt-out tools, or by switching to a different search engine. Location tracking is entirely under your control. Gmail is used for targeted advertising, if you use gmail. And... that's it. Oh, maybe Google+ is mined for keywords, but I don't think so, and in any case you can just not use Google+.
(Disclaimer: I'm a Google engineer, but I'm speaking for myself.)
That was my first thought. Google either wants to kill it or neuter it.
Actually, from what I see Google takes care to ensure the CM and similar efforts can continue to grow and thrive. This is why all Nexus devices are unlocked or unlockable, and why Google encourages OEMs to keep their devices open, too (with limited success).
I'm skeptical of the article's claim that Google was interested in acquiring CM. I just don't see the point... CM's whole value to Google is because it's independent, both of Google and of other parties in the ecosystem (OEMs, carriers, etc.).
(Disclaimer: I'm an Android engineer at Google, but I'm speaking only for myself.)
and will the binaries of that compiled C++ be 100% portable? no?
Sure they will, just as much as binaries compiled from C source. If you're writing libraries which are distributed in binary form (or used as shared libraries), then you have a bit of a portability challenge, but only a bit: You just have to make sure that all of the entry points follow C conventions. This may be an unfortunate restriction, but it's a restriction that applies to C as well.
I disagree, particularly if you include a bit of light template metaprogramming. C++ can enable the compiler to reject bad code which no C compiler could ever know is bad. One example, though a fairly heavyweight one, is that described in Barton and Nackman's "Scientific and Engineering C++". The authors construct a system that enables the compiler to do dimensional analysis on arbitrary expressions involving physical values. There is zero run-time cost, and the infrastructure they create ensures that any attempt to, for example, assign the product of a mass and a velocity value to a force variable will fail to compile. That's a simple example, but their system handles expressions of arbitrary complexity.
I have found the ability to extend the compiler's diagnostic abilities in that way to be tremendously valuable in system code. Recent additions to the specification, especially static assertions, make C++ even more powerful in this regard.
Beyond that, I deeply disagree that the tighter abstractions and automated bookkeeping that C++ provides aren't useful to systems programmers, however experienced. I've seen far too many little mistakes caused by forgetting some detail that could easily have been automated in a C++ program.