Hacker News Reader

Comment by TedDoesntTalk | Hacker News Reader

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.

View on HN

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

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 and the Safari Web Extension command line parts are documented at 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.

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.

I think the confusion here is need to own vs need to use.

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.

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.

If you can't afford to cross-browser test, and you don't have a Mac, I'm not sure why you're building an extension for a Mac-only browser then? Someone has to test it on a Mac, register for a certificate with Apple, etc. In the end, buying a Mac is the easy part?

And there are services like https://www.browserstack.com/docs/automate/selenium/add-plug... where you can basically rent Mac VMs on cheap monthly plans. Or GitHub Actions, as I pointed to earlier, has a free tier with free minutes on an automated Mac terminal.

I can’t believe what I’m reading.

On one side Apple says they now offer a compatible API, on the other side you’re telling me dropping a minimum of $800 on a computer (+$100 annually) to release a free extension is the easy part.

BrowserStack would be a good solution to test it, but unfortunately you also need a lot of preparation and XCode-specific knowledge to even get to a testable point, which you don’t get unless you own a Mac.

The browsers that Apple claims to be compatible with don’t require anything more than WinZip.

Apple added requirements for their store to publish extensions, yes. They also added more privacy prompts. If you don’t test on MacOS in Safari, how would you know if your extension works correctly?

Why not ask Apple to release macOS for any computer like Windows on x86? Why not ask for Safari to be published for and API compatible with Windows as on macOS? Why not ask Apple to ship Windows since mac-only APIs would be problematic?

Fact is, Apple requiring a Mac to publish for a Mac-only browser is not a problem. It’s not even true. You can code sign for Mac from Linux[1], as I understand it. Worst case, a third-party service will step in to handle packaging and publishing the way we already do for cross-platform native apps and yet Apple will continue to expect devs to test on their Apple devices.

I can run Firefox or Chrome on my Mac so it’s not like I’m missing out if you choose to not develop an extension for Safari and test it in Safari. I feel like you’re arguing that testing isn’t required if you have the right web standards, which is pretty much always false when there are privacy or other implementation details that vary by browser…

1. https://github.com/zhlynn/zsign

2. Apple’s codesign tool is open source: https://opensource.apple.com/source/security_systemkeychain/...

But you need Safari to test the extension and Safari only has these extensions on a Mac? This is Apple’s way of avoiding their store getting cluttered with extensions that haven’t been tested to work on Safari. And yes, it also encourages developers to buy Macs. It can do both…

Have you ever looked at the Mac App Store? It is a literal dumpster fire.

Could you give me an example of this please? I'd love to see what you're referring to.

Here's one article about it: https://www.howtogeek.com/281849/dont-be-fooled-the-mac-app-.... It's still pretty bad.

Can you explain what you mean by “literal dumpster fire” because this doesn’t align with my own experience. I’ve used it for purchasing a number of apps recently and I saw nothing eyebrow-raising. So long as the app you want has been uploaded to the store, it works perfectly fine.

The App Store is OK for the apps you know are on it and you search for them directly. But the rest of the store is just junk and scams, mostly.

That’s true of pretty much any App Store that isn’t strictly invitation only. If you have an app follows Apple’s rules, it gets listed. Whereas Steam, by comparison, exercises editorial control over all of its content. The solution for a better Mac App Store would require Apple to be similarly dictatorial about content.

In that sense I agree with you; personally I think it was a mistake of Apple to have the Mac App Store so closely mirror the iOS App Store. They should have made it a more aggressively curated experience.

Ok… but the following topics in your list have nothing to do with an API specification, which is what they say their goals is on the Goals section:

“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. - UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials. - Huge huge difference between publishing on chrome vs on firefox - Safari requires xcode, and therefore macos to publish”

Bottom line is I don’t think there is going to be an api standard around “distribution and publishing areas”

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/Web...

> 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.

"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/ [2] https://wiki.mozilla.org/Add-ons/Terminology#Background

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.

How is that relevant to OP topic?

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

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.

Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.

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.

Reply on news.ycombinator.com