Not sure whether this is the right place to report this, please let me know if there's a better place.
I just spent a little bit trying to figure out why today's google doodle wasn't showing up on mobile only. Disabling EasyPrivacy fixed it, but I couldn't find a rule in there that would block the image from loading. After some testing, I'm pretty sure it's because of this rule: ||google.com/log^$domain=~accounts.google.com which gets converted into this by the command line tool:
{
"trigger": {
"url-filter": "^[^:]+://+([^:/]+\\.)?google\\.com\\/log[/:&?]?",
"unless-domain": [
"*accounts.google.com"
]
},
"action": {
"type": "block"
}
},
The URL in question is https://www.google.com/logos/doodles/2025/googles-27th-birthday-6753651837110886.5-l.png
I believe this matches because of google.com/log(os...), and I verified that Safari on iOS blocks any URL that begins with google.com/log, including random nonsense like google.com/lognspvhevsu. This doesn't affect Safari on macOS, but it affects both Safari 18 and 26 on iOS, so it may well be a Safari bug in how it evaluates the URL. However, I still wanted to raise this issue in case there's some way to change how the converter creates the filter to work around this.
Not sure whether this is the right place to report this, please let me know if there's a better place.
I just spent a little bit trying to figure out why today's google doodle wasn't showing up on mobile only. Disabling EasyPrivacy fixed it, but I couldn't find a rule in there that would block the image from loading. After some testing, I'm pretty sure it's because of this rule:
||google.com/log^$domain=~accounts.google.comwhich gets converted into this by the command line tool:The URL in question is
https://www.google.com/logos/doodles/2025/googles-27th-birthday-6753651837110886.5-l.pngI believe this matches because of google.com/log(os...), and I verified that Safari on iOS blocks any URL that begins with
google.com/log, including random nonsense likegoogle.com/lognspvhevsu. This doesn't affect Safari on macOS, but it affects both Safari 18 and 26 on iOS, so it may well be a Safari bug in how it evaluates the URL. However, I still wanted to raise this issue in case there's some way to change how the converter creates the filter to work around this.