Live data from Hacker News

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

arstechnica.com

11–20 of 26 posts

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

#12

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 itse…

> 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

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

#13
post #6

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.

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

#14

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 itse…

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.

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

#15
post #12

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 itse…

> 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 ad…

[deleted]

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

#16
> 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

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

#17
post #16

> 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…

> 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...

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

#18
post #17
post #16

> 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…

> 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.

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

#19
post #17

Earlier quoted context omitted.

> 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'"

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

#20
post #19

Earlier quoted context omitted.

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.
Post reply on HN