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

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

#21

Post by smilliken » Thu, Jul 18, 2019, 6:35 PM UTC

itcrowd wrote: post #17

gorhill wrote: 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...

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

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

#22

Post by gorhill » Thu, Jul 18, 2019, 7:24 PM UTC

smilliken wrote: post #21

itcrowd wrote: 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...

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.

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

#23

Post by ryeights » Thu, Jul 18, 2019, 7:26 PM UTC

gorhill wrote: post #12

fastest963 wrote: post #2

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…

...and there it is

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

#24

Post by theamk » Fri, Jul 19, 2019, 4:17 AM UTC

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.

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

#25

Post by danShumway » Fri, Jul 19, 2019, 7:18 PM UTC

fastest963 wrote: post #10

danShumway wrote: post #4

Earlier quoted context omitted.

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…

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

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.

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

#26

Post by JayOC84 » Fri, Jul 19, 2019, 9:13 PM UTC

kumbel wrote: post #11

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.