This content originally appeared on Brave's latest news on Brave Browser and was authored by Brave's latest news on Brave Browser
This is the 24th post in an ongoing, regular series describing privacy features in Brave browsers. This post describes work done by Research and Privacy Engineer Shivan Kaul Sahib. This post was written by VP of Privacy Engineering Peter Snyder.
Starting in version 1.51, Brave will increase user privacy by extending the brower’s permission system to cover legacy Google Sign-In (which needs third-party cookies, or other unsatisfactory techniques, to allow users to log in to sites with their Google account). This new feature will replace Brave’s existing option of a global “allow” or “deny” setting for handling legacy Google Sign-Ins. This feature will be available on desktop and Android, and is another way Brave is retrofitting best-in-class privacy protections to Web APIs that were designed without concern for user privacy.
The good and the bad of “Google Sign-In”
Google, like many popular account-based sites, allows people to use their Google account to log in to other sites. This feature, sometimes called single-sign on (SSO), has both security benefits and privacy risks.
SSO systems can be helpful in several ways. First, SSO systems are very convenient for users, and remove the need to go through often-tedious account creation processes on different sites. Second, and more importantly, SSO systems in general (and “Sign in with Google” in particular) can improve user security. Instead of users needing to trust dozens or hundreds of websites with usernames and passwords (sites that may have wide-ranging security practices), users can instead benefit from Google’s top-notch security features, even on sites not belonging to Google. Examples of Google’s security bona fides include two factor authentication (2FA), advanced account protection features, and a security team that is among the best in the field.
However, SSO systems can also be harmful to users. For example, the centralized nature of SSO systems means that any flaws can have repercussions across the Web1. More relevant to this post, SSO systems can also harm user privacy, depending on how they are built and implemented. SSO systems necessarily involve the SSO-provider learning at least something2 about a user’s actions on another site, and many systems allow the SSO-provider to learn a great deal of sensitive and private information.
“Google Sign-In” in Brave, past and present
In most cases, Brave already protects a user’s privacy when they interact with Google Sign-In. Unless people intentionally and explicitly use their Google account to log in to sites, Brave prevents Google from learning about those sites.
However, there are many ways sites can integrate with Google Sign-In, the oldest of which relies on unrestricted third-party cookies. To combat this, by default Brave applies the strongest third-party cookie protections of any popular browser. This has the upside of providing robust, best-in-class privacy protections, though with the occasional downside of causing compatibility problems with systems that depend on unrestricted third-party cookies.
How Brave previously handled “Google Sign-In”
Previously, Brave provided compatibility with “Google Sign-In” with a single, global setting, accessible at brave://settings/socialBlocking. If the setting was off, Brave blocked third-party cookies for the “Google Sign-In” system, just as Brave blocks third-party cookies for all other requests on the Web. However, if the setting was on, Brave made a single exception to its third-party cookie policy, and allowed Google’s Sign-In system to access Google’s cookies.
This exception only affected URLs used for Google logins3, and did not allow other Google systems (such as Google Analytics, Google Tag Manager, or Doubleclick) to access third-party cookies. But regardless, when enabled, the exception caused Brave browsers on desktop and Android to send third-party cookies to Google in this narrow case.
How Brave now handles “Google Sign-In”
Starting with version 1.50, Brave has removed the exception and the global toggle, and moved to a permissions-based system. This allows users to control when (or if) a third-party cookie is sent to Google, while still taking advantage of the convenience and security provided by “Google Sign-In.” If the website already uses the new Google Identity Services for Web solution which doesn’t use third-party cookies for signing in, there’s no change.
Brave’s new “Google Sign-In” permission builds on previous privacy improvements Brave applies to permission handling in Chromium, including the ability to control how long a permission lasts for, and to partition permissions in third-party iframes.
Comparison to other browsers
Brave’s permission-based approach to enabling “Google Sign-In” is unique among browsers. Other browsers use different systems to be compatible with “Google Sign-In”(and other similar services). The approaches other browsers use are incompatible with Brave’s privacy goals and values, requiring us to develop our unique permissions-based approach.
Chrome’s approach
Chrome does not need any system to be compatible with third-party, cookie-based SSO systems because Chrome does not meaningfully restrict third-party cookies at all. In Chrome, SSO providers use the exact same techniques that third-party trackers and advertisers use to track you across the Web 1. This approach is fundamentally incompatible with Brave’s privacy-first principles.
Edge, Firefox, and Safari’s approach
Other browsers apply some restrictions to third-party cookies. Edge restricts third-party cookies if they appear on the Disconnect list of known trackers, and Firefox and Safari restrict (i.e. partition) third-party cookies for all sites. These browsers maintain compatibility with systems like “Google Sign-In” by using a system called the storage access API (plus various heuristics on top). The storage access API was originally developed in Safari, and allowed third-party frames to access unrestricted third-party cookies only after getting permission from the user.
The storage access API is both similar and very different from Brave’s “Google Sign-In” permission. The two are similar in that both systems only allow third-parties to access their first-party cookies after the user has given permission. The systems differ in that the storage access API is a general purpose API that allows third parties to request access for any purpose, whereas Brave’s system is purpose specific, and only enables third-party cookies for a narrow, specific purpose.
Brave disables the storage access API in Chromium as we believe this approach is not the right way to protect privacy on the Web. The storage access API asks users to make privacy-risking choices they do not understand, and generally requires users to bear the burden of protecting their own privacy. Brave’s system, by contrast, allows third-party cookies to be sent only for a specific, easily understood purpose, and for a very limited amount of time (i.e. the amount of time needed to complete the login process).
The storage access API was a tremendous improvement over what came before it (i.e. choosing between unrestricted access to third-party cookies, or breaking many third-party integrations). The designers and developers of the storage access API should be congratulated and appreciated for the privacy improvement their work brought. But Brave thinks the storage access API is best seen as a temporary stop-gap approach that has its own serious drawbacks; the Web should instead focus on other, better protections like ephemeral third-party storage.
The more promising future
Thankfully, many other browsers agree that narrow, purpose specific APIs are needed for protecting user privacy when sites need to communicate with each other. We at Brave are optimistic about efforts like the Federated Credential Management (FedCM) API, which would allow sites to narrowly request cross-site information for purposes like “Google Sign-In” without enabling the broad, unrestricted access to third-party state that the storage access API allows. Brave is still reviewing the current FedCM proposals, but we’re broadly in support of the effort. In a sense, Brave’s new permission-based approach for enabling “Google Sign-In” is Brave’s effort to bring the future privacy promises of FedCM to Web users today.
Brave’s “Google Sign-In” permission feature is another example of Brave’s approach to Web privacy: provide the strongest possible privacy protections for users today, while working with standards bodies to make sure the future direction of the Web is even more user-respecting.
-
For example, researchers at the University of Illinois at Chicago recently found that many single-sign on systems do not correctly handle account revocation, can allow for misconfigured site integrations, or suffer from other important security and privacy issues. ↩︎ ↩︎
-
Though what and how much information the SSO provider learns varies widely between systems. ↩︎
-
Specifically, URLs matching the patterns
https://accounts.google.com/o/oauth2/auth/*andhttps://[*.]firebaseapp.com/__/auth/*↩︎
This content originally appeared on Brave's latest news on Brave Browser and was authored by Brave's latest news on Brave Browser
Brave's latest news on Brave Browser | Sciencx (2023-03-06T00:00:00+00:00) “Google Sign-In” Permission. Retrieved from https://www.scien.cx/2023/03/06/google-sign-in-permission/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.