5 ms·

What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already c

What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already complete.

sneak 5y ago
Malicious extensions, as well as the ability to block the browser vendor’s ads still pose a problem to these groups to be solved.
- techdragon 5y ago
  Except Apple who don’t have the incentive of browser advertising and are currently selling privacy as one benefit of choosing their hardware (and by extension their software and browser [safari]) Mozilla make money from Google deals and so have outside incentives to not rock the boat too hard on this detail.
  - contriban 5y ago
    Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.
shash7 5y ago
There's still a lot to do, mainly around distribution and publishing areas: - webextensions specific storage apis to return promises but chrome still needs callbacks - A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser. - csp policies differs between chrome and firefox(and cors too I think) - UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials. - Difference between how permissions are interpreted on different browsers - Huge huge difference between publishing on chrome vs on firefox - Safari requires xcode, and therefore macos to publish
- lstamour 5y ago
  That last restriction (Safari requiring Xcode) isn’t always a limitation, though. Most CI platforms support Mac for publishing apps to that platform. For instance, GitHub: https://link.medium.com/63hjdbRBQgb https://link.medium.com/63hjdbRBQgb and the Safari Web Extension command line parts are documented at https://developer.apple.com/documentation/safariservices/safari_web_extensions/converting_a_web_extension_for_safari https://developer.apple.com/documentation/safariservices/saf... Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.
  - contriban 5y ago
    I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions. It is a limitation and it’s completely unnecessary for the end user. If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.
    - brutal_chaos_ 5y ago
      I think the confusion here is need to own vs need to use.
      - jfrunyon 5y ago
        You need to own it in order to use it, and you need to use it in order to publish an extension for Safari. No confusion.
        tehbeard 5y ago
        And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.
SilasX 5y ago
At the end of the day, though, you can't remap keys in a fully general way in Firefox[1], so the experience has regressed. [1] Extensions can change it, but they don't take effect until the tab for current page has loaded, which often defeats the purpose.
- TedDoesntTalk 5y ago
  How is that relevant to OP topic?
jchook 5y ago
Afaik Chrome does not support the standard, yet Firefox supports Chome’s API. As a result, most extensions seem to use the Chrome API. Firefox also provides a polyfill to adapt the Chrome API to the WebExtensions standard. More info here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- TedDoesntTalk 5y ago
  > Afaik Chrome does not support the standard Chrome published the WebExtensions API, not Mozilla. Whether or not it’s a standard is another question, you could call it a defacto standard, but Chrome definitely implemented the api that they published.
  - syshum 5y ago
    "WebExtensions" is a nebulous term and I can find no where that Chrome calls their API WebExtensions, it is simply the "ChromeAPI" Mozilla as even stopped using the term WebExtensions, instead just going with Extensions [2] The "spec" that most people refer to as WebExtensions, is BrowserExtensions orginally published by Microsoft via W3C [1] [1] https://browserext.github.io/browserext/ https://browserext.github.io/browserext/ [2] https://wiki.mozilla.org/Add-ons/Terminology#Background https://wiki.mozilla.org/Add-ons/Terminology#Background
rasz 5y ago
As always its about control. Its a fight against general computing. The goal is deprecation of "remote code" execution, where "remote" means remote to Vendor, but local to user, aka anything not shipped and signed by the extension store.

What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already complete.

sneak 5y ago

Malicious extensions, as well as the ability to block the browser vendor’s ads still pose a problem to these groups to be solved.

techdragon 5y ago
Except Apple who don’t have the incentive of browser advertising and are currently selling privacy as one benefit of choosing their hardware (and by extension their software and browser [safari]) Mozilla make money from Google deals and so have outside incentives to not rock the boat too hard on this detail.
- contriban 5y ago
  Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.

shash7 5y ago

There's still a lot to do, mainly around distribution and publishing areas: - webextensions specific storage apis to return promises but chrome still needs callbacks - A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser. - csp policies differs between chrome and firefox(and cors too I think) - UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials. - Difference between how permissions are interpreted on different browsers - Huge huge difference between publishing on chrome vs on firefox - Safari requires xcode, and therefore macos to publish

lstamour 5y ago
That last restriction (Safari requiring Xcode) isn’t always a limitation, though. Most CI platforms support Mac for publishing apps to that platform. For instance, GitHub: https://link.medium.com/63hjdbRBQgb https://link.medium.com/63hjdbRBQgb and the Safari Web Extension command line parts are documented at https://developer.apple.com/documentation/safariservices/safari_web_extensions/converting_a_web_extension_for_safari https://developer.apple.com/documentation/safariservices/saf... Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.
- contriban 5y ago
  I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions. It is a limitation and it’s completely unnecessary for the end user. If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.
  - brutal_chaos_ 5y ago
    I think the confusion here is need to own vs need to use.
    - jfrunyon 5y ago
      You need to own it in order to use it, and you need to use it in order to publish an extension for Safari. No confusion.
      - tehbeard 5y ago
        And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.

SilasX 5y ago

At the end of the day, though, you can't remap keys in a fully general way in Firefox[1], so the experience has regressed. [1] Extensions can change it, but they don't take effect until the tab for current page has loaded, which often defeats the purpose.

TedDoesntTalk 5y ago
How is that relevant to OP topic?

jchook 5y ago

Afaik Chrome does not support the standard, yet Firefox supports Chome’s API. As a result, most extensions seem to use the Chrome API. Firefox also provides a polyfill to adapt the Chrome API to the WebExtensions standard. More info here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

TedDoesntTalk 5y ago
> Afaik Chrome does not support the standard Chrome published the WebExtensions API, not Mozilla. Whether or not it’s a standard is another question, you could call it a defacto standard, but Chrome definitely implemented the api that they published.
- syshum 5y ago
  "WebExtensions" is a nebulous term and I can find no where that Chrome calls their API WebExtensions, it is simply the "ChromeAPI" Mozilla as even stopped using the term WebExtensions, instead just going with Extensions [2] The "spec" that most people refer to as WebExtensions, is BrowserExtensions orginally published by Microsoft via W3C [1] [1] https://browserext.github.io/browserext/ https://browserext.github.io/browserext/ [2] https://wiki.mozilla.org/Add-ons/Terminology#Background https://wiki.mozilla.org/Add-ons/Terminology#Background

rasz 5y ago

As always its about control. Its a fight against general computing. The goal is deprecation of "remote code" execution, where "remote" means remote to Vendor, but local to user, aka anything not shipped and signed by the extension store.