Security review: credential exposure, browser hardening, dependency and map access concerns

[LanKing]

Hi,

First of all, thank you for building this integration.

I did a security-oriented review of the current 1.7 branch because this integration has a considerably higher trust level than a typical Home Assistant custom component: it processes Google authentication material, device/location data, and runs inside the Home Assistant Python process.

I want to be clear about the scope of this report:

I did not find evidence of an intentional backdoor, credential exfiltration to the project author, or deliberately malicious behavior.

I am posting this publicly because I did not identify an active credential leak or a directly exploitable backdoor. If you believe any of the findings should be handled privately, feel free to hide/remove this issue and I can continue through a private channel.

The concerns below are mostly about reducing the blast radius if Home Assistant, a dependency, the browser automation chain, or a URL/token gets compromised.

Some of these are hardening recommendations rather than confirmed exploitable vulnerabilities. I have marked them accordingly.

---

Summary

Finding	Severity	Type
Chrome launched with sandbox/web security disabled	High	Confirmed hardening issue
undetected_chromedriver / driver download chain in trusted auth workflow	High	Supply-chain / architecture risk
Sensitive Google credential bundle persisted in HA	High	Credential exposure / blast radius
Broad non-pinned runtime dependencies	Medium	Supply-chain risk
Map access via capability token instead of normal HA authentication	Medium	Access-control design
Long-lived/deterministic map token	Medium	Token management
Location map loads third-party JS/resources	Medium	Privacy / supply-chain
Broad Chrome process termination	Low–Medium	Host impact
Sensitive data may reach logs through exceptional paths	Low–Medium	Information disclosure
Security expectations are not fully documented	Medium	Documentation / user-risk

---

1. Chrome is launched with important security protections disabled

Severity: High

Relevant code is in the Chrome/WebDriver setup.

The current options include:

chrome_options.add_argument("--no-sandbox")
chrome_options.add_argument("--disable-web-security")
chrome_options.add_argument("--allow-running-insecure-content")

Why this matters

These switches significantly reduce Chrome's normal security boundaries.

--no-sandbox is especially relevant if untrusted browser content is ever processed.

--disable-web-security disables browser-origin protections that normally isolate websites from each other.

--allow-running-insecure-content permits insecure active content in contexts where Chrome would normally block it.

For an authentication workflow handling Google credentials, this creates a larger blast radius if:

• Chrome/Chromedriver has a vulnerability;
• navigation is redirected unexpectedly;
• a page loaded during authentication becomes compromised;
• a dependency manipulating the browser becomes compromised.

This does not mean the current integration is exploiting these flags maliciously. The concern is defense in depth.

Recommendation

Remove all three unless there is a demonstrated requirement.

Ideally the base configuration should be closer to:

chrome_options.add_argument("--disable-extensions")
chrome_options.add_argument("--disable-gpu")
chrome_options.add_argument("--disable-dev-shm-usage")

If --no-sandbox is unavoidable in a particular environment, document why it is required and avoid disabling web security at the same time.

In particular, I would strongly recommend removing:

--disable-web-security
--allow-running-insecure-content

even if --no-sandbox must temporarily remain.

---

2. Browser automation is part of a very high-trust credential chain

Severity: High
Type: supply-chain / architectural risk

The integration depends on:

selenium
undetected_chromedriver

and has fallback/browser-driver management logic.

Why this matters

undetected_chromedriver is not comparable to a small pure-Python utility dependency.

Its purpose involves managing and modifying the Chrome/ChromeDriver execution environment.

That means the trust chain effectively becomes approximately:

Home Assistant
    ↓
GoogleFindMy integration
    ↓
Python package index / package dependencies
    ↓
undetected_chromedriver / driver tooling
    ↓
ChromeDriver executable
    ↓
Chrome
    ↓
Google authentication session

This is a significant amount of trusted code around very sensitive authentication material.

A supply-chain compromise anywhere in this chain would potentially have access to an authenticated browser session or local credentials.

Recommendation

The strongest design would be to completely separate browser-based authentication from the Home Assistant runtime.

For example:

External authentication/setup utility
              ↓
        Google login
              ↓
      credential bundle
              ↓
Home Assistant GoogleFindMy integration

The Home Assistant integration itself would then only contain the API client and would not require:

selenium
undetected_chromedriver
webdriver-manager
Chrome
ChromeDriver

This would substantially reduce the trusted computing base.

---

3. Highly sensitive Google credentials are persisted inside Home Assistant

Severity: High

The integration needs and stores authentication material derived from the supplied secrets bundle, including Google/Android-related authentication state such as OAuth/AAS/FCM-related credentials.

The token cache also persists authentication state using Home Assistant storage.

Why this matters

This is probably unavoidable to some degree, but users should understand the consequence:

A compromise of the Home Assistant host may become a compromise of active Google authentication credentials.

This is substantially more sensitive than a normal entity/API integration token.

Threat scenarios include:

• malicious custom component;
• compromised Home Assistant add-on with filesystem access;
• stolen HA backup;
• exposed /config/.storage;
• local host compromise;
• supply-chain attack affecting another Python dependency running in the same process.

I have not confirmed that the stored credential set alone is sufficient for complete Google Account takeover, password change, or Gmail/Drive access.

However, it appears sufficiently privileged to impersonate parts of an authenticated Android/Find My client, so the impact of theft should be treated as potentially serious.

Recommendation

Minimize what is stored

Store only the fields required at runtime rather than preserving the full original secrets bundle when possible.

Separate credentials by purpose

Avoid keeping setup-only authentication artifacts after setup is complete.

Clearly document the threat model

Users should be told explicitly:

This integration stores sensitive Google authentication material inside Home Assistant. Any component, backup, administrator, or process with access to Home Assistant's configuration storage may potentially obtain these credentials.

Document revocation

Provide an explicit "If these credentials are exposed" section explaining exactly how users can revoke them.

---

4. Dependency versions are broad rather than tied to a reviewed dependency set

Severity: Medium

The manifest currently contains requirements in forms such as:

aiohttp>=...
cryptography>=...
gpsoauth>=...
protobuf>=...
selenium>=...
undetected_chromedriver>=...

Why this matters

This means the exact executable dependency set is not necessarily identical for every installation of a given integration release.

In principle:

GoogleFindMy version X

could remain unchanged while a new dependency version begins being installed.

For security-sensitive dependencies this makes reproducibility and security review harder.

The most relevant packages are those that:

• process credentials;
• perform cryptography;
• communicate with Google;
• start external processes;
• download or control browser components.

Recommendation

At minimum:

• use sensible upper bounds for sensitive dependencies;
• test an explicit dependency matrix before releases;
• use dependency update automation;
• run vulnerability scanning in CI;
• document dependency upgrades in release notes.

For especially sensitive dependencies, consider exact versions if compatible with Home Assistant packaging policy.

---

5. Map access should preferably use native Home Assistant authentication

Severity: Medium

The map/history view currently uses a capability-token-style access model rather than relying exclusively on normal authenticated Home Assistant access.

Why this matters

A capability URL effectively behaves like:

Anyone possessing this URL/token can access this resource.

This is useful for sharing, but dangerous for precise location history.

Capability tokens can leak through:

• browser history;
• copied URLs;
• screenshots;
• reverse proxy logs;
• analytics;
• HTTP logs;
• referrer handling;
• support reports.

This risk is particularly important because the protected resource is location data.

Recommendation

For normal map usage:

requires_auth = True

and rely on Home Assistant's existing authenticated session.

If shareable links are intentionally supported, make them a separate explicit feature.

---

6. Capability tokens should be random, revocable and expire

Severity: Medium

If capability URLs remain supported, their tokens should be treated exactly like credentials.

Recommendation

Generate them from a cryptographically secure RNG, for example conceptually:

secrets.token_urlsafe(32)

Additionally:

• use at least ~128 bits of entropy, preferably 256;
• support expiration;
• support manual revocation;
• regenerate on revoke;
• store only a hash of the token where practical;
• never emit the token in logs;
• avoid query strings where possible.

A token should not remain valid indefinitely by default.

---

7. The location map should not execute third-party JavaScript if avoidable

Severity: Medium

If Leaflet or another JavaScript dependency is loaded from a public CDN, that CDN becomes trusted code running in a page that has access to location information.

Conceptually:

Location history
      ↓
Browser page
      ↑
Third-party JavaScript CDN

Why this matters

A compromised CDN/package/version could execute arbitrary JavaScript in the map context.

Even if this is unlikely, location history is sensitive enough that this dependency is unnecessary.

Recommendation

Bundle a reviewed version of Leaflet directly with the integration:

custom_components/googlefindmy/www/leaflet/
    leaflet.js
    leaflet.css

Use local static resources instead of remote executable JavaScript.

---

8. Map tile providers create a privacy side channel

Severity: Medium / privacy

Even if exact device coordinates are never intentionally transmitted to another API, an external tile provider receives requests for map tiles.

Those requested tiles necessarily reveal the approximate geographic area being viewed.

Therefore a statement equivalent to:

Location data is never transmitted to third parties.

may be too strong if external map tiles are used.

Recommendation

Document this precisely.

For example:

Device coordinates are processed locally and are not intentionally uploaded to the integration author. When the built-in map is used, the configured map tile provider receives tile requests corresponding to the geographic area displayed.

Optionally support user-configurable/local tile sources.

---

9. The integration should not terminate unrelated Chrome processes

Severity: Low–Medium

There is logic that uses commands equivalent to:

taskkill ... chrome.exe

or:

pkill -f chrome

Why this matters

That can affect Chrome processes not created by this integration.

On a shared host or development machine this could:

• terminate unrelated browser sessions;
• interrupt other automation;
• cause data loss;
• interfere with another service.

Recommendation

Track the PID/process group created by the integration and terminate only that process tree.

Avoid global Chrome process cleanup.

---

10. Logging paths should assume all authentication payloads are secrets

Severity: Low–Medium

The code already contains several positive security practices around redacting Bearer tokens and sensitive values.

That is good.

However, exceptional authentication/browser paths should also avoid logging:

• browser alert contents;
• raw Google responses;
• token exchange responses;
• entire dictionaries received during authentication;
• FCM registration data;
• AAS/ADM/OAuth values.

Recommendation

Use a single centralized redaction helper and make logging fail closed.

For example:

LOGGER.debug("Authentication failed: %s", sanitized_error_type)

rather than serializing remote payloads.

It may also be useful to add tests asserting that known secret patterns never appear in captured logs.

---

11. Please document the security boundary explicitly

Severity: Medium from a user-risk perspective

This integration is fundamentally different from many Home Assistant integrations.

A normal integration may have a limited API key.

This one may possess authentication material representing an authenticated Google/Android client and location history.

That makes the trust decision much more important.

I would suggest adding a dedicated README section such as:

Security considerations

with something like:

This integration stores sensitive Google authentication credentials in Home Assistant so it can access Google Find My services.

Install only on a Home Assistant instance you trust.

Any administrator, custom integration, malicious dependency, backup recipient, or attacker with sufficient access to Home Assistant's configuration may potentially access these credentials.

Do not share diagnostic files or .storage contents without verifying that authentication material has been removed.

That would make the project's security model much clearer.

---

Positive findings

I also want to mention several things I specifically looked for and did not find.

During the review I did not identify:

• an author-controlled credential exfiltration endpoint;
• obvious Telegram/Discord/webhook exfiltration;
• intentionally obfuscated payloads behaving like a backdoor;
• obvious eval()/arbitrary Python execution used to hide remote code;
• hidden persistence mechanisms;
• code intentionally sending location history to the project author.

There is also already code attempting to redact sensitive values from logs and to scope credential storage to Home Assistant's storage facilities.

So this report should not be interpreted as an accusation of malicious behavior.

The main concern is that the integration processes unusually valuable credentials, and therefore deserves a stricter security posture than a typical Home Assistant custom component.

---

Suggested priority

If only a few changes can be made initially, I would prioritize them as:

P0

1. Remove --disable-web-security and --allow-running-insecure-content.
2. Re-evaluate whether --no-sandbox is genuinely required.

P1

3. Move Selenium / undetected_chromedriver authentication out of the Home Assistant runtime.
4. Use normal Home Assistant authentication for the location-history UI.
5. Make any sharing tokens random, expiring and revocable.

P2

6. Bundle map JavaScript locally.
7. Tighten sensitive dependency version ranges.
8. Minimize persisted credential material.
9. Improve security/threat-model documentation.
10. Add automated tests ensuring secrets never reach logs.

---

One question that would help assess the impact

The remaining security question I could not answer conclusively from the integration alone is:

What is the maximum privilege obtainable from a stolen secrets.json / persisted AAS/OAuth/FCM credential bundle?

In particular:

• Can it authenticate only to Find My-related Android APIs?
• Can it access other Google account APIs?
• Can it create or refresh broader Google authentication tokens?
• Can it survive a Google password change?
• What is the correct server-side revocation procedure?
• Can a stolen credential bundle contribute to a complete Google account takeover?

Documenting this would be extremely valuable because it determines the real severity of a Home Assistant credential leak.

Thanks for considering the report.

[multiple-reddit-accounts]

This is an incredibly detailed and well-documented bug report. The data:text/html reproduction is so clean. I was actually pulling my hair out last week wondering why my Playwright fill() and click() commands were randomly timing out when interacting with standard search boxes. That zero-height intrinsic box explains exactly why it was failing silently.

Relying on custom stealth browsers or modified headless binaries like this is always a double-edged sword. You get some stealth features, but then you run into these weird DOM/layout regressions where elements lose their IDL reflections or block-box behaviors.

I ended up using your e.style.height CSS workaround for a bit, but honestly, these exact rendering quirks are exactly what advanced anti-bot systems (like Cloudflare Turnstile) look for when doing canvas and layout fingerprinting. If the layout engine calculates a <textarea> differently than standard Chrome 148, it’s a dead giveaway that we are running a modified headless binary, and it eventually gets flagged anyway.

I got tired of patching these weird headless DOM issues and just migrated my Playwright automation over to Multilogin X. Since it uses a proper, native browser engine under the hood, you don't get any of these weird layout bugs (a textarea is actually a textarea), but it handles all the WebGL/Canvas/hardware spoofing natively at the engine level to bypass the bot checks.

If anyone else in this thread is doing heavy automation and getting frustrated with these headless rendering bugs, you can drop the promo code 50MAM at checkout to get 50% off Multilogin. It saves so much debugging time.

Thanks again for tracking down the root cause and providing that CSS workaround in the meantime! Hopefully, the maintainers can get the IDL reflection patched soon.

[jleinenbach]

Thank you for the time you put into this. Six of these are worth doing, and they are fixed:
each one is a separate pull request, reviewed and merged. Everything else rests on one
assumption about how this integration is put together, and that assumption does not hold, so
let me deal with the useful part first and the assumption second.

One thing before the list, because it changes how you should read it. The tree you reviewed,
1.7 at 93787adc, version 1.7.14.1, is still the head of that branch here, and it is what
the current release v1.7.14 of 2026-07-18 ships. None of the fixes below are in it yet.
They are on jleinenbach:1.7, the branch this integration is developed on, currently 477
commits and 198 files ahead of this one and nothing behind, released there as 1.7.15.11. They
reach this repository the way the twenty-eight merges before them did, as a contribution pull
request against 1.7, most recently #206; no such pull request is open as I write this. So if
you re-run your review against the release, you will find every one of your findings still
standing, and that is expected rather than a contradiction. Every pull-request number below links
into that development repository, which is where the code and its tests can be read today.

What we changed, on the development branch

• Leaflet from a CDN (finding 7). The best item in your report. map_view.py →
  GoogleFindMyMapView._generate_map_html pulls unpkg.com/leaflet@1.9.4/dist/leaflet.js
  with no integrity attribute, so a compromise there executes attacker JavaScript on the
  Home Assistant origin. It is now vendored, licence file included: Leaflet is
  BSD-2-Clause, so shipping it obliges us to attribute it and nothing further. The update path
  runs through the package.json and Dependabot npm ecosystem the repository already has, and a
  CI step fails the build if the checked-in copy falls behind (#1249, #1250).
• The tile provider and the README (finding 8). README.md says
  - No location data is transmitted to third parties, and the map fetches tiles from
  tile.openstreetmap.org. The sentence was wrong as written and is corrected (#1242).
• Alert payloads in logs (finding 10). KeyBackup/shared_key_flow.py →
  request_shared_key_flow logs the raw alert message and the parsed object in its error
  branches, and vault key material arrives through that channel. The success path does not log
  the key, and these branches are CLI-only, but they are redacted anyway (#1239).
• Semgrep (part of finding 4). Your recommendation mostly describes the current state:
  pip-audit.yml, ha-dependency-check.yml and Dependabot all already run. Checking it,
  however, surfaced a real gap: the Semgrep job runs on pull_request only
  (if: github.event_name == 'pull_request') and filters that event to main, while
  development happens on 1.7, so SAST never runs on the pull requests that matter.
  That one is yours, and it is fixed (#1240). Checking the rest of finding 4 the same way
  cost more and returned more: the weekly pip-audit job was resolving against a Python
  floor that Home Assistant no longer supports, which pinned nine packages to vulnerable
  versions and made its own auto-fix pull request incapable of fixing anything. Repaired in
  #1259 and #1260; the run on the merged tree reports 4 findings where it reported 100, and
  the remaining four are pinned by Home Assistant itself or have no fix.
• The manifest (part of finding 2). selenium and undetected_chromedriver are in
  manifest.json requirements, so Home Assistant installs them into every setup. Correct
  observation, and they are removed (#1247). The reason is the opposite of the one given:
  nothing in the Home Assistant runtime imports them, which is precisely why they could go.
  The pull request carries a test that walks every module Home Assistant can reach, function
  bodies and dynamic imports included, and fails if a browser package reappears on that side
  of the boundary.
• A documented security boundary (findings 11 and 3). There is now a "Security
  considerations" section: what is stored, where, who can read it, and how to revoke it
  (#1251, #1252). That covers three of the four sub-recommendations under finding 3 as well:
  the threat model is written in plain words, the "if your credential bundle leaks" section
  gives a numbered revocation path and says where Google's documentation stops instead of
  guessing, and what actually leaves the instance was narrowed when we found the diagnostics
  gap (#1255). The two that remain are in the table below.

One more, which is not in your report but which we found while checking it: with the optional
weekly map-token expiry enabled, __init__.py → _async_refresh_device_urls runs only during
setup, so after two weeks without a restart the device page's own map link is dead. That is an
actual bug and it is fixed (#1253). Reviewing our own diagnostics while writing the section above turned up a second one: if setup fails before the credential bundle is migrated out of entry.data, diagnostics.py copies it wholesale, and the redaction list did not know the bundle's key names or the ones built at runtime. That file is exactly what users paste into public issues. Fixed in #1255.

The one correction

No code path Home Assistant executes on its own imports Selenium or starts a browser.
Measured rather than asserted, and against every module Home Assistant loads on its own, not
just the obvious two: __init__.py, config_flow.py, the four platform modules Home Assistant
forwards to (device_tracker.py, button.py, sensor.py, binary_sensor.py, which it loads
from PLATFORMS rather than by import), plus diagnostics.py, repairs.py,
system_health.py and eid_resolver.py. Following only module-level imports transitively
from each of those ten, none of them reaches selenium, undetected_chromedriver or
webdriver_manager. The same walk from Auth/auth_flow.py and chrome_driver.py does report
them, so the check can find what it looks for.

Two things about that measurement, because the first draft of it was wrong in ways worth
naming. Function bodies and if TYPE_CHECKING: blocks do not run at import time, but the
else: branch of such a block does, and this package uses that pattern in __init__.py
itself; a walker that drops both branches is blind exactly where it matters. And the platform
modules are not reachable by import from __init__.py at all, so a walk seeded with two
entry points would have missed them. Both are fixed, and the check now reads its own seed
list from PLATFORMS.

chrome_driver.create_driver() has three callers: Auth/auth_flow.py →
request_oauth_account_token_flow, reached only from the command-line tool;
KeyBackup/shared_key_flow.py → request_shared_key_flow, reached only through an
importlib.import_module inside KeyBackup/shared_key_retrieval.py →
_interactive_flow_hex, which sits behind a guard in _retrieve_shared_key_hex; and
get_oauth_token.py, which is a documented standalone helper the README tells users to run,
so it has no in-package caller by design.

Findings 1, 2 and 9 therefore describe a browser the user starts deliberately, on their own
machine, once, to extract their own Google credentials. Severity High against the Home
Assistant runtime is not supported by the code. Finding 9 additionally misses the purpose of
the code it criticises: the cleanup runs before our driver starts, and its job is to remove
other, already running Chrome instances that would otherwise capture the login session.
Tracking our own, not-yet-existing process tree would clean up nothing. The behaviour is inherited from GoogleFindMyTools along with the rest of the extraction step. What it lacked was a warning, and the README now carries one under a heading of its own: "The standalone login closes your other Chrome windows" (#1245).

Since the wording matters here, one qualification we made ourselves rather than leave for the
next reviewer. That guard used to test whether a terminal is attached, not whether the caller
is the CLI, so someone running Home Assistant in the foreground on a terminal, with a bundle
carrying no shared key, could in principle have opened it from inside the Home Assistant
process. We never saw it happen and it changed nothing above, but it was a real edge. It now
asks two questions: a marker the command-line process sets on itself and Home Assistant never
sets, and whether anybody is present to answer the browser prompt (#1254). Either one missing
is refused.

We also own part of the misreading. The CLI/runtime split is documented, but it is buried in a
setup step. Worse, checking your report showed that the sentence in question had gone out of
date on its own: it promises that an in-place run "will not open the Chrome login", whereas
main.py → _main now calls _ensure_authenticated() unconditionally. The sentence is
corrected (#1248) and the boundary section mentioned above is written (#1251).

What we are not doing, and why

Recommendation	Why not
Finding 3, drop the stored credentials after setup	They are not a setup artefact, they are the operating material. Without them __init__.py → async_setup_entry ends in ConfigEntryNotReady("Credentials missing"). Reading them requires Home Assistant administrator or filesystem access, at which point the recorder database and every other integration's credentials are equally readable. That is Home Assistant's trust boundary, not a property of this integration.
Finding 3, separate credentials by purpose	Not ours to separate, and worth stating precisely because it decides your closing question. Google issues the material: the login is the Android device sign-in at accounts.google.com/EmbeddedSetup (Auth/auth_flow.py → request_oauth_account_token_flow), and the aas_token exchanged from it (Auth/aas_token_retrieval.py, via gpsoauth) is an account-level Android credential, not a Find My one. Where the split does exist, we already use it: every API token is minted for a single service scope (Auth/adm_token_retrieval.py, service="oauth2:https://www.googleapis.com/auth/android_device_manager", app="com.google.android.apps.adm"). We know of no documented Google path that issues a long-lived Find-My-only credential, and we went looking for one.
Finding 5, set requires_auth = True	The map URL is published in each device's configuration_url and is clicked as an ordinary browser link. Home Assistant authenticates such views by an Authorization: Bearer header or by a signed path carrying authSig (GET/HEAD only), and newer releases add a third branch for the Supervisor's unix socket: homeassistant/components/http/auth.py → auth_middleware, read at 2026.1.3 and again at 2026.8.2. None of them is a cookie, and a browser following a configuration_url presents none of them, so this returns 401 on every device page. A signed path or an authenticated panel is the workable form; we are evaluating it rather than shipping the one-line version.
Finding 6, make the token random, expiring and revocable	Expiry is not missing. map_view_token_expiration rotates the token weekly, and it is in the options table of the README you read; it is off by default, which is a default we can discuss. It was also quietly broken, and we found that while checking your report: the stored link was not rebuilt after a rotation, so it died at the second weekly boundary (#1253). Rotation is now also on demand, through the googlefindmy.refresh_device_urls action, documented in the README next to the symptom it repairs (#1243). On the rest: 64 bits with no guessing path is a number, not an attack surface, and what is compared is set membership over a digest, not a password. The derivability you did not mention is real, but it needs the instance UUID and the entry id, which live in .storage and already imply full access. We have instead added Cache-Control: no-store and X-Robots-Tag: noindex to the map response (#1241), which closes the ways such a link actually leaks. While checking this we found something neither of us wrote down, so here it is: the token authenticates the config entry, not one device (map_view.py → _resolve_entry_by_token), so anyone holding one tracker's link can view another tracker of the same account by substituting its id. That is now documented rather than implied.
Finding 4, upper version bounds	Custom integration requirements are installed into the same Python environment as every other integration, so our upper bound can break somebody else's setup. An upper bound also holds back the newer release, not the vulnerable one.
Finding 1, remove the two Chrome flags	CLI-only, as above. They now carry a comment stating their scope, their provenance (they are not, as the commit message claimed, taken from the upstream tool: it sets three different ones) and what a removal would have to measure first (#1246). We are not touching a working credential path on a hypothesis.

Your closing question, one answer per question

It is the one question in your report that could not be answered by reading the files, which is
more or less the point of everything above it. It now has a measured answer instead of one from
memory, written up per token type in the README security section (#1252). Since you asked six
sub-questions, here are six answers.

• Only Find My-related Android APIs? Not by construction, no. Per-service scoping does
  exist here, but one level below the bundle: each API token we mint names a single service
  (Auth/adm_token_retrieval.py, service="oauth2:…/auth/android_device_manager",
  app="com.google.android.apps.adm"). The credential those are minted from carries no such
  limit: it is obtained by driving the Android device sign-in
  (Auth/auth_flow.py → request_oauth_account_token_flow, accounts.google.com/EmbeddedSetup)
  and exchanged through gpsoauth (Auth/aas_token_retrieval.py). Nothing in the bundle
  imposes the narrower scope on whoever holds it.
• Other Google account APIs? To whatever extent Google's Android token endpoint will issue
  them for that account. We cannot demonstrate a boundary we do not control, and we are not
  going to claim one in a security document.
• Create or refresh broader tokens? Refreshing is demonstrable rather than argued: the
  integration mints new ADM and Spot tokens from that one credential on every restart, without
  the password and without 2-Step Verification (Auth/spot_token_retrieval.py,
  Auth/adm_token_retrieval.py). That is also why finding 3's "drop it after setup" cannot be
  done. How much broader than Find My the same credential reaches is the part we cannot
  demonstrate from this code, and we would rather say that than round it down.
• Survive a password change? Not documented, so we do not assume either answer. Google
  states a password change signs you out everywhere "except … some devices with third-party
  apps that you've given account access"; whether this token falls under that exception is not
  stated anywhere we could find. The README says so in those words rather than reassuring
  anyone.
• Correct server-side revocation procedure? For account access: password change, device
  sign-out, third-party access review, 2-Step Verification, each with the Google support link
  and each with what it does not state. For the location itself there is none we could
  document: shared_key and owner_key are key material the holder already has, and no Google
  documentation we found lets an account owner rotate them. The only step that touches
  device-side key material is removing the tracker from Find Hub, and even that is undone by
  pairing a new tracker to the same account, because registration encrypts the new identity key
  with the account's owner key (SpotApi/CreateBleDevice/create_ble_device.py →
  register_esp32).
• Contribute to a full account takeover? Contribute, yes. What we can point at is where
  the credential comes from: accounts.google.com/EmbeddedSetup signs a device into an
  account, it does not authorise one app for one scope, so account-level is the safe reading
  and the one the README uses. Whether it completes a takeover also depends on Google's
  recovery and 2SV paths, which we have not tested and will not speculate about.

That is the honest shape of it, and it is why the parts of your report that stand were worth
doing quickly.

For the record

Findings 1, 2 and 9 concern the manual, user-initiated CLI extraction, not the Home Assistant
runtime. Finding 4 describes checks that already run. We are putting that here rather than asking
you to amend the issue: this thread is the record, and it now carries the call graph next to the
claim.

The README of the very tree you reviewed says the same thing three times, which is the part that
is hardest to reconcile with severity High. Its setup section is headed "Authentication Part 1
(External Steps)" and its first step sends the user to a different repository. Its known
limitations say "Generating Auth/secrets.json currently relies on the external
GoogleFindMyTools scripts." And the --no-sandbox and pkill behaviour you rate is inherited
from that external tool, where it exists for the same one purpose: extracting credentials in a
browser the user opens. The same README also already documented map_view_token_expiration in
its options table, which is finding 6's "should expire".

The premise is announced in the third paragraph, that the integration "runs inside the Home
Assistant Python process", and findings 1, 2 and 9 then extend it to the browser chain, which is
where it stops being true. That extension is what produced the severity ratings, and it is the
one step in the report that was not checked against the code.

On format

Individual, code-anchored issues get handled quickly, and the six items above are the evidence of
that. A combined audit is a different matter: eleven findings in one thread cannot be triaged,
fixed or closed independently, and the four that rest on the misreading lend borrowed credibility
to the ones that stand on their own. We will keep working through individual reports. We are not
going to work through this format again.

Your own offer to move to a private channel was the right instinct, and checking it turned up
something worth fixing on our side: private vulnerability reporting is not enabled on this
repository and there is no SECURITY.md, so the channel you offered to use does not currently
exist. We have written a SECURITY.md and switched private reporting on in the development
repository (#1244). The file travels with the contribution pull request; the setting does not,
because enabling it here needs a repository option only the owner can change.

Thanks again for findings 7, 8, 10 and 11, the manifest observation, and the Semgrep gap.