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

71–80 of 282 posts

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

#71

Post by Dah00n »

ascagnel_ wrote: post #56
tambeb wrote: post #24

It's because of things like this—not to mention the added overhead/middleman—that I think ad blocking at the DNS level is the best way to go. With both Android and iOS supporting encrypted DNS system-wide, blocking at the DNS level is more convenient than ever (mobile & wifi are covered, no need to set DNS for each wifi network, etc.). I realize of course, though, that DNS level blocking is mostly a non-starter with…

I run a Pi-Hole on my local network, and I still see YouTube ads -- they're served from the same CDN as the videos. The way in which YT delivers ads (pre-, mid-, and post-roll videos on the same CDN/domain as the content) seems, on the surface, to thwart any type of static ad detection.

This is more of a rant on Pi-hole than related to Youtube ads but...

Pi-hole can be fine but it isn't effective if you want it to block not only the lowest hanging fruits which a browser adblocker could easily block too but also stuff that doesn't follow the rules and might use hardcoded DNS IPs if they can't get the reply they want from the DNS server. With some Windows PC's, Apple devices, Chromecasts and Androids I quickly saw Pi-hole hang because of tens of thousands of requests if I tried to force all DNS through it. Because I'm a geek I turned to my homelab instead of the RPI4 and ended up with two nginx load balancers with two Pi-holes behind each (yes, 4 Pi-holes). Even though they were now running in virtual machines on a dual Xeon HP Proliant they still died when they got flooded. The hardware could easily take the hammering of requests but the software not so much (often the counter skyrocketed to 40000 requests before it died). Now I just block 100% of DNS requests at the gateway/firewall (OPNsense) instead and oh boy does it catch and log a lot of stuff the Pi-hole didn't. The amount of software that use hardcoded DNS, make example.com requests and try to reach RFC TEST-NET IPs is just staggering.

Sorry about the rant but just in case you didn't know that Pi-hole is only effective against good network citizens like, well, now you know.

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

#72

Post by ska »

sofixa wrote: post #60
ska wrote: post #57

Earlier quoted context omitted.

While this is all true, it doesn't obviously counter the GP's contention. It's a good argument as to why YouTube's cut isn't the same as Patreon's, but that doesn't mean that 45% isn't to high.

Considering Youtube probably doesn't break even ( Alphabet don't list YouTube expenses separately, only revenues, which is suspicious), and the vast majority of content on YouTube is thoroughly unmarketable and unprofitable ( think vacation videos, school lessons, etc.), maybe, maybe not?

I agree it's not clear.

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

#73

Post by Dah00n »

paxys wrote: post #51
heavyset_go wrote: post #23

Earlier quoted context omitted.

There's a difference between product placement and intrusive ads that interrupt content for minutes at a time. YouTube Premium customers paid to get rid of the latter.

YouTube Premium customers paid to get rid of ads placed by YouTube. A simple solution for channels that embed ads in their videos themselves (or have any other kind of content that you don't like for any reason) is to simply unsubscribe.

Yes but that is like not visiting a site after you found out it uses tracking or like peeing in your pants for warmth. It only work if you never see videos you haven't already subscribed to beforehand.

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

#74

Post by cpeterso »

twobitshifter wrote: post #2

The battle between ad platforms and users is going to be never ending. For YouTube, the _right_ thing to do is to pay for the premium option which removes ads. Otherwise as difficult as it is to say, you are getting something for nothing and people do make a living from YouTube videos. Ok, maybe you can contribute to a patreon outside of YouTube, but you’re not going to do that for everyone and those videos are not s…

I watch YouTube on my TV and the ads are annoying enough that I actually looked into subscribing to YouTube Premium to make the ads go away (and better support the content creators I follow). But I'm not ready to pay YouTube $12/month just to make ads go away. I would probably pay $5/month. Netflix's basic plan only costs $9/month.

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

#76

Post by Dah00n »

falcolas wrote: post #13
heavyset_go wrote: post #9

Earlier quoted context omitted.

> For YouTube, the _right_ thing to do is to pay for the premium option which removes ads. Even if you pay for premium, you'll still get sponsored ads in the content.

That's on the creator, and no ad blocker will stop sponsored content.

SponsorBlock will. It does require someone to flag the ads first though but so does most ads on adblocker lists.

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

#77

Post by viktorcode »

ameshkov wrote: post #54
viktorcode wrote: post #44

There's some misconceptions being put forth in the article which I, as a developer of a Safari ad blocker, would like to address. Content blockers are limited by design to ensure privacy and speed, but they may work together with other kinds of Safari extension. So, when AdGuard guys say that the only debugging tool you can use is Console, know that this isn’t true. There’s SFSafariExtensionHandler API which you can…

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(withIdentifier contentBlockerIdentifier: String, blockedResourcesWith urls: [URL], on page: SFSafariPage)

So, this is used in statistics extension that prevents me ever looking into the console. Helps to shorten the time it takes to add a new rule and see if it works.

> Let's take the simple example - unblocking something. For instance, here is the most obvious example that happens all the time. There may be a regional list that unblocks something blocked by EasyList (or EasyPrivacy) because this "something" breaks an important website in that region. Putting EasyList into one content blocker and the regional list into another breaks the regional list.

I totally agree! This is one of the reasons I don't use those lists as is. Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.

> We accept that argument despite me being literally sick of hearing it (so there's privacy on iOS, but no privacy on macOS since scripts are allowed to extensions there, okaay).

The statement that there's no privacy on macOS is incorrect. The user can see what privileges different extensions require, and can enable only those they are okay with, like content blockers. Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.

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

#79

Post by StavrosK »

ameshkov wrote: post #66
saagarjha wrote: post #63

Earlier quoted context omitted.

You may be amused to know that I debug my content blockers by keeping around a debug build if WebKit with a handful of breakpoints at the right spots to trace them. The experience really does suck…

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.
Post reply on HN