- cross-posted to:
- lealternative@feddit.it
- technology@lemmy.world
- cross-posted to:
- lealternative@feddit.it
- technology@lemmy.world
The “Manifest V3” rollout is back after letting tensions cool for a year.
You must log in or register to comment.
Google’s sales pitch for Manifest V3 is that, by limiting extensions, the browser can be lighter on resources, and Google can protect your privacy from extension developers.
Emphases mine. Funny, I use extensions to protect my privacy from Google.
Chromium needs to be fully divested from Google. End of story. There’s too much conflict of interest in letting the world’s largest advertising company have this much control over one of the two major browsers. If you don’t see the problem with that, imagine if Taco Bell was also the world’s largest producer of anti-diarrhea medicine.
The second being Safari, right?
Right?
…right…
As a web developer, Safari needs to either die in a fire or be transferred to a company that actually cares. It’s more than half a decade behind everybody else.
Tell me about it. Every time I implement some new thing in my app:
Firefox/Chrome: You cast HTML5 video. Critical hit!
Safari: Your spell fizzles…
It also took 6 years longer than everybody else to support WebGL2, and it’s the only browser without a working WebGPU implementation. It also has no timeline for wasm-gc, while Chrome already ships with it default enabled and Firefox will ship with it on the next release.
It also has no timeline for wasm-gc
Apple has been removing support for garbage collection from other technologies that used to support it. Wouldn’t be surprised if they never add support for that, they’ll tell you not to waste CPU cycles (and therefore, battery power) collecting garbage.
They want you to figure out when memory should be deallocated at compile time, not run time.
I personally prefer to use such languages, but I often don’t have a choice for certain tech stacks.
Mozilla is implementing Manifest V3. They plan to implement it slightly different than Chrome: https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/
They have published a guide for extension developers: https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
More background on Manifest V3:
https://www.eff.org/am/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security
https://www.eff.org/am/deeplinks/2021/11/manifest-v3-open-web-politics-sheeps-clothing
https://www.eff.org/am/deeplinks/2021/12/chrome-users-beware-manifest-v3-deceitful-and-threatening
https://www.eff.org/am/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation
Relevant part from the blog post:
What are we doing differently in Firefox? WebRequest
One of the most controversial changes of Chrome’s MV3 approach is the removal of blocking WebRequest, which provides a level of power and flexibility that is critical to enabling advanced privacy and content blocking features. Unfortunately, that power has also been used to harm users in a variety of ways. Chrome’s solution in MV3 was to define a more narrowly scoped API (declarativeNetRequest) as a replacement. However, this will limit the capabilities of certain types of privacy extensions without adequate replacement.
Mozilla will maintain support for blocking WebRequest in MV3. To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest. We will continue to work with content blockers and other key consumers of this API to identify current and future alternatives where appropriate. Content blocking is one of the most important use cases for extensions, and we are committed to ensuring that Firefox users have access to the best privacy tools available.
