Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YouTube ads in Safari: you see them now, will you see them in the future?

adguard.com

Post reply on HN
Print view View original

101–110 of 282 posts

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#101

Post by lotsofpulp »

Flow wrote: post #20
yliu wrote: post #6

Despite the title being about YouTube, this is fundamentally about Safari's declarative Content Blocker API being totally inadequate in the face of modern ad delivery technologies. Yes, it's fast and relatively more secure compared to old ad blocking techniques (which requires granting full access to effectively arbitrary JS), but ad tech has evolved since 2015 and Safari's Content Blocking API has not evolved with i…

I use Wipr as a content blocker on both macOS and iOS. I never see ads on YouTube. But I've always felt that it might not be enough some day. Perhaps that day is nearly here.

I use Wipr and I just saw an ad today for the first time on YouTube in Safari. Usually, it throws up an error and you refresh and the video plays, but today’s it was error, then a skippable ad.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#102

Post by _Algernon_ »

qlm wrote: post #97
_Algernon_ wrote: post #92

Earlier quoted context omitted.

That would require delivering ads from first-party servers, right? So third-party ad and tracking networks would die a painful death.

Couldn't they just be proxied through a first party server?

That would be more effort than including a single html-script tag to import google analytics. I have hope that most parties would decide that the extra server load and difficulties would make it not worth it.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#103

Post by kenniskrag »

defaultname wrote: post #85
shawnz wrote: post #58

Earlier quoted context omitted.

This is basically the exact fear which was being expressed by users when Google announced that they would require Chrome extensions to only use declarative content blocking starting with Manifest v3 (which anecdotally convinced me to switch to Firefox).

If we go down that road, however, sites can make ads completely indistinguishable from desired content. Same domain, same stream, no easily marked container. All of the imperative adblocking tech in the world, short of queuing everything through a neural engine post render, can block what is possible. So there has always been a detente between adblockers and publishers, presuming the former hit a small enough set of…

I think by law, ads have to be declared as such for users.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#104

Post by ameshkov »

viktorcode wrote: post #77
ameshkov wrote: post #54

Earlier quoted context omitted.

As someone who contributed to the post we're discussing, let me please respond. > There’s SFSafariExtensionHandler API which you can use with blockers as another extension with higher privileges to track who blocked what. I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script…

> I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script that will get some information about what's blocked, but it's far from what's required. SFSafariExtensionHandler implements SFSafariExtensionHandling protocol, which has this function: optional func contentBlocker(withId…

> SFSafariExtensionHandler implements SFSafariExtensionHandling protocol, which has this function

First of all, shame on me for missing this, and thank you for pointing this out.

Unfortunately, this still does not solve the issue in question - we cannot figure out which rule was triggered. But it is definitely better than nothing, at least knowing what's blocked we can try creating something resembling a debugging tool.

> Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.

Some of them can be handled this way, some of them cannot. Trying to handle all possible issues automatically right on the device is not at all as trivial as simply converting EasyList. And we need to do it that way (real-time, on device) because our goal is not to just convert a few lists, but also to provide maintainers with a tool they can use to develop their lists and test&fix them for Safari.

> Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.

Content blockers that can run JS code can guarantee privacy better by doing their work better than the others.

Anyways, let's not go further on this, we won't change each others view on this and we've already stated our positions.

My point was that we want to extend the declarative API, it has nothing to do with running JS.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#106

Post by ameshkov »

StavrosK wrote: post #79
ameshkov wrote: post #66

Earlier quoted context omitted.

Well, I have the same exact experience and frankly, it is not what I intend to repeat again. At least developers can do that. But most of the people who maintain filter lists are not developers and cannot afford enjoying compiling WebKit for the sake of finding what exact rule has blocked this or hidden that.

Honest question: Why not just drop support for Safari? If Apple wants to make it hard to write content blockers, they can do without content blockers, and the users can see ads and eventually switch to a browser that doesn't show them ads.

I do honestly believe they want to make content blockers good. Maybe the problem is that we don't communicate our pains good enough, maybe it's that they don't hear us sometimes, but I think that we have the common goal and this post will help them understand us better.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#107

Post by StavrosK »

ameshkov wrote: post #106
StavrosK wrote: post #79

Earlier quoted context omitted.

Honest question: Why not just drop support for Safari? If Apple wants to make it hard to write content blockers, they can do without content blockers, and the users can see ads and eventually switch to a browser that doesn't show them ads.

I do honestly believe they want to make content blockers good. Maybe the problem is that we don't communicate our pains good enough, maybe it's that they don't hear us sometimes, but I think that we have the common goal and this post will help them understand us better.

I see, thank you. Hopefully it's just about not enough extension writer feedback, fingers crossed it'll get addressed!

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#108

Post by whywhywhywhy »

Removing whatever Ublock Origin needed to exist in Safari is one of the dumbest moves Apple has made.

To get most of the battery advantages of Macs you're forced to use Safari. But when it comes down to having to see YouTube ads I'm willing to make the tradeoff and switch to Chrome.

Re: YouTube ads in Safari: you see them now, will you see them in the future?

#110

Post by topicseed »

mullingitover wrote: post #98
topicseed wrote: post #67

Earlier quoted context omitted.

You're mentioning the end user's learned expectation to get videos for free. But what about the creator's expectation to get paid for their hard-earned views, to then pay for the gear purchased and the production of the entire video, including team members? If you're really anti ads, don't take the content for free, find another piece of content that answers your ad-free philosophy.

> If you're really anti ads, don't take the content for free, find another piece of content that answers your ad-free philosophy. Google is in the process of breaking this deal themselves - they're now adding ads to videos which users did not opt to monetize, and they're keeping 100% of the revenue. Taking the content for free, if you will.

They, at least, offer a free hosting service. Not ideal to monetize on the back of the creator's work, but it's not comparable with friendly piracy rationalised through semantics behind what User Agent means (as per parent comment).
Post reply on HN