Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
The counter-argument would be that if you consider the name on an account to be something needing security protections, then Looker Studio code should not have had the ability to access the name on an account.
Since you're the person that didn't answered with "hah you say: don't code bugs", I'll take some time to answer you.
> Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.
Guess what else uses Google Accounts? Everything that Google needs authentication for. When designing software, so much effort is put into its design, possible user stories and architecture. We put so much effort into unit tests, integration tests, regression tests whatnot.Security is no different. When designing services, considering the data flow is critical for security. An engineering organization should take into account of data that needs authentication. Those should be separate isolated services.
They can crate security islands for critical parts. Why Looker needs to get the full name from an e-mail that this person hasn't initiated a two-way contact? Or even, why it can in the first place? There is a service that does this resolution (Contacts?). Google failed to consider that limiting this kind of queries when creating this service. It has nothing to do with the functionality of Looker Studio. Now anything touches this service has problems. The old and the new products. You'll not be able to resolve these problems by deprecating Looker Studio nor deprecating Reader solved these issues.
> Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.
It is not the sharing of the authentication provider but the authorization of the kinds of queries is the problem here. It is not the problem with the age of the service Looker provides either. Yes you may be able to extract some data if the pod running Looker Studio got compromised, maybe even PII data. The dependencies can get old or can have critical bugs. However, they shouldn't be able to be exploited to extract large swaths of data due to layering and consideration of security architecture. That's why creating those security narrow-waist points are so important. They need to be given the same care of the correctness of the software and other UX goals.
Even a smaller company needs to consider these architectural details when designing integrated services. With GDPR, you should be able to delete every piece of PII. It gently forces you to do the right thing already. It is totally unacceptable that bigger companies like Google skipping this.
Google could mitigate this by not having universally shared accounts across all services, but they're not going to do that because most users would find that inconvenient.