No blocking requests.
"Unlimited" storage (which is necessary for most non-trivial extensions) is actually limited to 10MB.
You're stuck in Apple's app store which is equally as draconian as Chrome's and Firefox's but now you have to pay $99/year.
No IndexedDB.
The extensions aren't usable on mobile.
I care little for Safari's users if I have to deal with all of this.
> You're stuck in Apple's app store which is equally as draconian as Chrome's and Firefox's but now you have to pay $99/year.
Safari extensions do have to be notarized (so $99/year), but notarized extensions don't have to be distributed via the Mac App Store.
> No IndexedDB.
Safari appears to support IndexedDB, with native support for IndexedDB 2.0 in Safari 10.1+. https://caniuse.com/#feat=indexeddb
> The extensions aren't usable on mobile.
Safari for iOS does support extensions, so I'd assume they'll use the same framework. https://www.idropnews.com/apps/11-best-safari-extensions-iph...
I didn't know this. Thanks.
>Safari appears to support IndexedDB
This is also news to me and makes me pretty happy.
>Safari for iOS does support extensions
This really makes me wonder how they handle the UI. I'll check it out.
Safari for iOS and iPadOS has native Safari App Extensions but not the new web tech based Safari Web Extensions (yet).
"All the demos revolved around Safari web extensions available on the Mac, though the talk makes a point of not targeting user agent strings (information a browser reports about its own version and what system it’s running on), but rather asking about features that might be present. Given that other types of Safari extensions are available on iOS/iPadOS (namely content blockers), might web extensions eventually make their way to Apple’s mobile platforms as well? One can hope."[1]
[1] https://sixcolors.com/post/2020/06/wwdc-2020-tuesday-session...
Having a shared API matters for extensions primarily because it makes it easier for a developer to say, "well, I might as well throw that on the Apple store as well." But if Safari literally can't do the things your extension needs it to do, then the API is kind of a secondary concern.
But if somebody asks me what the current state of adblocking is and how they can get it, I'm not going to pretend that Safari offers it.
The immediate problem is that Safari has a hard limit of 50,000 rules per extension. Some developers do try to get around this with various hacky strategies like splitting their adblocker up into multiple extensions, or moving their blocker to the OS-level, or trying to recompile the list on the fly. But at the end of the day it's just a really weird hoop to jump through, and it ends up being kind of error-prone, and there's no guarantee that Apple won't break those hacks in the future.
More fundamental is the list itself -- Safari doesn't allow contextual, dynamic blocking, you have to put everything into a static list. This makes it impossible to build the kind of detailed filters[0][1] that uBlock Origin allows -- for example, there's no way to strip HTML content from a GET request in Safari before it gets parsed by the browser.
And so on. See the privacy API[2], dns[3], which is used to block a newer bypass method where 3rd-party trackers are hidden behind 1st-party subdomains. Worse CSS/JS injection, etc...
I'm not saying everyone else is crap at adblockers, I'm saying static blocklists are fundamentally less powerful and less capable than Firefox's APIs. That's especially true if AdGuard is doing something like system-wide DNS blocking. No shade at those tools, they have a place, but a browser-based extension will always be better than a setup like PiHole, because the browser has more access to a given request's current context.
[0]: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax
[1]: https://github.com/gorhill/uBlock/wiki/Dynamic-filtering
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[3]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
I'm quite curious what legitimate use this has?
Of course, note that uBlock Origin also supports scriptlets[1] that can be used to rein in scripts after they get added to the page, instead of by doing resource rewriting. You're not restricted to only doing your filtering at the network level, HTML filtering is just another tool that filter authors have at their disposal.
Helpfully, at the scriptlet wiki page I've linked each entry also shows a practical example rule that relies on the scriptlet. You can also take a look at the uBlock Origin's default filter lists[2] if you want more examples of people using both HTML filtering and scriptlets in the wild. Many of these block rules are impossible to implement in Safari.
[0]: https://github.com/gorhill/uBlock/wiki/Inline-script-tag-fil...
[1]: https://github.com/gorhill/uBlock/wiki/Resources-Library
Sharing notion (dumb question) here, since you're smart about this stuff:
At what point will "ad blocking" flip to "content scrapping"? All this cat & mouse, arms race seems like a bad ROI.
I imagine an adaptive super reader view mode. Meaning emphasis on content scrapping rules vs ad blocking rules.
Take snapshots of top websites, do some rendered page aware content diffing, with some user directed setting & curation, infer where the content is, distill that down to "good enough" scrapping rules.
Any way. Thanks for answering some of my lingering questions.
If you want to swap from a blacklist model to a whitelist model, there are a couple of problems to solve off the top of my head:
- you need a way to refer to content that supports re-hosting. You need a way to convert the Facebook/Twitter link someone shares into the scraped version without you loading the original link. See IPFS, but also see Invidious, Nitter, and the Internet Archive for a lower-tech, more straightforward version of what that might look like.
- you need good enough copyright exemptions that it's OK to re-host or proxy the content somewhere else. This is kind of a gray area, people are rehosting web content without getting sued, but it's not clear to me if that's scalable moving from sites like Youtube to the Internet as a whole. I guess nobody's called to take down Pocket, so maybe the situation there is better than I think.
- You need the web to stay relatively semantic. There are a lot of sites that don't work with Pocket/reader mode. A lot of the sites that do work are because there isn't a highly adversarial relationship between Pocket and site operators.
I'm not sure whether a cat-and-mouse game around content scraping would be better or worse than what we have. I can imagine it would be better in the sense that you'd only need to do it once per page, and then distribute the scraped version. But that's assuming that copyright would allow you to do that.
And I suspect that breaking a scraper is easier than breaking an ad blocker. But maybe someone could prove me wrong there.
re "whitelist" vs "blacklist"
Nice phrasing. Stealing it.
re rehosting, copyright exemptions
I hadn't connected those dots. Thanks. Very interesting.
Tangentially, I've been chewing on an idea similar to quotebacks (recently on HN's front page). My naive take was to create URL shortener to support my use cases. For example, by shortener would attempt to link to OC, falling back to Internet Archive (or whatever). I'll now learn about IPFS, Invidious, Nitter.
Also, I didn't do a good job explaining my 1/2 baked notion for implementing a "whitelist" based content scrapper.
I imagined distributing the whitelist to be used by client's browsers to do the actual transformation locally. Your explanation of how uBlock can also rewrite HTML DOM client side sparked this line of thinking. For the whitelist's curators, my notion for capturing and diffing was providing tools, like a better debugger, which could also be used by front-end developers.
Back to your notion of server side processing, for some combo of caching, transformation, render: I love it.
Opera did something similar with their mini mobile browser, ages ago. The server would render pages to GIF (?) with an image map for interaction, pushed out to the mobile device. Squint a bit and that architecture resembles MS Remote Desktop, PC-Anywhere, X-Windows, etc.
I keep hoping someone trains some advertising hating AI, that will scrap content for me.
re cat-and-mouse
No doubt.
I have written a few scrapers in anger. On mostly structured data. Often mitigating compounding ambiguity from standards, specifications, tool stacks, and partner's implementations.
So I just tossed the traditional ETL stuff (mappings, schema compilers), treated the problem space as scrapping. Generally speaking, I used combos of "best match" and resilient xpath-like expressions (eg prefer relative to absolute paths) to find data.
Worked pretty good. Super easy to troubleshoot.
No additional software required at all.
"Please note that content blocking in Safari operates even when the app is not running"
considering that the free extension is built to block ads in Safari, it seems to be doing this just fine without the app running.
In the end I just use a browser with built in blocking (AdBlockBrowser or now Brave) and leave Safari alone.
I'm sure it's a great extension with a lot of work put into it, but there is no realistic way 1blocker can match the best ad blockers in Chrome/Firefox unless it's hacking Safari behind the scenes to inject new APIs.
Oh wait.
I wonder if half the reason the 50k rule limit exists is so developers don't end up with an append-only infinite rule list that takes 20 seconds to recompile. If you're stuck turning 200k rules into four lists of 50k rules, you can just recompile each one on its own thread and all of it will take a couple seconds max.
to maintain an apple developer account you also need a mac or iDevice with secure enclave, so even if these were actually compatible with webextensions, you couldn't publish your webextension for safari unless you were an apple user.
* draw them into fuller platforms for using it. (or)
* pressure safari to support more of the standard.
Stepping stones.
Probably will happen in Firefox too, since Google controls W3C: http://browserext.github.io/
Have you got _anything_ to back this up? I’m willing to bet the majority of Mac users use Safari (given it’s the default browser). I use it and it’s a lot less clunky than Chrome and Firefox. I also repeatedly run into an attitude of “if my users don’t user Chrome then I don’t care about their experience” and find it very off putting.
> Looking at my web stats, over the last 30 days, 69 percent of Mac users visiting DF used Safari, but a sizable 28 percent used Chrome. (Firefox came in at 3 percent, and everything else was under 1 percent.)
[0] https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m... - second to last paragraph
I only know of a few Mac users of Chrome.
USA desktop browsers, May 2020:
- Chrome: 58.97%
- Safari: 15.65%
- Firefox: 8.24%
Doesn't have much in common with your anecdote except that it's in the reverse order of popularity that you seemed to claim.
On iOS, even if they allow different browser apps they have not apparently relaxed the restriction on the embedded browser engine and that means Firefox or Chrome are different UIs on top of a browser engine which is still Safari.