> Within November 2018, another data breach was found within a Google+ API software update. The bug was fixed within a week and there was no evidence that any third party developer compromised the system.

Please explain how this is anywhere near the level of FB & CA?

> However, approximately 52.5 million non-public profile fields were exposed to alternative apps that requested access to individuals Google+ ID, and created access to other profiles that had shared information with each other.

It's not on the same level as CA but should remind you that even a corporation like Google can have such data breaches, regardless of whether they were gaps or poor design. The investigations were initiated only after the CA scandal. Would the gap have been discovered in time without CA? Who knows. Even if it is assumed that this gap was not exploited, 52 million affected users is not a small number.

I don't think it's comparable at all - the CA scandal wasn't something CA got access to via a bug. What CA had been doing, plenty of other companies had already been doing on Facebook's platform to maximize ad spend. CA was just first to apply it to agitprop. So yes, while Google did go back and make sure their APIs were cleaned up they never unofficially offered the functionality in the first place.

It's just very different.

For example, there are a ton of SDKs that provide push notifications, such as Baidu, Tencent, etc...

There are also "super apps", such as WeChat, that offer their own API surface and can be preferable to some app devs.

Then there are some things, such as "advertising id", which none of these SDKs provide (at the moment?).

So yeah, the answer is somewhere between "it's complicated" and "no one".

> The filesystem issue is going to be a problem for me. I have an app that writes about 1000 images a day from user photographs which should certainly not be mixed into the general images pool!

The app doesn't need to contribute the photos to the shared media store. It can if it wants to allow other apps to also have access, but it can also write them to its own private directory.

> And I want to be able to browse my filesystem. It sounds like that's basically out without rooting now.

The scoped storage changes are something that app developers must handle, but you, as a user, will still be able to browse the entire SD card. (I'm a member of developer relations on Android and wrote a proof of concept file browser that works just fine on Android Q. :)

Any chance this PoC file browser is open source and available? I've been looking at these changes and I'm not sure how I should handle discovery of new devices, e.g. insertion of a new SD card, or an OTG USB device.

How does it work if I want to be able to browse that private directory with a file browser?

Generally, an app can ask the user to grant it access to other directories on the device, including the actual SD card root. (The user can also decide to only give the app access to a subset.)

Specifically, the API one uses is ACTION_OPEN_DOCUMENT_TREE.

For those interested, Eric Biggers, the author of the patch which added Speck support, sent an RFC the previous day to add HPolyC support to the kernel.

http://lkml.iu.edu/hypermail/linux/kernel/1808.0/05226.html

One can use Firefox Focus in place of AdGuard on iOS and it will perform the content filtering. :)

I understand you're frustrated, but there are a lot of us at Google who are also just trying to build cool open-source software, and in cases such as mine, building it so that others can use it to build even better things with less work. =(

But you're still there to make Google more money. What do you do when they tell you to build a feature that's supposed to Extend and Extinguish? I'm guessing often you wouldn't even really know.