Can we use Firebase Authentication and be GDPR compliant?
<p><a href="https://firebase.google.com/support/privacy" rel="nofollow noreferrer">The Firebase Authentication is processing data exclusively in the United States</a>, and is therefore not GDPR compliant. However, they are saying on the same site that:</p>
<blockquote>
<p>Firebase has moved to reliance on Standard Contractual Clauses for relevant data
transfers, which, as per the ruling, can continue to be a valid legal
mechanism to transfer data under the GDPR</p>
</blockquote>
<p>They are also saying that:</p>
<blockquote>
<p>The European Commission approved new versions of the Standard
Contractual Clauses on June 4, 2021</p>
</blockquote>
<p>Google Cloud Platform have some Eu Standard Contractual Clauses on <a href="https://cloud.google.com/terms/sccs" rel="nofollow noreferrer">their website</a>, so can we therefore still use Firebase Authentication and be GDPR compliant?</p>

<p>Using US-based services is not necessarily illegal – but it's very difficult to do in a GDPR-compliant manner.</p>
<p>The CJEU's <em>Schrems II</em> judgment invalidated the “Privacy Shield” adequacy decision for the US. The court found that the US did not provide an adequate level of data protection, in particular due to national security / surveillance laws like FISA 702 and EO 12333. While European countries also have surveillance laws, the US laws are fundamentally different because the affected (non-US) persons have no real recourse: they can't really sue against overbroad or illegal surveillance.</p>
<p>Adequacy decisions are only one of many “transfer tools” that can allow international data transfers. Other tools include Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), “codes of conduct”, “certification mechanisms”, or as a last resort Art 49 derogations.</p>
<p>SCCs are a pre-formulated contract template provided by the EU that sort out responsibilities between the data exporter in Europe and the data importer in the non-European country. In essence, SCCs translate enough of the GDPR into contract law.</p>
<p>But SCCs are not necessarily valid, and this was also discussed as part of the Schrems II judgement. In <a href="https://edpb.europa.eu/our-work-tools/our-documents/edpbedps-joint-opinion/edpb-edps-joint-opinion-22021-standard_en" rel="nofollow noreferrer">their opinion on the new 2021 SCCs, the EDPB+EDPS</a> summarize the post-Schrems challenges to SCCs (edited to add bullet points):</p>
<blockquote>
<p>In order to be valid, SCCs must incorporate effective mechanisms</p>
<ul>
<li>that make it possible, in practice, to ensure compliance with the level of protection required by EU law</li>
<li>and that transfers of personal data pursuant to these clauses are suspended or prohibited in the event of the breach of such clauses or if
it is impossible to honour them.</li>
</ul>
</blockquote>
<p>In essence, a company can't sign SCCs if they are also subject to laws (such as US spy laws) that are incompatible with these SCCs.</p>
<p>Whether SCCs are valid in a particular context is not for the EU to decide, but for the data controller to determine.</p>
<ul>
<li><p>In particular, it is possible that SCCs alone are not sufficient. They are just a contract and cannot bind the authorities in the host country of the data importer. Thus, it may be necessary to implement supplemental measures to protect the transfer that makes the personal data worthless if it falls into the wrong hands. After Schrems II, the <a href="https://edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en" rel="nofollow noreferrer">EDPB published recommendations on such supplemental measures</a>, for example end to end encryption where the data importer never gets access to the keys. But this prevents use of nearly all SaaS/cloud services, perhaps with the exception of dumb backup storage.</p>
</li>
<li><p>In a different direction, industry has focused on a “risk based approach” to data  transfers. For example, the IAPP has a <a href="https://iapp.org/resources/article/transfer-impact-assessment-templates/" rel="nofollow noreferrer">transfer impact assessment template</a>. While this departs from the CJEU/EDPB interpretation, it might be a valid approach for EU–US transfers if and ony if you believe that US laws have since changed, so that Schrems II would be outdated.</p>
</li>
</ul>
<p>In all of this, the new 2021 SCC templates do not quite help. I think the new SCCs are very good since they address many issues with the previous (pre-GDPR) templates, but they do not magically negate Schrems II issues. Nothing the EU commission can do by itself can help here, whether this is new SCCs or negotiations for a new Privacy Shield treaty. The Schrems II issues can only be resolved (a) by amending the GDPR to drastically lower the protections for international transfers, or (b) by an act of the US Congress introducing stronger checks and balances into relevant spy laws, in particular providing real legal recourse for affected non-US persons.</p>
<p>So yes, you can absolutely use the US-based Google Firebase Auth service, if one of the following holds:</p>
<ul>
<li>Your analysis has determined that Google is not subject to problematic surveillance laws.</li>
<li>The EU or US legal environment have significantly changed since Schrems II.</li>
<li>You believe that you and Google have implemented sufficiently strong supplemental measures so that the US couldn't get their hands on your user's data even if it wanted to.</li>
<li>You subscribe to the “transfer risk assessment” school of thought and, as a result of such an assessment, believe that Google is unlikely to receive problematic requests from US intelligence agencies regarding your user's data.</li>
<li>(unethical: considering how unlikely it is to get sued or fined, do the transfer anyway)</li>
</ul>
<p>Given all of this trouble, it might end up being easier using a different authentication service. Google is notorious for struggling with data residency requirements, whereas other cloud services generally let you select the region(s) where data is processed and stored.</p>

gdpr