18 ms·

There are already ways to limit access to the webRequest API using host permissions, for which the user gives explicit consent. Once the host can be accessed t

There are already ways to limit access to the webRequest API using host permissions, for which the user gives explicit consent. Once the host can be accessed the webRequest API isn't even needed to rewrite requests and read or modify page content, all of it can be acomplished using content scripts. There are really no meaningful security or privacy benefits in limiting the webRequest API in ways that are being proposed by the Chrome team.

joshuamorton 7y ago
I don't think the host permissions do what you think they do. 1. They don't address the performance issue. 2. They still allow redirection of requests, which is a bigger security issue. V3 fixes 2, which is a security issue, and a unique one if your threat model is a malicious extension.
- dessant 7y ago
  Host permissions are required to access the requests through the webRequest API. Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API. The performance impact is negligible in sensibly implemented extensions, and there are several other ways to make the webRequest API more performant if that's really a valid reason for the change, some of which are already implemented in Firefox. I don't believe most honest software engineers would rip out a core functionality of the browser that so many people depend on, just to gain a couple of microseconds, at least not before trying other optimization techniques.
  - joshuamorton 7y ago
    > Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API. Then I'm a bit confused, why does this change cause a problem for ad-blockers? Can't they block and redirect requests via a content script after these changes?
    - dessant 7y ago
      No, you can't block requests from a content script as you would with the webRequest API. You can however redirect the page from a content script, read and replace page content, and steal passwords. The webRequest API gives you fine control over all requests on the page in a performant way. A content script based ad blocker would be able to block ads to some degree by removing the DOM elements that initiate the request, though it would be limited, prone to breaking, and not performant.
      - joshuamorton 7y ago
        Ah. I'm caught up now. That jives with my understanding. (this was meant as an edit to the prior comment, if it seems out of place): Looking into this more, I think what you're saying is that you can request both a content script and a host permission for the webrequest, and the user will approve both at the same time. But you have to specify them differently in the manifest, ie. it looks like permissions: [ "declarativeNetRequest", "<all sites>", // old way ], host_permissions: [ // new way "<all sites>" ], "content_scripts": [ { "matches": ["<all sites>"], "js": ["contentScript.js"] } ], My (limited) understanding is one of the points of the new manifest is to make things more declarative so that they can be statically analyzed. So that, for example, host_permissions "<all sites>" might be allowed, but would require manual review, and content_scripts: ["<all sites>"] could be flagged even more strongly, etc. If you don't specify the content_scripts portion of your manifest, you don't have the ability to write content scripts, so there isn't a security concern, you're limited by the declarativeNetRequest sandbox, and can't do the snooping. For reference, uBlock, which I use, requests a ton in the manifest[0], and there are valid reasons for that (the userscript is, iiuc, for using the content picker). But a minimal ad-blocker could declarativeNetRequest, host:<all sites>, and nothing else, if I'm reading correctly. And that limited footprint can be statically validated. You know that extension can do nothing but modify requests, the way the requests are modified is statically verifiable. That sure sounds more secure to me. [0]: https://github.com/gorhill/uBlock/blob/98271f6140bb188222e2190a06d48398d606fd1e/platform/chromium/manifest.json https://github.com/gorhill/uBlock/blob/98271f6140bb188222e21...

joshuamorton 7y ago

I don't think the host permissions do what you think they do. 1. They don't address the performance issue. 2. They still allow redirection of requests, which is a bigger security issue. V3 fixes 2, which is a security issue, and a unique one if your threat model is a malicious extension.

dessant 7y ago
Host permissions are required to access the requests through the webRequest API. Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API. The performance impact is negligible in sensibly implemented extensions, and there are several other ways to make the webRequest API more performant if that's really a valid reason for the change, some of which are already implemented in Firefox. I don't believe most honest software engineers would rip out a core functionality of the browser that so many people depend on, just to gain a couple of microseconds, at least not before trying other optimization techniques.
- joshuamorton 7y ago
  > Once you have set the host permission, you can redirect requests using a content script, without needing to touch the webRequest API. Then I'm a bit confused, why does this change cause a problem for ad-blockers? Can't they block and redirect requests via a content script after these changes?
  - dessant 7y ago
    No, you can't block requests from a content script as you would with the webRequest API. You can however redirect the page from a content script, read and replace page content, and steal passwords. The webRequest API gives you fine control over all requests on the page in a performant way. A content script based ad blocker would be able to block ads to some degree by removing the DOM elements that initiate the request, though it would be limited, prone to breaking, and not performant.
    - joshuamorton 7y ago
      Ah. I'm caught up now. That jives with my understanding. (this was meant as an edit to the prior comment, if it seems out of place): Looking into this more, I think what you're saying is that you can request both a content script and a host permission for the webrequest, and the user will approve both at the same time. But you have to specify them differently in the manifest, ie. it looks like permissions: [ "declarativeNetRequest", "<all sites>", // old way ], host_permissions: [ // new way "<all sites>" ], "content_scripts": [ { "matches": ["<all sites>"], "js": ["contentScript.js"] } ], My (limited) understanding is one of the points of the new manifest is to make things more declarative so that they can be statically analyzed. So that, for example, host_permissions "<all sites>" might be allowed, but would require manual review, and content_scripts: ["<all sites>"] could be flagged even more strongly, etc. If you don't specify the content_scripts portion of your manifest, you don't have the ability to write content scripts, so there isn't a security concern, you're limited by the declarativeNetRequest sandbox, and can't do the snooping. For reference, uBlock, which I use, requests a ton in the manifest[0], and there are valid reasons for that (the userscript is, iiuc, for using the content picker). But a minimal ad-blocker could declarativeNetRequest, host:<all sites>, and nothing else, if I'm reading correctly. And that limited footprint can be statically validated. You know that extension can do nothing but modify requests, the way the requests are modified is statically verifiable. That sure sounds more secure to me. [0]: https://github.com/gorhill/uBlock/blob/98271f6140bb188222e2190a06d48398d606fd1e/platform/chromium/manifest.json https://github.com/gorhill/uBlock/blob/98271f6140bb188222e21...