Chrome extensions spying on users' browsing data

Extension capabilities & security concerns

• Several comments stress that browser extensions often have far broader access than users realize, including page contents and potentially password fields.
• Others dispute details (e.g., whether scripts can read password inputs), but agree the model is fragile and backwards compatibility makes tightening it hard.
• People highlight that even “simple” extensions (UI tweaks, focus tools) can exfiltrate full URLs, including query params and auth tokens, making this more than just “history” spying.

Trust, monetization, and sell‑outs

• Multiple extension authors report constant buyout offers priced per user, clearly aimed at turning popular extensions into spyware.
• Commenters note it’s easy to see why developers in weaker financial positions sell, which undermines long‑term trust in any extension that can change hands.
• Past examples like Stylish’s sale and subsequent spyware behavior reinforce this pattern.

Open source, auditing, and supply‑chain risk

• Many advocate using only open source extensions with known maintainers, and in some cases self‑hosting or forking sensitive ones.
• Others point out limits: store builds might not match GitHub code; updates can introduce malware; code is often minified/obfuscated; and the xz incident shows sophisticated backdoors can evade casual audit.
• There’s discussion of reproducible builds, provenance systems (npm, PyPI), and the desire for “source hashes” or trusted publishing for extensions, but no consensus on a complete solution.

Store governance & platform responsibility

• Strong criticism that the Chrome Web Store is “basically unregulated” and that Google, despite vast resources, leaves this work to independent researchers.
• Some suggest Google may detect issues but not disclose them; others call this speculation.
• Mozilla is viewed somewhat more favorably due to its “Recommended” program and readable-source requirements, but it’s unclear how far this protection extends.

User practices & mitigations

• Many advocate minimizing extensions overall; others argue the web is so broken that rich extension use is essential (ad blocking, UI fixes, automation).
• Suggested mitigations:
  • Prefer a very small, vetted set (often uBlock Origin, password managers, containers).
  • Disable auto‑update or lock versions (with trade‑offs on security fixes).
  • Load extensions unpacked from reviewed source; audit local extension files.
  • Use tools to be notified on extension updates or to block extension network traffic at the browser level.
  • Check installed extensions against published “bad lists”; some small scripts and web tools are shared for this.

Ideas for better models

• Proposals include: user‑scoped permissions per domain, mandatory clear logging of outbound extension traffic, stronger vetting before store acceptance, deterministic code review tooling (possibly LLM‑assisted), and key‑based ownership with explicit user prompts on ownership or key changes.
• There’s debate over blacklist vs whitelist approaches and whether open, community‑run scanning tools would just help attackers evade detection.

Research scope and ongoing risk

• The researchers note their scan almost certainly missed many malicious extensions; sophisticated ones detect lab environments and use obfuscation or remote code.
• Several comments emphasize that even removing bad extensions doesn’t erase the “profile” already built and sold; the downstream use of collected data is largely unaddressed.