When “Sign in with Google” Becomes “Google Acting as the User”: What the Recent Lawsuits Mean for Indian Regulation

A spate of high-profile lawsuits and settlements against Google over its data collection practices has shifted the public and legal conversation from are they tracking us? to how and when do third-party integrations let platform providers collect and monetise behavioural data? A recent U.S. jury verdict (Sept 2025) ordering Google to pay roughly $425 million for continuing to collect app activity data after users thought they had opted out is a stark reminder: integrations that sit “behind the scenes” including Single Sign-On (SSO) and embedded SDKs can lead to extensive, unexpected data flows.

For India’s DPDPA regime, which places notice, consent, purpose limitation, transparency, and fiduciary accountability front and centre, these developments matter a great deal. Below I explain how Google SSO and similar identity integrations can enable behavioural collection, why courts are scrutinising these practices, and how organisations in India should respond to remain compliant.

1) How Google SSO / OAuth works and where behavioural data leaks happen

At a high level, OAuth-based SSO («Sign in with Google») lets a user authenticate with an identity provider (IdP) and with consented scopes share specific account attributes (email, name, profile picture) with a relying party (RP / third-party app). That basic flow is simple and useful. But in practice:

• Many RPs also embed vendor SDKs, analytics libraries, advertising SDKs or other Google code (e.g., Firebase, Google Play services) which run inside the same app/web session. Those SDKs can collect app activity, device identifiers, telemetry and other behavioural signals. Academic studies of OAuth/SSO and SDKs document these privacy vectors and how scope/permission UIs often obscure them.
• When a third-party app integrates Google services (login, maps, analytics), Google’s code can be triggered in contexts that go beyond identity verification. for example, telemetry or background app activity linking a user/device to behaviours across apps. That’s what recent litigation focuses on: collection of cross-app behavioural signals via embedded Google services.

Put simply: SSO authenticates but the same integration stack often also collects behavioral signals, which may be processed and monetised by the IdP/platform (Google) even if the RP only intended to authenticate.

2) Recent Google Privacy Lawsuits

Key recent actions show two things:

• Regulators and juries are prepared to treat platform data collection through embedded SDKs/integrations as privacy violations when user controls are ineffective or misleading. In Sept 2025 a federal jury found Google liable for collecting app activity despite users disabling “Web & App Activity” covering nearly 100 million users. Google said it will appeal. This case is part of a wider pattern (Texas $1.4B settlement, other browser/Incognito suits, YouTube children’s privacy settlement).
• Courts examine the design of privacy controls and whether they deliver the expectations they create. If a UI suggests a user opted out, but the platform continues collecting via other code paths, that is legally risky.

While these suits concern large U.S. statutory frameworks and consumer protection law, the legal and factual pattern is instructive globally including under the DPDPA.

3) How this maps to DPDPA obligations (notice, consent, fiduciary duties)

a) Notice (prior, clear, itemised)

DPDPA requires notice before collection, specifying purpose, categories of data, recipients, retention, and withdrawal rights. If an RP relies on “Sign in with Google” and a Google SDK also collects behavioural data, the RP must ensure the notice shown to users covers all actual data flows including indirect collection by the IdP via embedded services. An omission here risks invalid consent. (DPDPA’s notice + consent regime is purpose-specific and expects transparency.)

b) Specific & informed consent

Consent must be specific to purposes and data categories. A generic “I agree to the privacy policy” at sign-in is weak. If Google (or any IdP) will receive additional behavioural telemetry due to SDKs, the RP should disclose that clearly and obtain consent for those specific uses. Otherwise, the consent may be challenged as uninformed.

c) Data fiduciary vs processor allocation

Under DPDPA, the roles of Data Fiduciary, Data Processor, and Data Trustee are important. When integrating an IdP:

• The RP is a fiduciary for the user’s relationship with the RP.
• The IdP (Google) is a fiduciary for its own processing but where does liability sit if the RP’s integration causes additional collection without adequate notice? Both parties will face scrutiny: the RP for failing to disclose, the IdP for its own collection practices and how transparent its SDKs are.

d) Purpose limitation, minimisation and accountability

DPDPA’s principles of data minimisation and purpose limitation mean only necessary data should be collected for authentication. Collecting broad behavioural signals across apps, especially for monetisation, undermines minimisation and triggers regulatory risk.

4) Specific legal risks illustrated by the Google cases (what regulators/judges are looking at)

• Misleading controls: Do user settings (e.g., “Web & App Activity off”) actually prevent collection? If not, this is misleading and actionable.
• Hidden flows: Collection via embedded SDKs that users do not expect courts view these skeptically.
• Scale of impact: Class actions and state suits indicate that when millions are affected, damages and settlements escalate (Texas settlement, etc.).

5) Real-World Examples of How Google SSO Integrations Create Privacy Risks

1. App A uses “Sign in with Google” to authenticate users. It also includes Firebase for crash reporting and Google Analytics. The Firebase SDK collects app usage events and device identifiers and sends them to Google. User disables Web & App Activity thinking they halted all tracking but telemetry still flows. Result: user expectation vs reality mismatch; legal exposure. (This mirrors claims in recent suits.)
2. Web service lets users sign in with Google on multiple RPs. A user believes each RP only knows their email. Yet Google links signals across RPs and builds behavioural profiles. Without explicit disclosure and consent for such linkage, DPDPA issues arise.

6) DPDPA Compliance Checklist for Apps Using Google Sign In

Below is an action checklist for RPs (app publishers, service providers) who use Google SSO or similar identity providers.

Immediate (technical + product)

• Map all SDKs and vendor libraries included with authentication flows. Identify what telemetry they collect (app events, device IDs, background pings).
• Adopt least privilege: include only libraries necessary for login; avoid bundling advertising/analytics SDKs in the same process if not needed.
• Ensure scopes requested in OAuth are minimal and clearly match the purpose (authentication vs data access).
• For web flows, separate authentication cookies from tracking cookies; do not piggyback telemetry collection during auth.

Notice & consent design

• Update notice text shown prior to SSO/authentication to disclose:
  • That third-party libraries embedded in the app may send app activity to the IdP/platform.
  • The categories of behavioural data that may be collected and by whom.
  • Any commercial uses (ad targeting, profiling) if applicable.
• Use just-in-time micro-notices at authentication that link to an expanded, itemised notice. DPDPA expects clarity and purpose specificity.

Accountability & contracts

• Update vendor contracts with IdPs and SDK providers: require transparency about what is collected, data retention, and how users can exercise rights.
• If using Google services that collect telemetry, require contractual assurances about not using that data in ways that contradict your notice.

Evidence & audit

• Maintain consent receipts documenting the notice text, OAuth scopes, time, device, UI version, and user affirmative action. This will be key in disputes or regulator inquiries.
• Log SDK versions and release notes (forensics: “which version of Firebase was bundled?”).

User controls & remediation

• Provide clear opt-out paths within your product and link to Google account privacy controls where possible.
• Offer deletion/withdrawal mechanisms and ensure they propagate to aggregated behavioural profiles if you depend on a platform for such profiles.

7) What regulators should consider (policy implications under DPDPA)

• Transparency obligations for IdPs: regulators may ask IdPs to publish clear, standardised disclosures for developers explaining what their embedded SDKs collect and when.
• Standard consent receipts: require a standard machine-readable consent artifact (consent cart or receipt) listing authentication scopes plus any telemetry collection by embedded libs.
• Certification of SDKs: consider a certified-SDK regime or disclosure registry so developers and users can see, in plain language, what each library does.

8) For consumers

• On a new app, inspect permissions/scopes at the time of SSO. If an auth flow asks for wide access (“manage your Drive”), pause.
• Review Google account settings (Web & App Activity, Ad Personalisation) and periodically audit third-party app access in your Google Account (Security → Third-party access).
• If concerned, prefer email-only or passwordless authentication options from RPs that do not embed broad telemetry SDKs.

9) why this matters under DPDPA

The core lesson from the Google litigation is that data collection is often multi-layered: what the RP thinks it’s asking for (authentication) can differ materially from what the platform/SDK collects (behavioural telemetry across apps) and courts will look to whether users were given an effective, comprehensible notice and a real choice. Under DPDPA’s notice + consent + fiduciary accountability framework, Indian organisations cannot hide behind “we only asked for login” when their integration stack leaks behavioural data to platform vendors.

Selected sources & further reading

• Reuters: “Google must pay $425 million in class action over privacy” (Sept 2025).
• The Verge coverage of the jury verdict.
• Academic analyses on OAuth privacy implications: “Exploring Privacy Implications in OAuth Deployments” (Morkonda et al.).
• Research on SSO/third-party app security & privacy: “Security and Privacy Perceptions of Third-Party Application Access for Google Accounts” (Balash et al.).
• Background on the class action & claims site (Rodriguez v Google LLC).