Really? Keep in mind that without it Google search wouldn't exist... and neither would DDG, because most of DDG's sources are other engines that are also funded by advertising. Odds are that without Google's business model you'd also be seeing a lot more, and a lot more intrusive ads. You are probably too young to remember what the commercial side of the web looked like in the mid to late 90s, but I'm sure you've seen the "one weird trick" sites with pages and pages to present a small amount of content buried in mountains of ads. That was pretty much where we were headed until targeted advertising came along.

That would be the easy part. There'd just be no way for them to tell.

Android doesn't send any particular different parameters during setup. There's really no way the carrier could even know the difference. And if the device could send something that meant "hey, doing setup, don't charge this" you know custom ROMs would arrange to send that *all* the time, or at least as often as they can get away with.

Really? Care to support that claim?

Ctrl-F is your friend :-)

In that particular example, it's not even a change. None of the search engines have ever indexed much in the way of non-alphanumeric characters.

It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.

And the idea would be to get as much as possible out before it's encrypted. It would still be tough to analyze, but people would figure it out.

I don't even think it's true. The NSL gag order applies to the recipient of the NSL, not the whole world. So Google couldn't use this service to distribute information about NSLs sent to Google, but they couldn't do that anyway.

Fair enough.

No kidding. There's a reason my workstation has 40 cores and 128 GiB RAM.

I do, too, actually. Far better than I thought it would be. It's refreshing to hear someone outside of Google say that, though :-)

Well, the current direction is to create a lot of firewalls between components that even root can't breach, using SELinux. This is obviously to reduce the impact of privilege escalation exploits, and even more important to eliminated many of them because many exploits today are actually exploit chains, so if SELinux can break any link, the whole exploit is DOA. We're actually seeing a lot of exploits for older versions which no longer work in L because SELinux is in enforcing mode.

If what I'm thinking about doesn't require poking any holes through SELinux firewalls, then it's a relatively minor risk, though it does make an attacker's job easier. Specifically, the sort of attack I'm most worried about in this context is what we call "spouse spying". It's obviously not restricted to spouses, but it's the sort of thing that non-trivial numbers of people want to do, and which is a real and occasionally dangerous problem (as in, people die from the fallout of such tools being readily available -- not that the tools are at fault, exactly, but we'd rather not facilitate it). So we're not in the abstract realm of "well, it's theoretically possible to...", this is about real-world attacks, and so merely making it harder actually does achieve something in many cases.

I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though. I fundamentally like the idea -- probably mostly because it was my idea :-) -- if I can convince myself (and my colleagues) that it doesn't create any unacceptable new risks.

Other ideas for creating greater transparency are welcome.

If that's your level of paranoia, you're lost, and omitting the Google services doesn't help.

The fact is that you implicitly and deeply trust all the companies in the production pipeline for the networked electronic devices you use, because absolutely any one of them can easily arrange for whatever sort of backdoor they want. It's a little tougher for the hardware component vendors, I'll grant, but if they do the work they're in the best position of all to compromise your security without any possibility that you could find it.

With Android specifically, though, I'm interested in ideas for how we can make the system more transparent. We can't do anything about hardware-level compromises, but I'd like it if the upper layers were more auditable -- and note that having access to source code that purports to be what's running on the device doesn't get you there.

One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too. Of course, there's a big downside: if this single data collection point exists, it will be a tremendously attractive target for compromise by other parties who want to see what your device sends or receives.

You're a smart person, do you have any ideas for what Android could do to make its operations more transparent? We can't achieve perfection, but if we could get it to the point where Google or anyone else in the supply chain would have to do something which is obviously and solely intended to hide their actions in order to exfiltrate private data, that would be great.

Note that this is not an idle question. I'm a member of the Android security team, and in a position to make these sorts of things happen, or at least dramatically increase the likelihood.

You only gave one example, and that one I found very quickly. I just searched for "elisp operators" and it was the second hit. Do you have better examples?

I look for all sorts of fairly obscure things and I really don't see the problem.

National Security Letters can't give arbitrary instructions to suppress information. The law defines NSLs quite precisely. They are a form of subpoena and therefore can only be used to request information, with the additional constraint that the recipient of the NSL cannot tell anyone that the NSL was received or the information was provided. In addition, NSLs can only be used to request metadata, not content.

Maybe I'm not clever enough, but I can't think of any way that an NSL could be used to suppress stories. One could be used to demand information about who looked at stories, and Google wouldn't be able to tell anyone that the list of watchers was provided, but it couldn't be used to force the story offline.

There's also the possibility that the government is issuing secret gag orders which aren't so limited, but we have no evidence of that.

Hotword detection is optional in Android. If you don't like it, just turn it off.

It is fixed.

Google spends a lot of effort on optimizing search and has very sophisticated and effective metrics for tracking what works well and what doesn't. The thing is that you don't search like 99.99% of people search, and so the feedback loop optimizes away from you and towards others. Another poster above mentioned that it's better when signed in... I don't know if that's actually true, but Google does do some degree of search personalization, so it makes sense.

I find actually get very good results from Google, but I've changed the way I search. 20 years ago I learned to create very precise queries, with + and - to force and trim queries, omitting conjunctions and other common words that I knew weren't indexed anyway, etc. I don't do that any more. What works better these days, I find, is just to type a plain English question. For example, I just pulled up my Google search history, and here are some of my searches from today. Notably, not a single one of my searches required going to the second page of results and nearly all of them gave me the answer I was looking for as the top link.

"convert camelcase to underscore-separated with emacs" -- Got me immediately to a stackoverflow post that told me about the string-inflection package, available on MELPA.
"Can I use a heat pump to balance temperature between rooms?" -- My home office (I work from home) is perpetually hotter than the rest of the house, so I wondered if I could put a heat pump through the wall. Turns out, probably not. I'll investigate a fan instead.
"octal format string for printf" -- I didn't recall %o. Duh.
"example code for sha256 with openssl" -- Got me exactly what I wanted.
"how effective are hate crime laws" -- They appear to have no measurable effect on the rate of hate crime commission, though they arguably send a positive social signal.
"how to break on memory write in gdb" -- "watch"
"how to set gcm nonce length with openssl evp api" -- What a nasty hack that is, but it does work.
"trim whitespace from variable in bash" -- use tr
"bash tee to two pipes" -- redirect to a subshell
"942-Memory Training Error" -- Ugh, I think one of the DIMMs in my workstation is bad. Tech support is shipping me a replacement.

I only had the one error message to search for, but that's typical of my strategy. I don't try to craft an ideal query, I just paste the whole damned thing and 99% of the time I get an answer. Or at least more people complaining about the same problem.

I think a lot of the complaints about the change in search engine is from people who are still trying to use modern search engines they way they used them in 2000. Don't. Don't carefully craft your queries, just type a question, or paste a big pile of related text. That's what the masses do, so that's what Google optimizes for.

(Disclaimer: I work for Google, but not on search and don't know much about how it actually works.)

This is the right basic idea, I think, but I think everything will converge into a single device, either the mobile phone or a wearable. And as it becomes more and more central to everything we do, that device will become very smart about authentication.

The problem with using dedicated embeddable devices is twofold. First, the more of them you have to carry, the more difficult it is to keep track of them. With old-fashioned metal keys we've solved this with the key ring... but that creates its own problem. The more keys you add to it, the more valuable it becomes. Loss or theft become increasingly more problematic. And our metal keys open fewer, and less important, things than our electronic authenticators do.

So, it makes sense to combine the electronic keys in a single device, but then to use the capabilities it has that metal keys do not to solve the theft and loss problems. First, against loss, there must be a way of backing up all of the credentials, securely and automatically, so that in the event the device is lost they can all be recovered relatively easily. Some sort of remote server backup, to which you authenticate with some other mechanism that you protect very carefully (there are lots of options here, but a long, randomly-generated password printed out and stored in a safe place is a good option). That backup needs to be reliable and reliably accessible, but access need not be easy or convenient, since it should be rarely needed.

What about theft? This is where the smart device has huge advantages over dumber devices, because it can authenticate the user. This authentication needn't be particularly strong, but it should have good anti brute-force protections, and it should be smart. The goal is to make something that is extremely convenient for the user, but makes it relatively unlikely that someone else who gets it can use it. How could that work? Google is pushing towards this vision with Android Smart Lock features. The core idea is that the device shouldn't rely on a single signal, because that signal then has to be very strong.

It's worth looking at analogies with meatspace facilities that care a great deal about security. What they don't do is put a bank vault door on the exterior wall and rely on the strong combination lock to keep thieves out. Instead, they rely on layering of defenses, monitoring and active response.

What can your phone do? Quite a bit, probably. Not only does it have a touchscreen for entering passwords, it also has cameras, an accelerometer, GPS, various radios, compass, altimeter, microphones, a proximity sensor and probably other stuff I'm forgetting. In addition, it can know a lot about your habits, your plans (e.g. what's on your calendar) and more. With that wealth of signals, it should be possible for the device to determine with relatively high certainty whether or not it is still in your possession. Where it's uncertain, it can fall back to asking for authentication with, say, a fingerprint or simple PIN to increase its certainty. Or in more extreme cases, it can fall back to an even stronger password. The idea is to make authentication as seamless, transparent and automatic as possible... but as strong as necessary.

Or maybe a smart watch will be a better choice. It has pretty much all the same capabilities as a phone, but the advantage that you strap it to your body, making it harder to lose, and harder to steal. (Actually, I think over the next few years for many of us our phones will migrate onto our wrists; right now the smart watch is an extension of the phone, I think that will flip, with the handheld device becoming an extension of the watch providing a larger screen, aimable camera, etc.).

The "as strong as necessary" bit is important here, too. When the phone is going to use a stored authentication key to unlock something for you, the degree of certainty that it needs to have that you're you depends on what it's unlocking. If I'm using my phone to log me into slashdot on my laptop, I really couldn't care less. Getting access to my amazon.com account is a little more important, but less so if the access level doesn't allow the shipping address to be changed. Getting access to my bank account, or my house, are more important. Getting access to my brokerage account, or 401K, in a way that allows money to be withdrawn, are much, much bigger issues. At the high end, the phone should probably require a strong password for every use. In combination with possession of the device, that's a good two-factor auth (assuming it can store the authentication secrets securely; which it can for reasonable definitions of "securely").

Exactly how to do this well, with the right balances between convenience and security, is an unsolved -- and hard -- research problem. Google's baby steps towards it, with bluetooth smart unlock (keeps your phone unlocked as long as it remains within range of some bluetooth device, up to a maximum time limit) are just that, baby steps. Note that I'm not saying Google will necessarily be the organization to "solve" this problem. I expect to see lots of trial and error, experimentation by many individual researchers and companies, before we begin to figure out what really works. But I do think it's pretty clear that this is the future -- and I look forward to it.

(Disclaimer: I work for Google. I'm a software engineer on the Android security team, working on platform security features, including those related to user authentication and hardware-bound cryptographic key storage and usage, so my view is undoubtedly colored by my day job.)