[HN Gopher] How to convert existing web extensions for Safari
___________________________________________________________________
How to convert existing web extensions for Safari
Author : BigBalli
Score : 52 points
Date : 2021-01-05 19:03 UTC (3 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| dstillman wrote:
| 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.
| kosinus wrote:
| 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
| frou_dh wrote:
| 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).
| caffeinewriter wrote:
| Not to mention the $700+ upfront hardware investment if you
| don't already have an Apple machine.
| kitsunesoba wrote:
| 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.
| caffeinewriter wrote:
| 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.
| krbzsq wrote:
| 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.
| neurobashing wrote:
| 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.
| stephenr wrote:
| 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.
| system16 wrote:
| 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.
| chrisdbanks wrote:
| 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.
| fbelzile wrote:
| 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.
| forgotmypw17 wrote:
| This title, doesn't that say it all?
| dessant wrote:
| 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.
| kitsunesoba wrote:
| 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.
| jez wrote:
| 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.
| vimy wrote:
| I'm building this. Will be done soon.
| dotemacs wrote:
| 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.
| jez wrote:
| 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
| Merman_Mike wrote:
| > 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)?
| krbzsq wrote:
| 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.
| lapcatsoftware wrote:
| 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...
| Merman_Mike wrote:
| Did Apple give a reason? Privacy?
|
| I could see a privacy case in not letting any and every
| extension have access to all requests.
| machello13 wrote:
| 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).
| gorhill wrote:
| > 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...
| Merman_Mike wrote:
| Thanks for this. I'll stop propagating that.
|
| What reason does Apple give for not allowing blocking,
| then?
| runjake wrote:
| It's probably not.
|
| https://github.com/el1t/uBlock-Safari/issues/158
| fiddlerwoaroof wrote:
| 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.
| jumpman500 wrote:
| 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
| lotsofpulp wrote:
| I've been using safari + Wipr and I haven't noticed any big
| difference.
| neurobashing wrote:
| 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.
| kitsunesoba wrote:
| 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.
| adamhearn wrote:
| 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.
| gardaani wrote:
| 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
| [deleted]
| fdalvi wrote:
| 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...
| lapcatsoftware wrote:
| > 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.
| stephenr wrote:
| It's funny that you call it inadequate while a bunch of
| developers make very useful products based around it.
| lapcatsoftware wrote:
| Why is that funny? The point is that they're less
| effective at blocking than uBlock Origin, not that
| they're useless.
| akasian_1973 wrote:
| Curious that Ublock Origin still hasn't done this. Is there a
| reason why?
| ffpip wrote:
| https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_u...
___________________________________________________________________
(page generated 2021-01-05 23:01 UTC)