More on DataSpii: How extensions hide their grabs and how they’re discovered | Hacker News Reader

More on DataSpii: How extensions hide their grabs and how they’re discovered

arstechnica.com

96 pointssohkamyung24 comments

> The Hover Zoom extension can be seen downloading the 156KB payload

I have tried to find out from the article or the original report[1] how the extensions could execute the payload from remote servers. I could find no details about this -- I consider this one of the key point.

I could download and unzip one of the extension hosted on the owner's server, "SaveFrom.net Helper".

As expected, the manifest.json contained an entry which allows the extension to execute code not part of the package, in the context of the extension (i.e. can access extensions API):

    "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"

I have often pointed out that one of the key issue with the Chrome store is that it allows extensions with ability to execute remote code in extension context[2], this makes it impossible to code review such extension, as it can at any time download and execute code not part of the package.

If privacy and security were a genuine concern, all extensions which ask for `unsafe-eval` should be removed from the Chrome store -- they are essentially un-reviewable.

Firefox's AMO does not allow extensions with such ability.[3]

* * *

[1] https://securitywithsam.com/2019/07/dataspii-leak-via-browse...

[2] https://twitter.com/gorhill/status/1139306139072507906

[3] https://twitter.com/gorhill/status/1139308498825732096

> one of the key issue with the Chrome store is that it allows extensions with ability to execute remote code in extension context

I agree. It is also "strongly recommended against" by the dev page [1]. Do you know a strong argument to allow usafe-eval? (i.e. what would be the rationale of continuing to allow it?)

[1] https://developer.chrome.com/extensions/contentSecurityPolic...

I bet it’s for user script extensions like tamper monkey.

Tamper monkey is also available for Firefox, which doesn't allow unsafe-eval ..

[edit]: just checked, tamper monkey on chrome has the following policy:

"content_security_policy": "script-src 'self' https://ssl.google-analytics.com; object-src 'self'"

Firefox doesn’t allow plugins with unsafe-eval to their store.

Is it possible to prevent an extension from downloading a javascript payload and interpreting it? Eval isn't required.

The default `script-src` policy in extensions is 'self', no JavaScript code outside the package will be allowed to execute.

This seems like a nightmare especially for corporate IT security. I wonder if we'll start seeing more company-wide bans on browser extensions?

I work for on of the companies listed and yes we're working to block extensions internally.

Why do browser extensions do so much worse compared to, say generic Linux software? I think the biggest problem is lack of reputation -- the "value" of being trusted extension author is low, as long as people can find you in the appstore, you'll get the installs.

There are probably many ways to fix this, but one of the least-impactful ways to do so is to use third parties for extension approval -- if extension authors do not care about their reputation, let's find someone else who does!

The system would be simple:

(1) Anyone can publish an "extension whitelist", a list of (extension, version, hash) entries. Maybe it's just a webpage in a special format.

(2) In my browser, I can optionally subscribe to as many extension whitelists as I want.

(3) If I have any whitelist installed, then any extension versions must be on the whitelist. Auto-update does not work if the next version won't be on the whitelist.

That's it! I am sure that once such system is in place, then would be people who would provide such whitelists. There are already people out there that examine source code of extensions they run, as the original article shows.

And additionally, one could make automatic approvals -- say an AV vendor could scan extensions from app store, and automatically make a whitelist of all scanned and safe versions.

This will be a big departure from the current extension model, and it will bring control back to the user.

... and of course, this is why there is approximately 0% chance this or similar idea will ever get implemented. Chrome nowdays is not about user control at all.

hover zoom was known to be spyware long time ago.

https://old.reddit.com/r/chrome/comments/19nndn/hoverzoom_st...

Indeed, and I'm glad I saw the discussion and switched to Imagus and then Hover Zoom+, but if I had missed discussion of Hover Zoom's spyware activity I would have kept using it. We need better mechanisms of keeping people constantly informed about bad extensions, and ideally, ways of shutting them down.

Known to whom?

This is very relevant as part of the broader conversation about defaults and the trade-offs to be made between flexibility for power users and relatively more safety for most users.

This is why we need the changes that Chrome is making to their extension APIs [1][2]. We cannot trust extensions to have access to all URLs since it lets them collect all browsing history and content. Even if they're not doing it now, who's to say they won't sell their extension next year to the highest bidder who will. By forcing content blockers to use a new API that doesn't expose every visit to the extension itself a whole class of _potentially_ bad actors can't turn around and sell your data.

The average consumer that is installing these extensions are not aware of the risks they come with. An extension could easily be collecting usernames and passwords for banks, crypto wallets, etc. They have this ability because the extension requests access to all URLs and it's so common that no one questions it anymore. I'm glad to see Chrome taking steps to limit that access.

[1] https://blog.chromium.org/2018/10/trustworthy-chrome-extensi...

[2] https://blog.chromium.org/2019/06/web-request-and-declarativ...

> I'm glad to see Chrome taking steps to limit that access.

Given your opinion, I think it is important to disclose that your Twitter profile says "Co-Founder @ getadmiral.com"[1] -- Admiral's primary purpose is to counter content blockers[2]. I have repeatedly pointed out that Google's manifest v3 plans will cripple uBlock Origin[3].

* * *

[1] https://twitter.com/jameshartig

[2] "Admiral is the industry’s leading adblock revenue recovery specialists"

[3] https://twitter.com/gorhill/status/1139186208049905664

...and there it is

No one is against the general Active-Tab permission changes that Chrome is proposing, but you're misunderstanding what Chrome's changes to the web request API actually accomplish.

They're not going to improve your privacy and they're not going to improve your security, because the observational capabilities are still going to be available.

And if the new active-tab permissions wouldn't be enough to protect users from the blocking capabilities of the web request API, they're not going to be enough to protect users from the observational capabilities either. Removing blocking abilities isn't really going to slow malicious extensions down.

As a quick side note, this is how roughly 80% of the big public conflicts with the Chrome/web branch of Google go nowadays.

- Google proposes a change that they claim will improve security or privacy.

- People point out that the change doesn't actually improve security or privacy.

- Google wonders out loud why people don't care about security and privacy.

In regards to the web request API, so many developers have explained the problems so many times, that a less charitable me could plausibly claim that the continued implication that extension developers just don't understand security is borderline misinformation.

They stated in [1] that:

> In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options. Instead of being granted access to all URLs on installation, extensions will be unable to request <all_urls>, and instead the user can choose to invoke the extension on certain websites, like they would with activeTab. Additional settings will be available to the user post-installation, to allow them to tweak behavior if they so desire.

To me that reads that extensions won't be allowed to request <all_urls> anymore which would definitely increase privacy since they won't be able to get script access on every website. Some observational capabilities will still be available but from what I'm reading not as many. I would've liked the web request API to be deprecated and discouraged or under heavy scrutiny, if used but there was too much push back.

[1] https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

I mention active tab permissions above -- they're a welcome change, but they're separate from the debate around the imperative vs declarative blocking API.

There are no permission changes that I know of that are being applied to the observational API that couldn't be applied to the blocking API.

There are changes in V3 that are good for privacy -- but the removal of the blocking API will not increase your privacy.

Can any extension still be able to read my browsing history? IE. know what URLs I visit. What Google searches I perform? Even if it's technically harder to implement.

If so, then I totally agree: this change does absolutely nothing! But as expected from Google: this sort of thing has been going on for 5-10 years, and nothing has been done. They got my hopes up yet again.

Short answer yes.[0]

> In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged.

Longer answer, there are multiple good changes coming in V3 (in particular, the introduction of active-tab permissions, which would let you have an extension that can only run code when you explicitly click on it), but those changes aren't really part of the blocking/observation argument that's been happening.

I thought about doing a blog post going into more detail about this at one point, but I figured it was unlikely to make anything change, and that the controversy was old enough that anyone who wasn't already informed wouldn't care any more.

If I'm wrong, maybe I should take a week and write something more detailed.

[0]: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

Chrome's API changes will hurt a substantial part of the extension ecosystem. Google could have dissected the webRequest API by introducing new granular APIs that together would have offered feature parity with the deprecated API functions. But they didn't because it would hurt their bottom line.

Granular APIs would have allowed developers to migrate their extensions in a meaningful way, while users would have been able to allow only the permissions they truly need. Reviewers could have scrutinized extensions which request unrelated permissions.

This is a feature reduction from Google's part with the aim to keep ad blockers in check, while the rest of the many extensions and future use cases that they'll make impossible are casualties that they are willing to accept to protect their profits.

1) With the Manifest V3 changes, will this apply to all already extensions installed before you install the latest version of Chrome? Or only extensions you install AFTER the update?

2) With the Manifest V3 changes, what is exactly stopping an extension from reading your browsing history, and the URLs you visit? I'm not sure I understand what they're changing.

1) I would think that there would be a period where its opt-in for a while before forcing the new API since its not backwards-compatible.

2) Nothing necessarily other than them rejecting extensions that access all URLs now if they don't need them.

Reply on news.ycombinator.com