4 ms·

Devils advicate: I know hating on manifest V3 is popular. I know especially content-blockers (which I myself enjoy!) face issues with the new permissions model.

Devils advicate: I know hating on manifest V3 is popular. I know especially content-blockers (which I myself enjoy!) face issues with the new permissions model. That said, I've ported an above moderately complex extension from manifest V2 to V3 and found the experience quite OK. * The permission model is more clearly defined. * Background-workers instead of background-pages makes for a more consistent API. IMO background-pages were always weird. * Usage of obsolete APIs which may have "suddenly" failed in V2, now actually immediately causes runtime-failures in V3, making sure you've get all of them upgraded. * You need to be explicit when doing "dangerous" things like injecting scripts. There's nothing accidental about this. This clearly improves security. * Time taken? Roughly one work-day. * No functionality lost. Right now, as a developer, my only complain about V3 for this extension... That I no longer can have a single, consistent codebase for the Chrome and Firefox-versions, because Firefox doesn't yet support V3 in their regular end-user builds. But once they do, that problem will be solved too. And as an end-user, I really feel this security-model makes extensions which can operate within the V3-constraints more trustworthy than similar extensions implemented using V2.

raxxorraxor 4y ago
> You need to be explicit when doing "dangerous" things like injecting scripts. There's nothing accidental about this. This clearly improves security. What do you mean here? How do scripts get included explicitly?
danpalmer 4y ago
Thank you for adding some context to this that seems missing from all discussion I've seen so far. Extensions have always had a dodgy security model, and given the nearly unprecedented access they have to our data and habits, it's important that this is being improved. Most users aren't going to be able to tell the difference between a good extension and a malicious one, and even developers who would like to think they can probably can't in many cases. It sounds like security and performance are significantly improved, and these are both things that the tech community are usually big supporters of. But in this case it comes at the cost of some flexibility with ad-blocking, and if there's one thing we love more than security and performance, it's a chance to point the finger at big tech. There's a lot of nuance that has been lost from the ad-blocking discussion.
creesch 4y ago
I really think it depends on the complexity of the extension and how much it leverages the background page. > Background-workers instead of background-pages makes for a more consistent API. IMO background-pages were always weird. True, but they also did provide developers with a few benefits. For starters having a complete DOM available allows for a lot of handy dandy functionality to be done in the background. In the same sense it also meant having localstorage available in the backgroud. Which was actually very neat for caching purposes. Specifically if you care about privacy and people using your extension in incognito mode. With `"incognito": "split"` enabled it meant that cached data (so most likely the sort of data you don't want to leak between sessions) would remain seperated. This is no longer possible. You'd hope that the new session storage would work there, but no, for some reason that still ignores the fact that `"incognito": "split"` has been set and just leaks across sessions. Timers no longer being a thing also makes some operations slightly more complex, even more so because alarms do have some funky behavior. Ajax no longer being available sort of makes sense, but fetch isn't a drop in replacement as it does require a bit of boilerplate to make it work in a predictable manner. So it does require some effort there. > Time taken? Roughly one work-day. Eh, for relatively simple extensions I'd say that is accurate. But having done the conversion recently with an extension that does a bunch more and did rely on various background operations it took substantially more to get to there. It had a general positive impact on the code base in various areas but it was really more work than one workday, even more so when I include all planning and brainstorming. Given that many extensions are open source projects where maintainers have limited time and where for many extensions there really isn't a benefit I fully understand some of the hate towards being forced to do the conversion.
- josteink 4y ago
  All extensions are different. My extension (excluding NPM-dependencies) counts in at around 20k lines of TypeScript + various other resources. I think that counts as above average. Granted, the background-page/worker portion of it was not the dominant aspect, and thus had less rewrites required than if things had been the other way around. That said, migrating to V3 was way less effort than I thought it would be. I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Basically I'm just trying to provide some additional perspective here besides the usual content-blocker perspective which so far has gotten 100% of the narrative. Note I'm in no way dismissing that concern, but I think having the entire conversation framed around those extensions only does not correctly represent the huge variations found across the extension ecosystem.

raxxorraxor 4y ago

> You need to be explicit when doing "dangerous" things like injecting scripts. There's nothing accidental about this. This clearly improves security. What do you mean here? How do scripts get included explicitly?

danpalmer 4y ago

Thank you for adding some context to this that seems missing from all discussion I've seen so far. Extensions have always had a dodgy security model, and given the nearly unprecedented access they have to our data and habits, it's important that this is being improved. Most users aren't going to be able to tell the difference between a good extension and a malicious one, and even developers who would like to think they can probably can't in many cases. It sounds like security and performance are significantly improved, and these are both things that the tech community are usually big supporters of. But in this case it comes at the cost of some flexibility with ad-blocking, and if there's one thing we love more than security and performance, it's a chance to point the finger at big tech. There's a lot of nuance that has been lost from the ad-blocking discussion.

creesch 4y ago

I really think it depends on the complexity of the extension and how much it leverages the background page. > Background-workers instead of background-pages makes for a more consistent API. IMO background-pages were always weird. True, but they also did provide developers with a few benefits. For starters having a complete DOM available allows for a lot of handy dandy functionality to be done in the background. In the same sense it also meant having localstorage available in the backgroud. Which was actually very neat for caching purposes. Specifically if you care about privacy and people using your extension in incognito mode. With `"incognito": "split"` enabled it meant that cached data (so most likely the sort of data you don't want to leak between sessions) would remain seperated. This is no longer possible. You'd hope that the new session storage would work there, but no, for some reason that still ignores the fact that `"incognito": "split"` has been set and just leaks across sessions. Timers no longer being a thing also makes some operations slightly more complex, even more so because alarms do have some funky behavior. Ajax no longer being available sort of makes sense, but fetch isn't a drop in replacement as it does require a bit of boilerplate to make it work in a predictable manner. So it does require some effort there. > Time taken? Roughly one work-day. Eh, for relatively simple extensions I'd say that is accurate. But having done the conversion recently with an extension that does a bunch more and did rely on various background operations it took substantially more to get to there. It had a general positive impact on the code base in various areas but it was really more work than one workday, even more so when I include all planning and brainstorming. Given that many extensions are open source projects where maintainers have limited time and where for many extensions there really isn't a benefit I fully understand some of the hate towards being forced to do the conversion.

josteink 4y ago
All extensions are different. My extension (excluding NPM-dependencies) counts in at around 20k lines of TypeScript + various other resources. I think that counts as above average. Granted, the background-page/worker portion of it was not the dominant aspect, and thus had less rewrites required than if things had been the other way around. That said, migrating to V3 was way less effort than I thought it would be. I'm not saying it will be so for all extensions, but it was for mine, and it may be for others as well. Basically I'm just trying to provide some additional perspective here besides the usual content-blocker perspective which so far has gotten 100% of the narrative. Note I'm in no way dismissing that concern, but I think having the entire conversation framed around those extensions only does not correctly represent the huge variations found across the extension ecosystem.