However the pay and hours in these fields is a form of misery not seen since the old testament. You cant raise a family on any of these careers, and for some of them retirement isnt really an option. we use education as a whipping stick for these careers to insist theyre worth "less" than they really are
You're making a claim here that doesn't hold up to scrutiny. Specifically, you're claiming that those vocational careers aren't well paid because we "insist" they're less valuable than others that require more education. But such perceptions have little to no effect on wages. What drives wages is supply and demand, and those fields aren't well paid because the supply of people able to do them is high relative to the demand for them.
If you want to see this self-fulfilling prophecy of underemployment in the real world, just look at the trucking industry. Perpetually understaffed, underpaid long-haul tractor-trailer drivers that get no vacation, sick leave, or retirement fund yet are in such ridiculous demand that most trucking companies like Dart or Swift will pay the driver to finish their CDL education. The demand is so high, drivers with a good record can quit a job and be hired at another in the same day.
The fact that a driver can get another job easily, and the fact that trucking companies are willing to pay for training, don't indicate that truck drivers are underpaid relative to the economics of the industry. Truckers can change jobs easily because their skills are highly mobile: Driving a truck for one company is no different from driving for another. There are slight differences in procedures and paperwork, but they're trivial, so friction is low. The contract nature of trucker employment also helps a lot; because the company can easily terminate any driver who turns out to be a problem, they don't have to be very careful about who they hire.
As for training, trucking companies have found that it's cheaper to pay for training than to pay higher mileage rates, because that allows them to draw from the large pool of unskilled workers available and because the training is easy, a legally-required formality more than a challenging skill development exercise. If the training were longer, more expensive and more difficult, then they'd undoubtedly find it better to raise pay scales and let the higher pay encourage people to take on the risk of obtaining training themselves.
Why do all of their voice-activated prompts require me to repeat the name of the corporation, over and over?
Probably so that the on-device voice recognition can recognize you're talking to it, so that it doesn't have to send a live feed of your microphone to Google HQ, and also so it doesn't randomly hear commands in your regular speech.
Then why can't I set up my own phrase to activate the on-device voice recognition?
Referring to the US as "America" is pretty much accepted by everyone other than pedants and people with an axe to grind.
FTFY.
And people who live in America, but not in the United States of America. It's pretty unusual for Latin Americans to use "America" to refer to the US, for example.
BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.
I don't quite follow: if it was a fork it would have come with SSLv2 since OpenSSL comes with it. How can it have not been added in the first place?
From the blog post that I linked:
Generally when people say “forking” they mean that they took a copy of the code and started landing patches independently of the original source. That's not what we did with BoringSSL. Rather than start with a copy, I started with an empty directory and went through OpenSSL function-by-function, reformatting, cleaning up (sometimes discarding) and documenting each one.
However, Adam did say that the SSL code was handled a bit differently, it was copied then incrementally improved, and the improvements included removing SSLv2 support. So my claim that SSLv2 was never added to BoringSSL was wrong. It was copied over from OpenSSL, then removed.
BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.
Well that's a pretty amazing endorsement of autonomous vehicles, if *already* 25% of the population is accepting of a new technology they haven't yet experienced.
The headline should actually read "75% of drivers speculate that they might not feel safe in an autonomous vehicle", because none of those polled know anything about how they'd actually feel, having never even seen an autonomous vehicle in operation, much less been in one.
Google needs to start looking at a revenue model that cannot be quashed by a free browser extension. Down the road there will be a paid version for anyone.
I assume you're referring to advertising. Two points: First, Google already has some $6B per year in non-advertising revenues, and growing rapidly. Second, if everyone starts using adblockers, they'll stop working because sites that depend on advertising revenue will start rejecting users that adblock. We've already seen the beginning of that. Adblocking doesn't work if more than a small portion of the world uses adblockers.
Oh, one more: yours is a funny comment on a discussion about a service that could very obviously be sold as a service. Perhaps what you suggest is exactly what Google is doing?
Wait, that's really it? How hard can it be to figure that out?
I'm not sure how, but maybe some kind of geolocation based on timing?
Since your DNS name will resolve to a Google proxy server IP and that's where requests will go, timing will be hard. Not impossible, but hard. And supposing you did manage to see pass that obfuscation to discover the geolocation of that actual target server. How does that help you direct packets to it? You need the IP.
For that matter, supposing you did get the IP, it seems like the admins could just configure their firewall to drop all packets except those coming from Google, because all legitimate traffic will go there first.
(Disclosure: I'm a Google engineer. Security is my gig, not privacy, but the two overlap a bit so I see a lot of what goes on around privacy.)
Including, I assume, all of the privacy that your company systematically violates in order to conduct its core, mission-critical, business and reason for existing,
Google only wants your data if you want to provide it. It's an exchange of value; you get service, Google gets to advertise to you. If you don't like it, Google provides the tools you need to opt out -- while in most cases still allowing you to use the services!
Hmm. Maybe. Play services doesn't have root access, but it does have pretty deep hooks. It probably couldn't get everything, but it might be able to get quite a bit. I hadn't thought about that one. Thanks.
Android 4.3 introduced support for this kind of hardware secure key storage. There is some detail here: http://nelenkov.blogspot.co.uk... [blogspot.co.uk]
Note that until L there was no relationship between disk encryption and the hardware-backed keystore. In L we added a dependency on the keystore, though I think it's still not quite where it should be (even in M). We'll continue improving it, obviously.
Are you saying that Android on Qualcomm SoCs that have secure storage don't use it?
They don't use it for this, exactly. The usey bits of it for master keys used to derive keys that are used for this. I don't believe there's any equivalent of a TPM that in QC SoCs that requires presentation of a certain hash (or sequences of hashes) in a PCM or similar to unlock a key in secure storage.
Because if they do use it then what you say about being able to update the bootloader, boot image, system image etc, is all irrelevant. Go ahead, replace any of them, the SoC isn't going to give up the master key unless you present it with the right hash, and there is nothing you can do to reduce the delay between attempts or the maximum number of attempts per power cycle.
Yeah, that would be awesome wouldn't it? Unfortunately, no. The secure storage you're talking about is just storage. The software that manages it runs on the main CPU, is loaded from flash, etc. Various ARM features are used to keep this all completely walled off from Android and the Linux kernel, and largely even from the trusted OS and applications that use it. But they're still all loaded from flash.
This is why TPM on computers is secure. Obviously you can boot any OS image you like, or flash the BIOS any time you like. It doesn't matter, the TPM has its own processor and isn't giving up that key until you give it the right hash.
Right. To really do this you need a separate secure processor that has its own storage and its own code... ideally code that physically cannot be updated, though that assumes the code is perfect, which is never true so some tradeoffs have to be made. Apple has done this, I believe, though I don't know the details, with their Secure Enclave chip. Samsung has done something with KNOX. Nexus has no equivalent, and neither do most Android devices.
One interesting side note: Since Intel doesn't have any equivalent of the ARM TrustZone, the typical implementation of the hardware-backed keystore on Intel devices is to actually use a TPM chip. That has some nice properties, though TPMs are fixed-function devices and so cannot implement the access controls added to the hardware-backed keystore feature set in M.
First, I'm not 100% sure that the TOS vendor signs the TOS. That may also be signed by the OEM.
Second, my comment that Qualcomm would be the "best" point of attack was only because the TOS is the best point of attack, from a technical perspective, not because I think Qualcomm would cooperate. I have neither the knowledge nor the authority to say anything about what Google's partners would or would not be willing to do.
Third, I want to point out that my project to add a separate secure processor to Android devices and to no one can brute force passwords has nothing to do with the current Apple/FBI issue. It's ongoing work that I initiated some years back. I should also mention that it may or may not be successful. These things are complicated.
What about getting to know who want to visit what website which is protected through the system?
That's a good enough reason to do it?
Google has explicitly stated that data on visitors will not be used for advertising or search purposes, and that Google will not retain any of the data beyond two weeks, and then only in aggregated form and only for the purpose of improving the shield service.
I realize that people really don't want to believe a corporation could every do anything nice, but I really don't see any room for nefarious hidden motives here (and such would be pretty out of character for Google anyway). Of course, that just seems to make people look harder and stretch further to find the diabolical plot underneath, and the further they have to stretch the more diabolical the plot they "discover".
separate organization that is tasked with monitoring and minimizing access
How about for someone already part of that organization. It would just be themselves and their manager's approval (if one is needed at all for their org, and even may be just themselves if they are the head). It all comes to the culture in the organization. I cant comment on google, but I bet these things happen even organizations with similar policies.
It's possible, though it also would surprise me if there aren't defenses in place against that... such as that the systems do not allow anyone in the access management organization to have access themselves (which pushes the question off on the managers of those systems... and I know there are many eyes positioned to watch them). In this case, though, it's hard to see why someone in such an organization would want access to data that flowed through Project Shield. You could see the ads guys wanting it, and maybe the search guys (though that's not so clear), but an employee in the access control org would have no business motive at all. It would have to be a personal motive... and they'd have to be ready to risk their job and perhaps even prosecution for it.
It's not inconceivable that data that could generate such an interest in someone who happens to be in a position to abuse it (at significant personal risk) could pass through Project Shield, but I think it's really, really unlikely. I think it's much more likely that other Google services would have data that might motivate someone to take the risk.
What I haven't heard yet is where Android lands on the security spectrum. Are they already as or more secure than what the rumors are now saying Apple is trying to achieve? Are they as or more secure than where Apple is right now? Are they as or more secure than where Windows is right now?
Android devices with L or M are roughly as secure as the pre-Secure Enclave Apple devices (like the 5C). That is, the security software is all in flashable components which are signed, and if the holder of the signing keys can be coerced into signing a custom image, it's possible to bypass all of the anti brute-force protections. Brute force is still necessary, then, but it's trivial for four-digit PINs and may be feasible even for better passwords (or patterns).
That's in general. Some OEMs have gone a bit further, such as Samsung's KNOX. I don't know the details and can't comment on whether or not they actually improved the security above the baseline required/defined. by Google.
I'm the Google Android engineer responsible for lots of these bits.
But I suspect Google could push a Google services update targeted at a specific phone, and those can do darn near anything.
You suspect wrong. Play services can affect some things, but all of the device encryption stuff is at a much lower level. Breaking encryption would require changing the core OS, and even a little deeper. See my reply to the GP for more detail.
Google's Nexus devices are secure and don't have the same firmware update flaw that iPhones do. In fact all Snapdragon 810 based phones are immune because the 810 does not allow firmware updates to the secure memory, it's a ROM burned into the silicon.
As an Android security engineer I appreciate you standing up for Google, but this isn't true.
The relevant software for device encryption includes:
1. The system image. This contains the vold daemon which mounts the encrypted disk and configures the kernel with the key.
2. The boot image. This contains the Linux kernel, which includes dm-crypt, the code that does device encryption.
3. The trusted OS image (TOS). This contains the code that knows how to use device-specific hardware-bound secrets. Vold calls into it when decrypting the disk encryption key to pass to the kernel.
4. The bootloader image. This is used to load all of the above. The details vary, but generally the TOS is verified and loaded first, then the bootloader switches out of secure mode (I'm describing the process for ARM-based devices; it's a bit different for others), then verifies and loads the boot image and boots the kernel. The kernel mounts the system image and configures dm-verity which does run-time verification of system image blocks.
All of the above are flashable images, and replacing them would enable bypassing the security controls they implement. The bootloader image is the most critical one, since it verifies and loads both the TOS and the boot image. If you can change the keys it uses to verify those, you can change everything else. The bootloader (including the keys it contains) is signed by a key whose public part is burned into ROM. That key can't be changed, and the private key is held by the device OEM. I believe the keys used to sign the system and boot images for Nexus devices are held by Google (not sure), and the key used to sign the TOS is held by the TOS maker (Qualcomm, on the recent Nexus devices).
You could compromise Android device encryption with the assistance of any of these parties. Getting the OEM to sign a new bootloader allows you to provide your own versions of any of the higher-level pieces, though these things are pretty intricate and writing replacements from scratch that would work is a big, big job. If I were working for the FBI, I probably wouldn't take that approach. Getting Google to sign a modified system image would, from a technical perspective, be much better. You'd still have to brute force the password, and you'd still have to have the TOS perform a 50ms operation for each password you try, but that would be no problem for a four-digit PIN. If the user used, say, an eight-character password, though, it wouldn't be enough. Also, Google's response to a request for a modified system image would probably be about the same as Apple's.
The best point of attack would be Qualcomm (for recent Nexus devices; other platforms and older Nexus devices use different TOSes). Get them to sign a TOS image that takes the device secrets and simply exports them in response to some request. With those secrets in hand, and a copy of the device flash, you can then brute force the device encryption key off-device, on big hardware. No realistic user password would stand up to that. The process is complicated so I won't bother explaining it here, but it would be very doable.
To be clear, the Android security team considers these multiple points of entry a bug, not a feature. I, personally, want to get to a state where if you don't have the user's password, you aren't getting in, barring direct attacks that involve peeling apart chips to extract secrets. Doing that requires a separate secure processor (something most Android devices don't have) running non-updateable software. Working to make this possible is one of my current projects.
It's a much tougher problem in the Android world than for Apple, though, because of all of the players in the ecosystem. Not because they're unw
Seriously, the size of some of the DDoS attempts is massive. That's a lot of bandwidth wasted, and there will be a dollar impact associated with this.
Not as much as you might think. Google has really excellent DDoS resistance systems that recognize and simply terminate a lot of DDoS connections, because DDoS traffic looks very different from normal traffic. Also, as I understand it, Google doesn't really pay for bandwidth. It peers with the various backbone providers rather than buying service from anyone. And Google obviously has enough bandwidth capacity to deal with any DDoS attack without trouble; Google's normal traffic volumes are vastly larger than even the biggest DDoS attacks. Google measures bandwidth in petabits per second.
So, the real cost is just capacity of the proxy servers used to provide project shield... but I'm sure these are the same proxy servers which are used to front all of Google's own services. They have tremendous capacity and, again, their normal workload looks much like what anyone else would see as a massive DDoS attack. My guess is that the additional load is negligible.
What additional angle will google be targeting to make money off this?
For now, it's purely altruistic, providing protection for news, human rights and election monitoring websites. If it works well for them, Google could easily turn it into a service offering for any sort of organization who wants DDoS protection. It could be a very nice business for Google, actually, since it's unlikely to add noticeable load to Google's infrastructure.
(Disclaimer: I'm a Google engineer. I've written code that runs in the proxy servers I'm sure are being used for this. However, I'm speaking for myself, not for Google, and the above contains some suppositions about how the shield system will work which may not be correct. I've deliberately avoided searching out the internal design documentation until after posting this. But I'm curious so I'm sure I'll go look later:-) )
No, Project Shield doesn’t place ads on websites it protects.
Project Shield doesn’t change the content of your website in any way. It also doesn’t impact the ability for your website to target advertising or analyze ads-related data.
For now, until users get comfortable with the service. Once it gains traction they will be re-writing the terms and conditions.
Want to bet? Seriously, care to put money on that? I'll take that action in a heartbeat, assuming we can work out a way to do it.
Also just because a company has a policy, doesn't mean there isn't someone violating it behind the scenes
Pursuant to the consent decree signed after the Buzz fiasco, the Federal Trade Commission regularly audits Google to verify compliance with the terms of the decree, which includes compliance with Google's publicly-stated privacy policies. It would be very, very risky for Google to do anything to violate those terms.
Google also applies strictly-limited and closely-audited access controls on all such data, so it's virtually impossible for a "rogue" employee to do what you describe without approval from both his or her own manager, and from a separate organization that is tasked with monitoring and minimizing access. Attempting to bypass any of these controls is both very hard and is a firing offense.
(Disclosure: I'm a Google engineer. Security is my gig, not privacy, but the two overlap a bit so I see a lot of what goes on around privacy.)
But by using Project Shield you and your agents and seven generation of your children's children agree and that we can change the Terms and Conditions of use, in a 64 page-long document of legalise, that only 1 in 100 people will ever read and/or notice, at any time.]
Does Google’s Privacy Policy apply to visitors to my website?
No. Your website’s own policies and terms of service — including how you manage user data and privacy — apply to people visiting your site, not Google’s privacy policy and terms of service.
Slashdot Mirror
However the pay and hours in these fields is a form of misery not seen since the old testament. You cant raise a family on any of these careers, and for some of them retirement isnt really an option. we use education as a whipping stick for these careers to insist theyre worth "less" than they really are
You're making a claim here that doesn't hold up to scrutiny. Specifically, you're claiming that those vocational careers aren't well paid because we "insist" they're less valuable than others that require more education. But such perceptions have little to no effect on wages. What drives wages is supply and demand, and those fields aren't well paid because the supply of people able to do them is high relative to the demand for them.
If you want to see this self-fulfilling prophecy of underemployment in the real world, just look at the trucking industry. Perpetually understaffed, underpaid long-haul tractor-trailer drivers that get no vacation, sick leave, or retirement fund yet are in such ridiculous demand that most trucking companies like Dart or Swift will pay the driver to finish their CDL education. The demand is so high, drivers with a good record can quit a job and be hired at another in the same day.
The fact that a driver can get another job easily, and the fact that trucking companies are willing to pay for training, don't indicate that truck drivers are underpaid relative to the economics of the industry. Truckers can change jobs easily because their skills are highly mobile: Driving a truck for one company is no different from driving for another. There are slight differences in procedures and paperwork, but they're trivial, so friction is low. The contract nature of trucker employment also helps a lot; because the company can easily terminate any driver who turns out to be a problem, they don't have to be very careful about who they hire.
As for training, trucking companies have found that it's cheaper to pay for training than to pay higher mileage rates, because that allows them to draw from the large pool of unskilled workers available and because the training is easy, a legally-required formality more than a challenging skill development exercise. If the training were longer, more expensive and more difficult, then they'd undoubtedly find it better to raise pay scales and let the higher pay encourage people to take on the risk of obtaining training themselves.
Now answer my question: Who do you recommend I vote for?
In the primaries? Republican or Democrat? If Republican, I recommend Rubio. If Democrat, I recommend Bernie.
In the generals? If Trump gets the nomination, vote Democrat. Early and often. Even if you're a Republican. Maybe especially if you're a Republican.
Why do all of their voice-activated prompts require me to repeat the name of the corporation, over and over?
Probably so that the on-device voice recognition can recognize you're talking to it, so that it doesn't have to send a live feed of your microphone to Google HQ, and also so it doesn't randomly hear commands in your regular speech.
Then why can't I set up my own phrase to activate the on-device voice recognition?
You can.
So are the LibreSSL guys not part of the Linux community anymore?
I don't know that I'd say that OpenSSL is part of the Linux community, but LibreSSL definitely is not, since it's developed by the OpenBSD team.
Referring to the US as "America" is pretty much accepted by everyone other than pedants and people with an axe to grind .
FTFY.
And people who live in America, but not in the United States of America. It's pretty unusual for Latin Americans to use "America" to refer to the US, for example.
BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.
I don't quite follow: if it was a fork it would have come with SSLv2 since OpenSSL comes with it. How can it have not been added in the first place?
From the blog post that I linked:
Generally when people say “forking” they mean that they took a copy of the code and started landing patches independently of the original source. That's not what we did with BoringSSL. Rather than start with a copy, I started with an empty directory and went through OpenSSL function-by-function, reformatting, cleaning up (sometimes discarding) and documenting each one.
However, Adam did say that the SSL code was handled a bit differently, it was copied then incrementally improved, and the improvements included removing SSLv2 support. So my claim that SSLv2 was never added to BoringSSL was wrong. It was copied over from OpenSSL, then removed.
BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.
https://www.imperialviolet.org/2015/10/17/boringssl.html
Well that's a pretty amazing endorsement of autonomous vehicles, if *already* 25% of the population is accepting of a new technology they haven't yet experienced.
The headline should actually read "75% of drivers speculate that they might not feel safe in an autonomous vehicle", because none of those polled know anything about how they'd actually feel, having never even seen an autonomous vehicle in operation, much less been in one.
Google needs to start looking at a revenue model that cannot be quashed by a free browser extension. Down the road there will be a paid version for anyone.
I assume you're referring to advertising. Two points: First, Google already has some $6B per year in non-advertising revenues, and growing rapidly. Second, if everyone starts using adblockers, they'll stop working because sites that depend on advertising revenue will start rejecting users that adblock. We've already seen the beginning of that. Adblocking doesn't work if more than a small portion of the world uses adblockers.
Oh, one more: yours is a funny comment on a discussion about a service that could very obviously be sold as a service. Perhaps what you suggest is exactly what Google is doing?
Wait, that's really it? How hard can it be to figure that out?
I'm not sure how, but maybe some kind of geolocation based on timing?
Since your DNS name will resolve to a Google proxy server IP and that's where requests will go, timing will be hard. Not impossible, but hard. And supposing you did manage to see pass that obfuscation to discover the geolocation of that actual target server. How does that help you direct packets to it? You need the IP.
For that matter, supposing you did get the IP, it seems like the admins could just configure their firewall to drop all packets except those coming from Google, because all legitimate traffic will go there first.
(Disclosure: I'm a Google engineer. Security is my gig, not privacy, but the two overlap a bit so I see a lot of what goes on around privacy.)
Including, I assume, all of the privacy that your company systematically violates in order to conduct its core, mission-critical, business and reason for existing,
Google only wants your data if you want to provide it. It's an exchange of value; you get service, Google gets to advertise to you. If you don't like it, Google provides the tools you need to opt out -- while in most cases still allowing you to use the services!
Good luck with that. I don't have access to that information and couldn't get it if I tried. Also, I like being able to look in the mirror.
So, stupid question. What's to stop the DDOS attackers from directly targeting my server, and bypassing this proxy?
Not knowing your IP address.
Hmm. Maybe. Play services doesn't have root access, but it does have pretty deep hooks. It probably couldn't get everything, but it might be able to get quite a bit. I hadn't thought about that one. Thanks.
Android 4.3 introduced support for this kind of hardware secure key storage. There is some detail here: http://nelenkov.blogspot.co.uk... [blogspot.co.uk]
Better link, reflecting the massive improvements in M: https://source.android.com/sec...
Note that until L there was no relationship between disk encryption and the hardware-backed keystore. In L we added a dependency on the keystore, though I think it's still not quite where it should be (even in M). We'll continue improving it, obviously.
Are you saying that Android on Qualcomm SoCs that have secure storage don't use it?
They don't use it for this, exactly. The usey bits of it for master keys used to derive keys that are used for this. I don't believe there's any equivalent of a TPM that in QC SoCs that requires presentation of a certain hash (or sequences of hashes) in a PCM or similar to unlock a key in secure storage.
Because if they do use it then what you say about being able to update the bootloader, boot image, system image etc, is all irrelevant. Go ahead, replace any of them, the SoC isn't going to give up the master key unless you present it with the right hash, and there is nothing you can do to reduce the delay between attempts or the maximum number of attempts per power cycle.
Yeah, that would be awesome wouldn't it? Unfortunately, no. The secure storage you're talking about is just storage. The software that manages it runs on the main CPU, is loaded from flash, etc. Various ARM features are used to keep this all completely walled off from Android and the Linux kernel, and largely even from the trusted OS and applications that use it. But they're still all loaded from flash.
This is why TPM on computers is secure. Obviously you can boot any OS image you like, or flash the BIOS any time you like. It doesn't matter, the TPM has its own processor and isn't giving up that key until you give it the right hash.
Right. To really do this you need a separate secure processor that has its own storage and its own code... ideally code that physically cannot be updated, though that assumes the code is perfect, which is never true so some tradeoffs have to be made. Apple has done this, I believe, though I don't know the details, with their Secure Enclave chip. Samsung has done something with KNOX. Nexus has no equivalent, and neither do most Android devices.
One interesting side note: Since Intel doesn't have any equivalent of the ARM TrustZone, the typical implementation of the hardware-backed keystore on Intel devices is to actually use a TPM chip. That has some nice properties, though TPMs are fixed-function devices and so cannot implement the access controls added to the hardware-backed keystore feature set in M.
Some small clarifications:
First, I'm not 100% sure that the TOS vendor signs the TOS. That may also be signed by the OEM.
Second, my comment that Qualcomm would be the "best" point of attack was only because the TOS is the best point of attack, from a technical perspective, not because I think Qualcomm would cooperate. I have neither the knowledge nor the authority to say anything about what Google's partners would or would not be willing to do.
Third, I want to point out that my project to add a separate secure processor to Android devices and to no one can brute force passwords has nothing to do with the current Apple/FBI issue. It's ongoing work that I initiated some years back. I should also mention that it may or may not be successful. These things are complicated.
What about getting to know who want to visit what website which is protected through the system?
That's a good enough reason to do it?
Google has explicitly stated that data on visitors will not be used for advertising or search purposes, and that Google will not retain any of the data beyond two weeks, and then only in aggregated form and only for the purpose of improving the shield service.
I realize that people really don't want to believe a corporation could every do anything nice, but I really don't see any room for nefarious hidden motives here (and such would be pretty out of character for Google anyway). Of course, that just seems to make people look harder and stretch further to find the diabolical plot underneath, and the further they have to stretch the more diabolical the plot they "discover".
separate organization that is tasked with monitoring and minimizing access
How about for someone already part of that organization. It would just be themselves and their manager's approval (if one is needed at all for their org, and even may be just themselves if they are the head). It all comes to the culture in the organization. I cant comment on google, but I bet these things happen even organizations with similar policies.
It's possible, though it also would surprise me if there aren't defenses in place against that... such as that the systems do not allow anyone in the access management organization to have access themselves (which pushes the question off on the managers of those systems... and I know there are many eyes positioned to watch them). In this case, though, it's hard to see why someone in such an organization would want access to data that flowed through Project Shield. You could see the ads guys wanting it, and maybe the search guys (though that's not so clear), but an employee in the access control org would have no business motive at all. It would have to be a personal motive... and they'd have to be ready to risk their job and perhaps even prosecution for it.
It's not inconceivable that data that could generate such an interest in someone who happens to be in a position to abuse it (at significant personal risk) could pass through Project Shield, but I think it's really, really unlikely. I think it's much more likely that other Google services would have data that might motivate someone to take the risk.
What I haven't heard yet is where Android lands on the security spectrum. Are they already as or more secure than what the rumors are now saying Apple is trying to achieve? Are they as or more secure than where Apple is right now? Are they as or more secure than where Windows is right now?
Android devices with L or M are roughly as secure as the pre-Secure Enclave Apple devices (like the 5C). That is, the security software is all in flashable components which are signed, and if the holder of the signing keys can be coerced into signing a custom image, it's possible to bypass all of the anti brute-force protections. Brute force is still necessary, then, but it's trivial for four-digit PINs and may be feasible even for better passwords (or patterns).
That's in general. Some OEMs have gone a bit further, such as Samsung's KNOX. I don't know the details and can't comment on whether or not they actually improved the security above the baseline required/defined. by Google.
I'm the Google Android engineer responsible for lots of these bits.
But I suspect Google could push a Google services update targeted at a specific phone, and those can do darn near anything.
You suspect wrong. Play services can affect some things, but all of the device encryption stuff is at a much lower level. Breaking encryption would require changing the core OS, and even a little deeper. See my reply to the GP for more detail.
Google's Nexus devices are secure and don't have the same firmware update flaw that iPhones do. In fact all Snapdragon 810 based phones are immune because the 810 does not allow firmware updates to the secure memory, it's a ROM burned into the silicon.
As an Android security engineer I appreciate you standing up for Google, but this isn't true.
The relevant software for device encryption includes:
1. The system image. This contains the vold daemon which mounts the encrypted disk and configures the kernel with the key.
2. The boot image. This contains the Linux kernel, which includes dm-crypt, the code that does device encryption.
3. The trusted OS image (TOS). This contains the code that knows how to use device-specific hardware-bound secrets. Vold calls into it when decrypting the disk encryption key to pass to the kernel.
4. The bootloader image. This is used to load all of the above. The details vary, but generally the TOS is verified and loaded first, then the bootloader switches out of secure mode (I'm describing the process for ARM-based devices; it's a bit different for others), then verifies and loads the boot image and boots the kernel. The kernel mounts the system image and configures dm-verity which does run-time verification of system image blocks.
All of the above are flashable images, and replacing them would enable bypassing the security controls they implement. The bootloader image is the most critical one, since it verifies and loads both the TOS and the boot image. If you can change the keys it uses to verify those, you can change everything else. The bootloader (including the keys it contains) is signed by a key whose public part is burned into ROM. That key can't be changed, and the private key is held by the device OEM. I believe the keys used to sign the system and boot images for Nexus devices are held by Google (not sure), and the key used to sign the TOS is held by the TOS maker (Qualcomm, on the recent Nexus devices).
You could compromise Android device encryption with the assistance of any of these parties. Getting the OEM to sign a new bootloader allows you to provide your own versions of any of the higher-level pieces, though these things are pretty intricate and writing replacements from scratch that would work is a big, big job. If I were working for the FBI, I probably wouldn't take that approach. Getting Google to sign a modified system image would, from a technical perspective, be much better. You'd still have to brute force the password, and you'd still have to have the TOS perform a 50ms operation for each password you try, but that would be no problem for a four-digit PIN. If the user used, say, an eight-character password, though, it wouldn't be enough. Also, Google's response to a request for a modified system image would probably be about the same as Apple's.
The best point of attack would be Qualcomm (for recent Nexus devices; other platforms and older Nexus devices use different TOSes). Get them to sign a TOS image that takes the device secrets and simply exports them in response to some request. With those secrets in hand, and a copy of the device flash, you can then brute force the device encryption key off-device, on big hardware. No realistic user password would stand up to that. The process is complicated so I won't bother explaining it here, but it would be very doable.
To be clear, the Android security team considers these multiple points of entry a bug, not a feature. I, personally, want to get to a state where if you don't have the user's password, you aren't getting in, barring direct attacks that involve peeling apart chips to extract secrets. Doing that requires a separate secure processor (something most Android devices don't have) running non-updateable software. Working to make this possible is one of my current projects.
It's a much tougher problem in the Android world than for Apple, though, because of all of the players in the ecosystem. Not because they're unw
Seriously, the size of some of the DDoS attempts is massive. That's a lot of bandwidth wasted, and there will be a dollar impact associated with this.
Not as much as you might think. Google has really excellent DDoS resistance systems that recognize and simply terminate a lot of DDoS connections, because DDoS traffic looks very different from normal traffic. Also, as I understand it, Google doesn't really pay for bandwidth. It peers with the various backbone providers rather than buying service from anyone. And Google obviously has enough bandwidth capacity to deal with any DDoS attack without trouble; Google's normal traffic volumes are vastly larger than even the biggest DDoS attacks. Google measures bandwidth in petabits per second.
So, the real cost is just capacity of the proxy servers used to provide project shield... but I'm sure these are the same proxy servers which are used to front all of Google's own services. They have tremendous capacity and, again, their normal workload looks much like what anyone else would see as a massive DDoS attack. My guess is that the additional load is negligible.
What additional angle will google be targeting to make money off this?
For now, it's purely altruistic, providing protection for news, human rights and election monitoring websites. If it works well for them, Google could easily turn it into a service offering for any sort of organization who wants DDoS protection. It could be a very nice business for Google, actually, since it's unlikely to add noticeable load to Google's infrastructure.
(Disclaimer: I'm a Google engineer. I've written code that runs in the proxy servers I'm sure are being used for this. However, I'm speaking for myself, not for Google, and the above contains some suppositions about how the shield system will work which may not be correct. I've deliberately avoided searching out the internal design documentation until after posting this. But I'm curious so I'm sure I'll go look later :-) )
They'll probably show ads on the shielded version of the website.
From https://support.google.com/pro...
Does Project Shield place ads on content?
No, Project Shield doesn’t place ads on websites it protects.
Project Shield doesn’t change the content of your website in any way. It also doesn’t impact the ability for your website to target advertising or analyze ads-related data.
For now, until users get comfortable with the service. Once it gains traction they will be re-writing the terms and conditions.
Want to bet? Seriously, care to put money on that? I'll take that action in a heartbeat, assuming we can work out a way to do it.
Also just because a company has a policy, doesn't mean there isn't someone violating it behind the scenes
Pursuant to the consent decree signed after the Buzz fiasco, the Federal Trade Commission regularly audits Google to verify compliance with the terms of the decree, which includes compliance with Google's publicly-stated privacy policies. It would be very, very risky for Google to do anything to violate those terms.
Google also applies strictly-limited and closely-audited access controls on all such data, so it's virtually impossible for a "rogue" employee to do what you describe without approval from both his or her own manager, and from a separate organization that is tasked with monitoring and minimizing access. Attempting to bypass any of these controls is both very hard and is a firing offense.
(Disclosure: I'm a Google engineer. Security is my gig, not privacy, but the two overlap a bit so I see a lot of what goes on around privacy.)
But by using Project Shield you and your agents and seven generation of your children's children agree and that we can change the Terms and Conditions of use, in a 64 page-long document of legalise, that only 1 in 100 people will ever read and/or notice, at any time.]
From https://support.google.com/pro...:
Does Google’s Privacy Policy apply to visitors to my website?
No. Your website’s own policies and terms of service — including how you manage user data and privacy — apply to people visiting your site, not Google’s privacy policy and terms of service.