How to convert existing web extensions for Safari | Hacker News Reader

How to convert existing web extensions for Safari

developer.apple.com

81 pointsBigBalli84 comments

Interesting, I had not heard about this (looks like it was announced at the most recent WWDC), but the Vimium devs already have![1]

Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.

Given all the hype around Safari’s performance on new M1 Macs (and the fact that only Safari supports Apple Pay), I’d love to have parity on these two extensions extensions. It seeems like Web Extensions will not provide enough to fully support uBlock Origin, but maybe their Content Blockers will be a close enough approximation.

At the very least, I hope that Safari will gain a larger userbase from these changes, regardless what I choose to use. Having multiple large, evenly distributed userbases will only make web developers think more about Chrome-first or Chrome-only development.

[1] https://github.com/philc/vimium/issues/3610

Same. I can't use Safari without Ublock Origin. The web is a horrible place without it.

[1] https://github.com/el1t/uBlock-Safari/issues/158

I’ve been using safari + Wipr and I haven’t noticed any big difference.

I will actually second this. Wipr is really good.

Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,

1. It is more private since the extension does not have access to your webpage. 2. It is faster because Safari can do it natively and it is not done in JavaScript.

Too true. I have Safari with 1Blocker / Wipr, through a PiHole that uses NextDNS for DNS resolution. All other browsers feel like wading through treacle. Whenever I'm forced to use Chrome on someone else's device I'm gobsmacked at how anyone could put up with something so slow and clunky.

for what it's worth I've got a Pi-Hole running on my local network instead of in-browser adblock, and it's pretty good, and before that i had some success with 1Blocker, which IIRC uses the same lists as uBlock Origin.

YMMV (probably depends on the subset of the web that one visits) but I've had good luck with Wipr under Safari. Once in a while something slips through but it's generally ~99% as effective as uBO when it comes to visible ads. The difference is small enough that I'm not inclined to use a different browser.

> Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.

+1, especially uBO

Does anyone know the latest on uBO coming to Safari (or not)?

I’ve been pretty happy with 1blocker for Safari. It’s not as flexible as Ublock, but it seems to do a good enough job.

I was under the impression that certain functions required by uBlock Origin still weren't available even though Apple embraced WebExtensions. I may be wrong.

You are correct. Safari does not support webRequest blocking and will almost certainly never support it. Indeed, Google Chrome has already announced its deprecation of this API.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Did Apple give a reason? Privacy?

I could see a privacy case in not letting any and every extension have access to all requests.

> a privacy case in not letting any and every extension have access to all requests.

People keep making that argument, and I keep having to correct this.

Their webRequest is not blocking but it does support _observing_ all network requests[1], just as is planned with ManifestV3.

The privacy argument can't and shouldn't be used to justify the removal of the blocking capability from the webRequest API.

---

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

It should be noted that there's a significant difference between Safari and Chrome in this respect, however. Safari content blockers are not actually JavaScript at all, they're nothing more than JSON rules, so content blockers have no webRequest API usage whatsoever. Whereas Chrome extensions are JavaScript, with webRequest capabilities.

Safari Mac does have JavaScript extensions too (iOS only supports content blockers), and everything gorhill says does apply to them. And indeed some vendors ship both a content blocker and a Safari JavaScript extension in the same Mac app (though each one has to be enabled separately in Safari). Thus, it could be argued that this is a distinction without a difference. But from a technical perspective they're entirely different technologies.

The macOS 10.15 SDK did add an API for a Safari JS extension to receive information from a content blocker embedded in the same Mac app, allowing for example the extension to show stats for blocked resources: https://developer.apple.com/documentation/safariservices/sfs...

My personal theory is that Safari content blockers were designed primarily for iOS, which has no Safari web extensions, and the Mac side was a bit of an afterthought.

Thanks for this. I'll stop propagating that.

What reason does Apple give for not allowing blocking, then?

My guess would be maintenance cost.

I think the privacy argument is that extensions cannot steal cookies. The current model grants extensions permission to steal cookie values right?

I am unfamiliar, so please feel free to correct me. Thanks for uBO!

You can observe `Cookie` header with a webRequest.onHeadersReceived listener.

Documentation about what can be observed or not is all available online, there is no need to make any assumption:

Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Chromium: https://developer.chrome.com/docs/extensions/reference/webRe...

That should answer all questions regarding what can be observed.

Thanks for the links. I should read up on that. So the privacy argument is false.

The difference is that I can choose to enable a content blocker that has no JavaScript component and know that it can’t observe what I browse.

I can also choose to enable an extension that does have JavaScript and know that it could observe what I browse.

That's almost certainly what it is, in addition to performance. Apple supports ad-blockers, but they work by providing a list of rules to Safari, which uses the rules to filter resource loading (rather than allowing the ad-blocker to intercept individual requests).

It’s probably not.

https://github.com/el1t/uBlock-Safari/issues/158

I was really excited to try this after the WWDC announcement. Apple was not joking about how easy the conversion is [1]. It took me 15 minutes and 1 command to port my extension [2], and I didn't even need to install Big Sur!

But when the Safari 14 GM release came around, I couldn't justify spending $100 per year just to get my extension on Safari. My goal is to test my product ideas. Chrome gives me plenty of installs to do that, and Safari's user base is too small on the desktop. Adding Safari also means that I have to manage another release system, deal with all of Apple's app store approval quirks, and support customers on a new platform. The added $100 / year just adds to the trouble.

I still think Safari supporting WebExtensions is a big win for the web platform. When I do scale and when Apple sorts out the new platform quirks, I think I will pay the $100 per year and all the added time and technical costs.

[1] https://twitter.com/rayshan/status/1292270249362956288

[2] https://finance.shan.io/stock-inspector-discover-new-compani...

I similarly have an iPhone app I built and have been enjoyably using on my iPhone for years and slowly iterating on. I'd happy give it away for free and pay the associated increase in web service costs just so others can enjoy it. But the thought of paying $100/year (and having to deal with App Store review) is a bit much for a hobby app...

I'm surprised Apple put this barrier up since it certainly would have scared me away from iOS development as a poorer/newer developer. I guess Apple's happy with amateurs building but doesn't want to deal with their apps in the store. Maybe a compromise would be letting people self-distribute free apps without paying the $100?

Google's webstore for extensions charges a one-time fee of $5 to mitigate the abuse problem. I think it's a reasonable compromise. Apple's $100 per year is also keeping my hobby extensions off Safari as well.

I was more than happy to pay $5, but I don't think it helps with abuse at Chrome's scale. The abuse got so bad that Google is forcing Manifest v3 [1] on developers to seriously limit what extensions can do. Beyond the abuse, most of the extensions in all the stores, Chrome, Firefox, Edge and especially Opera, are not designed and maintained well.

[1] https://developer.chrome.com/docs/extensions/mv3/intro/

Is the abuse because $5 is too little or because the initial permissions and policies too lax?

Not sure what you mean about poor design or maintenance. The lower barrier to entry means there are many more options and often unmaintained extensions get forked. (If their license is permissive, which is more often the case when the creator doesn't have to pay $100 per year.)

Nothing stops you putting the code on GH and let people self deploy it.

However I’d also wondered if there’s a scenario where several independent devs might band together and use a single organisational dev account to ship their own apps. Obviously trust (between devs who are otherwise strangers to each other) is an issue here but I’m sure you’re not the only one in that scenario.

I'm into the shared account / shared cost idea for small side projects. But the reality is that managing an app store account for a popular app can be its own full time job. I spent weeks tinkering with account settings, exchanging dozens of app store support emails, and managing the release process. A lot of unexpected things. A lot went wrong. And it's not just Apple. The Chrome Web Store has plenty of quirks too. I trust my fellow devs but I don't trust myself to not screw up a shared account.

Agree with the $100/year just to be able to do what other browsers allow for free (AFAIK). Used to be that Apple offered free extension hosting, even with a free certificate.

Forcing developers to pay is the most developer- and user-hostile thing they could do, and is the main reason I don’t use Safari anymore (there just isn’t any worthwhile extensions for it).

IMHO, it is the reason to use Safari. The $100 and the registration process is a high barrier that helps keep out junk extensions. Even better, in some cases I can pay the creators of the extensions I rely on which makes the ecosystem more sustainable.

I’m sure as a percentage of extensions you’re probably right, but who installs extensions by browsing the entire catalog of extensions?

What I’d bet most people (including myself) do is search for extensions (assuming you don’t already know the exact one you want). My experience has almost always been that the extension I want isn’t available for safari (just chrome and Firefox), or is a shitty/old version of the chrome one.

So even if the $100 keeps some more junk out than on chrome, I still don’t get to use the extensions I want and the ones that are available aren’t great (albeit better than junk).

I'd be happy to pay a $100 1-time fee, but Apple's $100 is recurring.

> free (AFAIK)

Google requires developers to pay them $5, once, before they can upload extensions to the web store.

So, basically free. I mean most coffees cost more.

They’re just covering the fees to prove you’re a person/developer, and basically nothing more.

FWIW your homepage looks super distorted on my iPhone (11 Pro). I realize this is a web browser extension for desktop, but if folks get linked to it on social media or something, there’s a good chance they’ll be on mobile.

Would you please share what you see? This is what I see: https://imgur.com/a/xv6LQkQ

Thank you!

The top part also looks fine for me. It's the screenshots below the fold that are distorted: https://imgur.com/a/eNOtGu0

Thank you! Fixed!

Safari have been messing extension developers around for ages now. It's been hugely frustrating. When you dig into the data, most of Safari traffic is from iOS so most devs just can't be bothered to port to Safari. The $99 is just another kick in the face. You might think it's quick and easy to convert, but Safari has all sort of annoying inconsistencies that make it a huge amount of work. For any small software company it's just not worth the effort. Safari should incentivize people not disincentivize them.

Yes, it's also really buggy. One of the API calls return bad data (after the mac wakes from sleep). Side loaded extensions get corrupted on some macOS/Safari updates requiring the user to fully reinstall apps.

They make reporting bugs impossible because you can't just reproduce it by updating your OS again. Native app messaging is done through shared data which forces you to poll for updates.

Urggh. I wish they could just own up to the mess (like Microsoft did) and fully move to Web Extensions, including native app messaging.

I'm going through converting a Chrome extension to Safari 14, and the process isn't nearly as seamless as shown, although it's nice to have the converter tool.

Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill

Here's some incompatibilities between Chrome and Firefox to consider: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Also had some html/css glitches to fix in Safari. Some other issues others have mentioned such as notifications and webRequest APIs.

> Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'.

According to the documentation, "Safari web extensions support both the chrome.* and browser.* namespaces." https://developer.apple.com/documentation/safariservices/saf...

Ah, well that may have well been a recent update. I'll have to try it again under chrome.* It didn't used to work at all unless I replaced chrome.* with browser.

It's nice that it uses a standard API now. But it seems to me that the long tail of one-person-developed hobby extensions will still be completely turned off by the prospect of paying $99/yr indefinitely to be able to distribute the extension (App Store membership).

Yeah, this baffles me. I can't figure out why this still exists. I've got to imagine the volume of people paying that fee specifically to develop Safari extensions has to be low.
Thing is Safari is a nice browser to use, but without uBlock Origin it's a non-starter for me, all these 'content blocker' solutions are either bloated or nowhere near as good as uBlock Origin.

The irony of calling content blockers, which provide prebuilt block lists to the browser, to compile into an efficient format, “bloated” while suggesting that JavaScript extensions running before every single resource request to check if it should be blocked are not, is beyond ridiculous.

the fee exists, at least from what I have gleaned historically, to provide some mild barrier to people who would otherwise spam the App Store with crap. By building a modest amount of hoops, it keeps the laziest spammers out. (Also something about "paying to keep the lights on", as if AAPL needs money these days)
In practice, well, just search this site for threads about it. I'm not sure, like you indicate, it's worthwhile for the browser ecosystem.

Google Webstore has a one time fee of $5. Surely there is a more reasonable middle ground.

Not to mention the $700+ upfront hardware investment if you don't already have an Apple machine.

Most extensions could likely be built and tested just fine on a ~$250-$350 used Mac mini. That's probably still more money than should need to be spent, but a brand new machine probably isn't necessary in this particular case.

I was thinking on that. You still need peripherals if you're using a Mac Mini, though that's no different than if you were using another desktop. Still though, if you don't use, or don't want to use a Mac as your daily driver, that's a dedicated machine just to build/publish an extension for a browser. IMO, there's a slightly stronger case for iOS apps, but requiring that for a browser extension is much harder to justify.

It's not like you can use safari on Windows.

However, if you're the creator of a Firefox/Chrome extension, and want to utilize the WebExtension support in Safari, your deployment workflow can no longer be platform agnostic.

I've done this to build for MacOS, and it still becomes like a tax as the hardware ages out and Apple insists you have the latest OS to publish to their stores.

Requiring app-based distribution feels like a perversion of the entire premise of WebExtensions. I understand why Apple wants to reuse its existing development, review, and distribution platforms, and it makes sense for some apps, but it's simply not reasonable to expect cross-platform browser extension developers to go through the hassle of building and distributing Mac apps just to support Safari users.
If you have an existing Mac app, it might be worth it, but personally, there's no chance that I would bother porting my own standalone WebExtensions to Safari under the current system, whereas I went to the trouble of doing so ($99/year fee and all) for the legacy framework, even though I don't really use Safari. Maybe Apple is OK losing large numbers of smaller extensions, but for me, it just means I'd never seriously consider Safari as an alternative to Firefox or Chrome.

I hate pooping where I eat since I’m trying to finally move to Safari, but all the writers saying how easy it is to port an extension now still have no idea.
Here’s what I need to port Chrome extension to Firefox:
1. Upload a zip file 2. Fill in very few additional details 3. Wait for review
Here’s what it takes for Safari:
1. Own a Mac 2. Download 12GB of XCode 3. Run the conversion tool (this is the point that everyone talks about) 4. Well done, now you have an XCode project you’ll have to maintain 5. Pay $99/yearly 6. Fill pages of senseless details and read scary-sounding notices about encryption because your extension is enabled on HTTPS 7. Wait for review 8. Get denied because of an “entitlement” that the conversion tool added for you 9. Wait for review 10. Fix a number of slight incompatibilities you’ll find over time, from basic features that other browsers have had for a long time to the APIs actually not being standard.

I've used this to convert a small Google Meet push-to-talk extension: https://github.com/BashVideo/google-meet-push-to-talk/pull/2...
That one's really simple, but doing the Firefox port first seems to have ironed out most of the compatibility issues. Mostly APIs with newer versions where Chrome is the only one to support the old API.
But just exploring web extensions a bit (this was my first time interacting it), it feels like supported features differ quite a bit between browsers. Chrome has the lead here, and Safari seems 'minimal' in comparison. UI elements can also behave very differently between browsers.
Apple is dead-set on having you use the App Store to distribute even web extensions. The converter works fine, but just this way of doing things does bring along a bunch of frustration for unfamiliar devs. There was a Twitter thread on this recently started by a member of the Safari team, which gives an idea: https://twitter.com/jensimmons/status/1338558758025367553

I maintain a small extension focused around Competitive Programming niche. I often get requests from users asking if there's a safari version available. As much as I would love to add support, I'm not paying 99$/year as I don't make any money from the product.
My extension for those interested: https://github.com/nishanthvijayan/CoderCalendar-Extensions/

Speaking of web extensions, one thing I’ve been missing from iOS is a convenient way to turn JavaScript on or off on a page-by-page basis.
uBlock Origin makes this trivial—it’s literally a click on the extension logo and then one more tap.
iOS Safari already has “Turn off Content Blockers” and “Website Settings” per website, but I haven’t been able to find a menu or app that makes it convenient to toggle JavaScript on a page.
I use a 4 year old iPhone with a dying battery and aging processor. The web is slow and made much faster without JavaScript. It’d be great to have a toggle for this.

I’m building this. Will be done soon.

The webRequest API is not supported in Safari, so extensions like uBlock Origin cannot be ported in their current form. It's unfortunate that Apple is not embracing the webRequest API, since it's so much more than a tool for content blocking. Requests are a core feature of any browser, and not allowing extensions to control and edit requests hinders innovation among browser extensions.
The notifications API is also missing in Safari, so extensions must use the native messaging API to show notifications from the native app extension.

I am not a browser developer, but the impression I get is that the issue with the webRequest API is that the amount of overhead that can be added to a function that's invoked extremely frequently (loading resources) is unbounded and difficult to optimize. It entrusts a pillar of browser performance to extension developers, which is a dicey proposition.
This leads me to think that if Apple were to add support for something like the webRequest API, it'd likely be via the native half of the extension API and potentially even Swift-only so there can be stronger guarantees on things like execution time. This may also allow users of the API to better take advantage of multithreading for more complex operations.
I may be misunderstanding something about how the webRequest API is traditionally implemented that deals with these concerns however, in which case feel free to correct me.

I tweeted recently about a research paper which found that the performance argument does not hold, see https://twitter.com/gorhill/status/1345743193179095040

Chrome will also drop that soon and only allow a tiny fraction of extensions to continue using it.
This is in the name of security. Whether you believe that is up to you, but personally I don’t even install extensions that require access to all of my tabs, let alone something that can read pure requests (with the exception of uBlock)

This motivated me to finally port Wappalyzer to Safari. It was fairly straight-forward but Safari doesn't implement every API that Chrome, Firefox and even Edge support, so I had to do a bunch of work to get a single version of the extension to work consistently in all four browsers. I'm glad it's finally here though.
https://apps.apple.com/app/wappalyzer/id1520333300

I just tried converting our Chrome Extension and the process on the surface seemed pretty seamless. It doesn't seem like Safari supports web Bluetooth yet though, so aside from displaying my icon and accessing my config page, I can't really do much else.

Curious that Ublock Origin still hasn't done this. Is there a reason why?

https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_u...

I hope RECAP[1] comes to Safari.
1. https://free.law/recap/

Sidenote but does anybody know how feasible it is to install mac on a virtual machine and develop extensions for safari?

IIRC this is possible but violates their EULAs for MacOS and likely the DMCA. So if you plan on using it commerically then you may be risking the entire business.

Now who’s gonna convert and submit uBlock origin to the App Store for safari?
The only extension I truly need before I use safari again.

Actually certain functionalities necessary for uBlock origin are still blocked, so the port is not possible as of yet: https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_u...

> not possible as of yet
Never. The Safari team already (wrongly) feels that their Safari-specific "content blocker" API is adequate, and moreover, Google Chrome has announced the deprecation of the webRequest blocking API used by uBlock Origin, so it almost certainly won't be ported to Safari, and it's an open question how long uBlock Origin will even last on Chrome in the future.

It’s funny that you call it inadequate while a bunch of developers make very useful products based around it.

Why is that funny? The point is that they're less effective at blocking than uBlock Origin, not that they're useless.

To claim something is not adequate is to claim it can’t do the job.
Ad/tracker blockers based on Apples content blocker framework absolutely do work.
So when I said funny, I meant funny as in, “this meat smells funny”.

This is unhelpful quibbling over the semantics of one word. You know what I meant. Everyone knows what I meant. I even explained in more detail what I meant. You're also wrong about the word, but I'm not going to bother arguing that here.
Please refrain from writing "this meat smells funny" comments on HN. You could go around commenting on typos too, which happen all the time, but that's not at all helpful.

Definition of adequate 1 : sufficient for a specific need or requirement adequate time an amount of money adequate to supply their needs also : good enough : of a quality that is good or acceptable a machine that does an adequate job : of a quality that is acceptable but not better than acceptable Her first performance was merely adequate.

uBlock Origin is GPL licensed software. GPL isn't compatible with the App Store Terms of Service: https://www.fsf.org/news/2010-05-app-store-compliance

I'm glad to see that certain extensions are what's stopping people from switching to Safari.
For me the issue is that Safari garbles the sound when using Google Hangouts and Whereby. Having to open another browser just to use those services, is pretty annoying.

This title, doesn't that say it all?

To clarify my comment:
I wanted to point out that it is Apple sharing how to modify your extensions to work with Safari, as opposed to Apple sharing how they modified Safari to work with WebExtensions.

Reply on news.ycombinator.com