Would this also affect chrome extensions? For example, when an extension makes a request to a 3rd-party domain, browsers by default pass all the cookies associated with that domain to the server. AFAIU, these cookies are considered to be 3rd-party.
Shameless plug: I've built the unofficial "Hide My Email" browser extension [0], available both in Firefox [1] and Chromium [2]. Tried to make it as frictionless as the Safari UX, which proved to be a challenge given the lack of native HME APIs.
It's funny that geohot/tinygrad chooses to not meet the PEP8 standards [0] just to stay on brand (<1000 lines). Black [1] or any other python autoformatter would probably 2x the lines of code.
V3 not allowing remote code execution is actually a serious benefit. Of course, this does not negate the fact that V3 is mainly there to boost the ad ecosystem of Google, but I'd never want my screen casting extension to be mining bitcoin on the background. That said, I'm not sure how this is going to scale long term, given that it sometimes takes 2+ weeks for the web store review team to approve a genuine one-line change. Lack of RCE is only going to make this review backlog bigger.
>V3 not allowing remote code execution is actually a serious benefit.
This is Google Kool-Aid. When Google says "remote code", they mean _remote to google_. Your own script on your own drive is remote to google. Google is removing User from the User Agent.
Well, in this instance remote code actually means remote. In V3 one can no longer use the tabs.executeScript API [1] in which you could pass an arbitrary server rendered string.
V3 kills Userscripts (tampermonkey/violentmonkey). You will no longer be able to execute your own code written with your own hands&brain and stored on your own hard drive.
Disallowing remote code by default could be considered a benefit, but disallowing me from saying "I trust this one particular source of remote code; please let it execute" is most definitely not.
> With Manifest V2, it was possible to inject a "Referrer" HTTP header if necessary. With Manifest V3, it's no longer possible.
Not entirely sure of how this is true. A recent V3 extension I've built is able to inject both the "Referer" and "Origin" headers using a declarative net request ruleset:
