> One of these had to give, and Manifest V3 was the most elegant technical approach. Far from being the brainchild of a sociopathic executive, its architecture was devised by well-meaning engineers on the Chrome team.
The Chrome team has some very competent engineers. lcamtuf is a well-respected security engineer. I would expect such a group, trying to solve a problem of poorly behaved extensions, to develop a nice privacy-respecting API to block requests.
For example, there could be a way for an extension to run a portion of itself in a sandbox, such that the sandbox could inspect a request, decide whether to allow it, and output only an indication of whether to allow it. No further outgoing communication, including to the rest of the extension, would be allowed.
> Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use.
Did well-meaning engineers on the Chrome team really come up with a security improvement in which extensions can read request and response headers but not block the requests? I'd love to see an explanation, but to me it seems that the security "improvement" is pretty narrowly tailored to prevent ad-blocking without meaningfully improving privacy.
it's a reasonably difficult problem as you want turing complete computation, but then if you have that you can make state escape the sandbox by blocking/not blocking certain requests and transmit a single bit at a time
you'd think with their legions of competent engineers they'd be able to come up with some way of defeating this attack
but that would hurt the business over the blunt MV3 approach, and you're not going to get promoted for that...
This is a really awkward attack for a couple reasons. In general, a malicious extension may have no way to tell whether a request was blocked — the origin if the request doesn’t belong to the extension authors, and the portion of the extension outside the sandbox won’t be told which requests were allowed. And, if too many requests are blocked apparently at random, the user may well notice.
It’s surely possible to sneak out some data, slowly, over a noisy channel, but it doesn’t sound straightforward.
Compare to actual manifest V3, where exfiltrating the keys to the kingdom appears to be entire trivial as long as the extension doesn’t try to block ads.
> One of these had to give, and Manifest V3 was the most elegant technical approach. Far from being the brainchild of a sociopathic executive, its architecture was devised by well-meaning engineers on the Chrome team.
The Chrome team has some very competent engineers. lcamtuf is a well-respected security engineer. I would expect such a group, trying to solve a problem of poorly behaved extensions, to develop a nice privacy-respecting API to block requests.
For example, there could be a way for an extension to run a portion of itself in a sandbox, such that the sandbox could inspect a request, decide whether to allow it, and output only an indication of whether to allow it. No further outgoing communication, including to the rest of the extension, would be allowed.
But instead we got Manifest V3, and I simply don't believe it's a meaningful privacy improvement. Read the docs: https://developer.chrome.com/docs/extensions/reference/api/w...
> Note: As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API is unchanged and available for normal use.
Did well-meaning engineers on the Chrome team really come up with a security improvement in which extensions can read request and response headers but not block the requests? I'd love to see an explanation, but to me it seems that the security "improvement" is pretty narrowly tailored to prevent ad-blocking without meaningfully improving privacy.