Then you'll notice them.

Sorry. I can't take any solution that runs on PHP seriously. Especially one with such a history of horrid bugs and remote exploits.

If you're talking about WordPress, then I would agree. It has a long history of security problems, mainly because it was written in an era when PHP was too popular for its own good.

Anyone suggesting PHP as a solution is quite obviously a moron.

The problem isn't PHP. The problem is PHP coders. When PHP was in its heyday, it made basic website CGI coding simple enough to attract a lot of coders who didn't have much experience. A lot of PHP code was written during that period. The result is that a lot of PHP software (much of which is still in common use) was written by people with minimal programming experience.

To make matters worse, the initial MySQL API in PHP was disastrous. (That's not PHP's fault, mind you; the same API was used in C and every other language at the time.) Most PHP software out there was written before the modern, parameterized syntax became available, so statistically speaking, the overwhelming majority of PHP code that uses MySQL probably contains security holes.

If you take a group of people who have solid programming backgrounds today, give them a two-week training course on PHP, then spend another two weeks on PHP-specific security and design issues, and insist that they use parameterized queries exclusively, you'll end up with good software. Unfortunately, this approach precludes the use of any software currently available unless you're willing to spend the time to do a detailed security audit.

My Nissan LEAF has a speaker mounted in the driver-side front wheel well which makes noise (a tone that sweeps across the frequency range, to cover people with frequency-limited hearing) whenever the vehicle is moving below 20 mph. It's not fake engine noise, it's better.

As to the article... I have learned to really enjoy the silence of an EV. Engine noise annoys me.

If the argument is that I as a consumer have a right to not have my ISP discriminate against my choice of content providers then where in that argument is the limiting principle that prevents me from forcing the content providers to provide the content on a device of my choosing rather than theirs?

Clearly these are exactly identical situations despite the fact that in the network neutrality argument there is a third party (the ISP) interfering with my choice of content provider, while in your argument there is no ISP interfering in my choice of content provider. The total and complete lack of third-party interference in your case (which is entirely what network neutrality is about) is what makes it different.

That's true... but why doesn't it apply to Android phones? They're also associated with Google, and also have cameras.

FWIW, I think Google has a big PR problem to solve here. The perception that Google slurps up all information available isn't really correct, either, but it's pretty difficult to convince people of it. The Google dashboard was an attempt to show people what Google actually knows about them but (a) hardly anyone knows about it and (b) most who look at it assume that it's only what Google wants them to know that it knows.

I think in the long run the only solution for Google is to move away from advertising, to a payment-for-services model. That won't happen with much of the existing service suite, but advertising can be de-emphasized by growing in other directions.

True, but the point the GP is making is that such wealth status is a choice. It's a choice that's a good idea regardless of your career field.

Clearly it's a violation of the separation of powers. Only the judicial branch can decide reality, like the judge ruling that deepwater horizon spilled 3.19 million barrels of oil.

This gets to the heart of the matter; it's all a question of perceptions/feelings. Perhaps it's because of something in Google's original ads and videos about Glass, or something else, but people perceive the main purpose of Glass to be video recording and assume that anyone wearing one is recording them, while they don't think the same thing of phones with cameras. Even though phones are actually better video recording devices, and almost as easy to record with covertly.

(Disclaimer: Because some AC thought I should mention it, I am a Google employee. I don't work on Glass, and don't speak for Google, though. This is only my own personal opinions. I've only used Glass a handful of times myself, though I've frequently been around other people wearing one.)

When I say something that may be construed as defending Google, I do post a disclaimer. I didn't think this qualified.

And, yes, I'm pretty happy with my compensation :-)

That is the perception, but it's really not true. It's quite easy to record video while pretending to be texting, or something.

It will also be limited by not wanting to reveal that they have the capability. Per a former-NSA colleague of mine, that is often the more stringent restriction.

I'm fairly certain there aren't any in the Nexus 6 or Nexus 9 low-level boot or hardware security code. However, there certainly could be in firmware blobs. Those run in non-secure mode, but all your data is also accessible from non-secure mode.

That said, the Android security team pays pretty close attention to exploits in the wild, so if there were something like that being exploited on a large scale, I think we'd know. Exploits that are used only for so-called "targeted persistent attacks", whether by criminal organizations or government agencies are a different story, of course, but those simply aren't relevant to most people.

Sure, that's why I said "the next option is to exploit some defect...".

Another fine place for a back door, though, and still not that unlikely that a flaw will exist there. The critical code paths should be sufficiently short that it's worth disassembling them.

You seem to be restating what I just said :-)

Keep what secrets from whom? If the NSA is really your adversary and they're specifically targeting you, you're simply screwed. Seriously, give up now. My goal is to ensure that your device is secure against (a) remote network exploits, (b) locally-installed software and (c) hardware attacks of moderate sophistication. (c) definitely includes "I lost my device and some clueful hardware engineer found it".

Assuming you're running up-to-date software (yeah, much easier said than done, I know), haven't done anything yourself to compromise the Android security model (e.g. running around with an unlocked bootloader) and have a reasonably-good password and an encrypted file system, I give you high odds of being perfectly safe against (a), (b) and (c).

Dear Dimit:

Thank you for taking the time to apply to our job. Unfortunately we are not able to extend an offer of employment to you as we feel you are overqualified for this position. Thank you for your interest.

Sincerely,
HR

his next bonus will suffer resulting in him not benefiting

Unless his next quarter is a negative bonus where he has to pay his ill-gotten gains back, he gets $10000 for hitting this quarter's target and gets only $1000 next quarter. As opposed to only getting $1000 both quarters. The behavior is a no-brainer.

He could later be considered for termination if the pattern continues.

Unless he's high enough up AND his behavior drives the company into bankruptcy, then the gets a $50000 retention bonus to help ensure his leadership through these tough times.

Actually, since it's closely related to my day job (Android hardware-backed crypto), I have quite deep knowledge of exactly how true it is or is not.

Subverting it requires subverting the bootloader sequence, which starts with code in on-SoC ROM, which is nearly impossible to modify, and I add the "nearly" only because nothing is impossible; I sincerely doubt that any agency is able to modify silicon without destroying the CPU and I'm quite certain that if anyone can it's a very closely-held, and therefore rarely-used, secret. Supposing the initial bootloader can't be subverted, subverting later bootloaders (which are stored in flash) is also difficult, since they're signed and signatures are verified by the hard-to-subvert boot ROM. There are two obvious ways: break the cryptographic signing, or obtain the signing key. There's no doubt that intelligence services could do the latter. It's unlikely that they would share the signing key, or the subverted signed code, with law enforcement since doing so would make their ability known. It's unlikely in the extreme that criminals would obtain either the key or the subverted signed code. I'll dismiss the notion that someone can break the crypto directly.

The next option is to exploit some defect in the implementation of the bootloaders and/or fastboot (or in the case of intelligence agencies, even to implant a defect to be exploited). This is probably the best avenue of attack, but it's not easy because the code in question is relatively small, and should be closely scrutinized. Most of it is not open source, though, so scrutiny is limited. This is an avenue law enforcement and criminals could use, if there are exploitable defects. If there are any such defects in any Android devices, I don't know of them, and if they were in any sort of widespread use, I would. If such exploits exist, they're being held close by criminals (for TPT-style attacks) and not being used by LE or intelligence agencies in any context which might reveal them publicly... such as in court.

The final option is to ignore all of the above and simply attack the hardware. Remove the flash chips and install them in a custom device which reads out their contents. This threat is what device encryption exists to mitigate. Pre-Lollipop, the strength of FDE depended entirely on the strength of the user's password. In Lollipop it was strengthened with the use (where available) of a key bound to the device SoC.

Oh, yeah. I forgot to mention that those pixel counts were for adult-size heads. Scale accordingly for younger kids. :-)