Safe Search on YouTube not working in Safari on iOS

WildByDesign commented 1 year ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARMv7

Installation

GitHub releases or script from README

Setup

On a router, DHCP is handled by AdGuard Home

AdGuard Home version

v0.107.40

Action

Specific Clients have had SafeSearch enabled and working for past 1-2 years successfully.

Recently, YouTube started showing the comment section on videos and it shows: Restricted Mode: Off

Expected result

Restricted Mode: On

No comment section visible.

Actual result

Restricted Mode: Off

Comment section is visible.

Additional information and/or screenshots

I have cleared the DNS Cache in AGH. I have cleared cache in browsers.

All affected devices are iOS devices running iOS 17.0.3 (iPads and iPhones).

Google SafeSearch is working 100%. This issue only affects YouTube Restricted Mode.

I tested on a Windows laptop and the issue is not affecting Windows devices at all.

Therefore, this issue only affects iOS devices and only affects YouTube Restricted Mode.

ainar-g commented 1 year ago

A few questions:

Do you actually see the queries from these devices in the query log? They should look something like this (with your client name, of course).
By “YouTube” do you mean the website, the app, or both?
How did you set up the devices to use AGH? Perhaps, the DNS settings on the device or in the browser have flipped to not use it?

WildByDesign commented 1 year ago

I will have to check and answer this a bit later. I did check this morning and they were not showing as Safe Search in Query Log. My assumption is that they were being served from cache and therefore not showing new entries for Safe Search. I have cleared DNS cache in AGH but I will have to check Query Log later today.
YouTube in Safari
All devices are setup to use AGH and therefore receive AGH IP address for DNS only. They don’t have any other DNS addresses configured. Just the AGH IP.

Another whacky thing happening is that if I go to the YouTube Check Content Restrictions page (https://www.youtube.com/check_content_restrictions) it shows that Content Restrictions are On:

DNS restrictions are on
Moderate restricted for youtube.googleapis.com, youtubei.googleapis.com, m.youtube.com

However, on YouTube main page (and page for any video) it states Restricted Mode: Off and all videos show comments and there is no filtering of offending videos.

ainar-g commented 1 year ago

I did check this morning and they were not showing as Safe Search in Query Log. My assumption is that they were being served from cache and therefore not showing new entries for Safe Search.

Queries answered from cache show up in the Query log as well, so if there are really no queries for YouTube's domains from these devices, they may not use AGH. Make sure that your Safari doesn't use a custom DoH server.

WildByDesign commented 1 year ago

Thank you, sir. I have followed your advice and did some research into blocking DoH at the network level. I have all DoH servers blocked now via domain name and via IP addresses.

The issue still persists (only iOS devices) and I can reproduce this 100% of the time.

iPhone or iPad:

Go to YouTube.com in Safari
Request Desktop Website
Content Restrictions: Off
Request Mobile Website
Content Restrictions: On

iPhone uses mobile website by default. iPad uses desktop website by default because of the bigger screen size.

Regardless of iPhone or iPad, it is this switching back and forth via Request Desktop Website / Request Mobile Website that is triggering the Content Protection on and off. Although for iPads, the protection is off initially since it uses desktop website.

Can you try that in an attempt to reproduce the issue?

Thank you.

ainar-g commented 1 year ago

We'll see if we can, but we really do need to see the queries in AdGuard Home's Query log. If they are not there then, as mentioned, it's a DNS configuration issue. If they are there but not filtered properly, it's an AGH issue.

WildByDesign commented 1 year ago

Sorry, I had forgotten to get back to you regarding the Query Log. I did test the query log entries yesterday and all five of the YouTube domains showed up under Safe Search in Query Log. They showed up for the iOS devices which do exhibit the problem and they also showed up for the Windows laptop which does not exhibit the problem.

Also, I am surprised at how many blockages I get from the Apple devices regarding blocking the Apple DoH servers. That has been eye-opening.

Summary: This problem only seems to affect iOS devices and it only seems to affect the Desktop Website version of YouTube on Safari. This especially affects iPads the most because they load the Desktop Website version of YouTube by default due to screen size. iPhones are only affected it the user specifically chooses Request Desktop Website. iPads are affected by default by viewing YouTube on Safari.

WildByDesign commented 1 year ago

I got an nslookup utility for my testing iPhone and ran some dns lookups for the five YouTube domains from the iPhone and also from my Windows laptop:

Time        Request                     Response        Client
07:21:39    www.youtube-nocookie.com    Safe Search     MSI-Win11 (192.168.1.xxx)
07:21:07    youtube.googleapis.com      Safe Search     MSI-Win11 (192.168.1.xxx)
07:20:46    youtubei.googleapis.com     Safe Search     MSI-Win11 (192.168.1.xxx)
07:20:27    m.youtube.com               Safe Search     MSI-Win11 (192.168.1.xxx)
07:19:58    www.youtube.com             Safe Search     MSI-Win11 (192.168.1.xxx)
07:19:18    www.youtube-nocookie.com    Safe Search     iPhone Xr (192.168.1.xxx)
07:18:46    youtube.googleapis.com      Safe Search     iPhone Xr (192.168.1.xxx)
07:18:19    youtubei.googleapis.com     Safe Search     iPhone Xr (192.168.1.xxx)
07:17:31    www.youtube.com             Safe Search     iPhone Xr (192.168.1.xxx)
07:16:31    m.youtube.com               Safe Search     iPhone Xr (192.168.1.xxx)

ainar-g commented 1 year ago

Thank you, these are very helpful. When you see “no DNS restriction”, are there queries in the Query log for these domains with types other than A and AAAA? For example, something like this (N.B. Type: HTTPS):

Screenshot from 2023-10-27 15-05-02

WildByDesign commented 1 year ago

You're welcome. The problem is that no subsequent queries show up in the Query Log. Whether its from the Windows laptop or the iOS devices, only the initial queries show up in the query log. I assume that both Windows and iOS (or Safari) are caching the lookup results.

They show up again in the Query Log if I turn the iOS devices off and back on again because I believe that is what clears the DNS cache on the iOS devices.

I think what I will have to do is clear the DNS cache in AGH, start with the devices off and then start fresh to see what details I can capture in the Query Log. I will try separately with the iPhone, iPad, and also the Windows laptop. I will do each device following the same steps in the same order so that I can compare queries between the 3 devices to see if we can spot some differences.

ainar-g commented 1 year ago

Just to be clear, you can just enter "m.youtube.com" into the search bar. Note the quotation marks; they force exact search. (Filtering by both question domain and client isn't currently supported, unfortunately, but is planned.)

WildByDesign commented 1 year ago

Thank you for that tip. AGH Query Log is incredible. Powerful yet simple to use.

I spent the past few days thoroughly studying DoH, DoT, etc. with regard to possible DNS bypasses. Here is what I have done:

blocked DoT via firewall rule to reject all outgoing requests on port 853 udp and tcp.
firewall rule to redirect any DNS queries on port 53 udp and tcp to AGH.
setup DoH domain blocklist in AGH with the follow list (https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-domains.txt) and getting lots of hits from iOS devices.
setup DoH IP address blocklist in OpenWrt in firewall with banIP with the following list (https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-ipv4.txt).
ipv6 is completely disabled/blocked on my network in OpenWrt and ipv6 DHCP is disabled in AGH.

Despite all of my research and all DNS bypass restrictions in place, the problem still persists.

iOS devices using YouTube website with Safari continue to be unprotected with the AGH YouTube SafeSearch. It is still reproducible when switching back and forth with Request Desktop Website and Request Mobile Website.

It is protected 100% of the time with Request Mobile Website. It seems to only affect desktop website on iOS devices and iPad affected by default since it uses desktop website.

ainar-g commented 1 year ago

Thanks for your words and for the thorough investigation. Unfortunately, neither our QA nor I personally could reproduce this behaviour, including with an iOS 17.0.3 device just now. A few additional points:

Do you use AdGuard Blocker or any other content proxy on the device?
Do you use any sort of VPN on it, including iCloud Private Relay?
Do you perform this check from a YouTube account or are you signed out?
setup DoH domain blocklist in AGH with the follow list (https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-domains.txt) and getting lots of hits from iOS devices.

I could have already mentioned that, but have you checked the Private DNS settings in Safari?

WildByDesign commented 1 year ago

There are no adblockers or content proxies on the iOS devices.
No VPN is installed. I don't have an iCloud+ subscription and therefore no iCloud Private Relay is enabled or available.
All of the iOS devices are using YouTube on Safari with no YT accounts logged in.
I have never been able to find Private DNS-specific settings in Safari on iOS. But certain things that have been suggested might affect Private DNS on iOS such as: Limit IP Address Tracking in Wifi settings, Hide IP Address in Safari settings and also Advanced Tracking and Fingerprinting Protection in Safari settings have all been disabled on all iOS devices.

As you can see, all iOS devices are quite bare bones and very close to factory default iOS settings, with the exception of the (above) privacy related settings being disabled.

I am starting to wonder if this might be a Region-specific issue. What I mean is, I wonder if this is something that is affecting users in Canada (like myself) and United States, but maybe not affecting users in Europe and other areas.

I also wonder if this has something to do with all of the changes that YouTube has been making to prevent adblockers. In my case, no adblocking is being done on the iOS devices and I don't have adblocking enabled in AGH either. I am just using AGH right now to serve DHCP and also specifically for enabling Safe Search on a per-client basis. AGH has such fantastic granular control.

ainar-g commented 1 year ago

I see, thanks again for the information. I don't think I have any more theories, though. Unless it's a bug either in Safari or in YouTube, it doesn't seem like something that should be happening. I'll add the help-wanted tag to see if anyone else has any ideas.

WildByDesign commented 11 months ago

I just noticed PR (https://github.com/annguyen0/AdGuardHome/commit/51f7f359a716a555e1e3426be0361dfaf78b101b) from issue (https://github.com/AdguardTeam/AdGuardHome/issues/6263) and how it might explain part of this issue.

Since these Clients were setup in the Client section with custom upstream DNS providers, I assume from this issue that no DNS cache was occurring.

Once this fix hits Stable channel builds, I will have to revisit this issue and attempt to reproduce it again to see if it had any effect on my issue or not.

WildByDesign commented 11 months ago

@ainar-g After several weeks of testing, I have finally figured it out.

The client devices had custom upstream DNS settings for OpenDNS Family Shield (208.67.222.123 and 208.67.220.123). The iOS devices (only) were forcing those DNS addresses to upgrade to encrypted DNS via doh.familyshield.opendns.com and familyshield.opendns.com.

The main question is, why didn't AdGuardHome block those domains?

I figured this out by replicating the setup in OpenWrt without AdGuard Home.

Comparison:

Setup 1:

OpenWrt AdGuardHome (including AGH as DHCP server) Clients with custom upstream DNS in AGH AGH configured with DoH blocklist (https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-domains.txt)

Setup 2:

OpenWrt Adblock (built-in OpenWrt adblocking via dnsmasq) Clients with custom upstream DNS in AGH Adblock configured with DoH blocklist (https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-domains.txt)

Results:

With both Setup 1 and Setup 2, I get many blockages for doh.dns.apple.com, mask-api.icloud.com, mask-h2.icloud.com, etc. All of the iOS Apple DoH and iCloud Private Relay related domains. The blockages are identical between both setups and are from that DoH blocklist.

However, only Setup 2 shows many blockages for doh.familyshield.opendns.com and familyshield.opendns.com which are also in that same DoH blocklist coming from the iOS devices only. Setup 1 with AdGuardHome is showing zero blockages for those domains. Yet, it is blocking the iOS Apple DoH and iCloud Private Relay related domains.

Clarity:

In both setups, the iOS devices are receiving the router address as DNS address. So just for clarity, the iOS devices do not have the OpenDNS Family Shield (208.67.222.123 and 208.67.220.123) DNS addresses directly on the client devices.

So it seems to me that there may be a bug in AdGuard Home's Client Custom Upstream DNS setup to where the blocklist cannot catch these DNS IPs converting/upgrading to encrypted DNS domains.

If I set those OpenDNS Family Shield DNS IPs as the main DNS servers in AGH, the blocklist does block the upgrade to encrypted. However, when I have these OpenDNS Family Shield DNS IPs setup in the Client section as custom upstream DNS, this is where it seems to bypass the blocklist.

EDIT: Also noteworthy, I have Block domains using filters and hosts files enabled in the Client section only. That setting is unchecked on the General settings. Hopefully this extra bit of information can help to track this down.

ainar-g commented 11 months ago

Thanks for the testing and the information. Do you see any _dns.resolver.arpa queries in AdGuard Home's logs? It is possible that those Apple devices use DDR to upgrade, and that AGH doesn't filter out these.

WildByDesign commented 11 months ago

You’re welcome. I will test this tonight.

Does this log entry require verbose logging?

EDIT: I re-read your response and I realize that you are referring to query log. I will test this tonight.

WildByDesign commented 11 months ago

Do you see any _dns.resolver.arpa queries in AdGuard Home's logs?

Unfortunately, there were none of those in the Query Log.

I also tried enabling Block domains using filters and hosts files in the General settings during this set of testing hoping that it might prevent the bug, but unfortunately I was still able to reproduce the YouTube protection issue. Sometimes it was protected, sometimes it wasn't.

The fact that it was occasionally reaching out over encrypted DNS explains why not all lookups were showing up in the query log before also. It was kind of 50/50, approx. It also explains why sometimes the DNS-level protections were working, and sometimes not.

I don't quite understand why OpenWrt with plain dnsmasq blocking with that same block list shows many blockages for doh.familyshield.opendns.com and familyshield.opendns.com, but AdGuard Home for some reason does not see it happening and therefore not blocking. For sake of clarity that was two different testing scenarios. I didn't have dnsmasq and AGH together at the same time.

EDIT: According to this (https://twitter.com/hquest/status/1720584038304342073) Apple started using DDR on all iOS devices since the release of iOS 17. That fits the timeline of when I started seeing this issue.

ainar-g commented 11 months ago

Just to be safe, can you block DDR and see if that improves the situation with the iOS device?

You can do that with a rule similar to:

/_dns\./$dnstype=SVCB,client='Your iOS Client Name'

The way to test if the rule works is by using e.g. dig:

dig IN SVCB '_dns.resolver.arpa' @YOUR_AGH_ADDR

Or, if you have an older dig that complains about SVCB:

dig IN TYPE64 '_dns.resolver.arpa' @YOUR_AGH_ADDR

WildByDesign commented 11 months ago

You can do that with a rule similar to:
/_dns\./$dnstype=SVCB,client='Your iOS Client Name'
This rule succeeded in blocking DDR because the dig command does cause a blockage to show in AGH for \'_dns.resolver.arpa\'. Unfortunately, however, it did not fix the problem with YouTube going in and out of protected mode.

That led me to my next idea in testing. I remembered from two years ago that Eugene had taught me another way to achieve SafeSearch per client (https://github.com/AdguardTeam/AdGuardHome/issues/1163#issuecomment-983527050). This method uses dnsrewrite to simply rewrite the domain name instead of the CNAME method that AGH currently uses.

So I tested the following:

# Google SafeSearch
||www.google.com^$dnsrewrite=forcesafesearch.google.com,client='AGH Client ID'
||www.google.ca^$dnsrewrite=forcesafesearch.google.com,client='AGH Client ID'
# Bing SafeSearch
||www.bing.com^$dnsrewrite=strict.bing.com,client='AGH Client ID'
# YouTube SafeSearch
||www.youtube.com^$dnsrewrite=restrictmoderate.youtube.com,client='AGH Client ID'
||m.youtube.com^$dnsrewrite=restrictmoderate.youtube.com,client='AGH Client ID'
||youtubei.googleapis.com^$dnsrewrite=restrictmoderate.youtube.com,client='AGH Client ID'
||youtube.googleapis.com^$dnsrewrite=restrictmoderate.youtube.com,client='AGH Client ID'
||www.youtube-nocookie.com^$dnsrewrite=restrictmoderate.youtube.com,client='AGH Client ID'

And this surprised me because this worked 100% of the time. No matter what, I was not able to get out of YouTube restrict moderate mode on the iOS devices at all. I tried the trick of requesting desktop site and back to requesting mobile site and so on. And I could not bypass it at all.

I believe that this narrows the issue down to being something to do with how the CNAME rewrite method is implemented and how YouTube responds to it on iOS devices. Now, to be honest, I have no idea why this issue does not affect Windows machines. It only seems to be an issue with iOS devices.

WildByDesign commented 11 months ago

Some more information from the YouTube Check Content Restrictions page (https://www.youtube.com/check_content_restrictions) showing the difference between the two methods:

Default AGH SafeSearch CNAME dnsrewrite method:

The screenshot (above) is consistent with what I always saw throughout weeks of testing. I just had never done a screenshot of it previously.

I believe that would explain why choosing Request Desktop Website would always remove the protections, and Request Mobile Website would put the protections back on.

My dnsrewrite working fix:

Protections stay on 100% with this method.

ainar-g commented 11 months ago

Thanks for testing that out as well! The difference seems to be that AGH doesn't add the CNAME record and instead just puts the resolved IP address directly into the A record.

@Mizzick, please make the behavior consistent with the usual dnsrewrite one.

WildByDesign commented 11 months ago

You can do that with a rule similar to:
/_dns\./$dnstype=SVCB,client='Your iOS Client Name'

How would I adapt this rule to cover all clients?

Would it simply be /_dns\./$dnstype=SVCB ?

Mizzick commented 11 months ago

The difference seems to be that AGH doesn't add the CNAME record and instead just puts the resolved IP address directly into the A record.

We have implemented the requested changes. Now the behavior is consistent with the usual dnsrewrite one. The new build version v0.108.0-a.793+dae304fc has been just published to the edge channel.

@WildByDesign please have a look?

WildByDesign commented 11 months ago

please have a look?

Absolutely. I will test this edge build later in the day today and have some feedback to share by tomorrow morning.

ainar-g commented 11 months ago

Would it simply be /_dns\./$dnstype=SVCB?

@WildByDesign, yes. You can test that by using the dig commands mentioned previously.

WildByDesign commented 11 months ago

I am running edge version v0.108.0-a.793+dae304fc and I am happy to report that I am now unable to bypass YouTube Restricted Mode on iOS. The YouTube Check Content Restrictions page reports that all 5 YouTube domains are protected now.

As always, your Team is fantastic. Thank you very much.

AdguardTeam / AdGuardHome