I guess by your test, Google Music All Access gets an A, though personally I think what it does is better than immediately playing motown. What it provides is several sections: Motown artists, Motown albums, Motown songs, Motown Radio stations (similar to Spotify), Motown Playlists (apparently put together by users and shared to the world) and Motown videos, each with a selection of a half-dozen choices and a "See All" button that takes you to the rest of the matches for that section.

Not caring for Motown myself, I can't comment on the quality of the contents of the sections. It all looked pretty reasonable, though.

Relative to the points in the summary, Google also has Adele and Taylor Swift. Beatles... not so much. There are a bunch of "albums" but most of them are interviews along with a couple of albums including somewhat random songs... but none of their actual album releases. It's also possible that a couple of the music albums I see are not in the library, but were uploaded by me (you can upload your own music and it appears in the streaming service just as though it were part of the library. I think Metallica is also not in the library. I've uploaded all of their albums, so they're all there for me. It's possible I also uploaded some Adele, though there are albums I don't have so they must be from the library. And I don't own any Taylor Swift, so I'm sure all of that is from the library.

Oh, and Google Music's subscription also includes YouTube MusicKey, so whatever isn't available in the streaming service is almost certainly available there. The Beatles' music is, though not under a music license, so it's not available for download or background play.

(Disclosure: I work for Google, though I'm speaking here as a satisfied customer of the music service.)

The world without web search, or even the pre-search model of curated indexes (Yahoo!, also based on targeted advertising, though of a less effective form)? You're either trolling, or stupid.

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?

https://tyk.io/

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.