> if Chrome detects that the page load ads or ads-related resources.

Let me guess, “ads-related resources” are not defined, but in a court case in 5-10 years time it’ll be accidentally revealed that internally Google considers this to include “JavaScript, css, or HTML files”...

It's a good idea to read the article:

> During the current FLoC origin trial, a page will also be included in the calculation if Chrome detects that the page load ads or ads-related resources. (Ad Tagging in Chromium explains how Chrome's ad detection mechanism works.)

Ad tagging? https://chromium.googlesource.com/chromium/src/+/master/docs...

> Ad Tagging works by matching resource requests against a filter list (...) to determine if they’re ad requests. Any requests matching the filter are tagged as ads. Further, requests (and some DOM elements such as iframes) made on behalf of previously tagged scripts are also tagged as ads by the AdTracker. An iframe will be marked as an ad iframe if its url matches the filter list, if tagged script is involved in the creation of the iframe, or if its parent frame is an ad iframe. The main frame of a page will never be tagged as an ad. Any request made within an ad iframe is considered an ad resource request.

I can't find what is included in this filter list, I'm not sure it's open source.

(mandatory disclaimer: I work at Google, not on Chrome nor ads)

> Ad Tagging works by matching resource requests against a filter list (...) to determine if they’re ad requests.

This list should be shared with UBlock Origin. Let the people decide what they want IMO.

I'm pretty sure this is the list: https://github.com/chromium/chromium-ads-detection/blob/mast...

It's derived from easylist, and (I think) scoped down based on things that actually show up in the top X websites.

The court case will reveal that google used the string "ad" to search within html documents, thy completely missed that <head> will contain the ad substring...

Excluding a page is a manual process however, requiring to set the header mentioned in the blog post. So website owners have to explicitly opt-out of FLoC.

Web server software maintainers should enable the header by default. Bugs should be filed against those with the wrong default.

Web server software should absolutely not add a bunch of garbage to work around some ad company's shenanigans.

Pretty much all network code has workarounds or default configurations that work around problems with specific clients.

I guess this topic is more of a political issue rather than an obvious compatiblity issue, so it's not as clear cut.

But adding special code to deal with buggy clients is something everyone has to do sooner or later.

They shouldn't have to, but there are several examples of where it's the software author who has take action in order to put a stop to it.

Not an Apple fanboy, but Safari is a great example of software which has changed its default behavior to prevent creepy things from happening.

Safari is also a great example of a browser to keep the app store relevant ( outside of games)

Different companies, different incentives

If Google is going to shift to using almost unblockable tracking calculations, then servers are the next most logical place to push back against it.

Anyone who runs a site and wants to opt in against a default block should have to take extra action to reduce their visitors privacy, and should be called out for their behavior. As others have noted, there are already plenty of workarounds in use for many reasons... this is a BETTER reason than most.

Yeah, but that is only necessary if the page contains ads or ads-related resources, right? That’s how I interpret the previous quote.

Yeah and the system will never accidentally see something not advert related as advert related and turn the option on. Things like that never happen.

And when that does happen, Google is famously transparent in its actions and easy to contact to resolve such issues.

(You may detect a little touch of sarcasm above!)

If you detected it yourself, you should rewrite it to make your writing less confusing.

What’s an “ads-related resource”???

Is it way to cynical to think that coming from the worlds largest advertising company that can’t mean anything except “monetizable web content”...

Dirty of google to hide behind “web.dev” and not make it front and center clear this is a google property.

They own the entire .dev gTLD namespace - they aren't hiding it, but it's probably not common knowledge.

I am not defending Google behavior, I have no dog in this fight, just sharing. In fact, there was a weird behavior I detected inadvertently last year 2 employers ago where I couldn't load any .dev public internet sites due to preloaded rules that hadn't been updated since before the .dev gTLD was publicly available. Some would load, and others (web.dev in particular) wouldn't load. Anyways yeah this sucks, it seems that any new advancements in web related technologies that could enable new privacy measures are just side stepped by the dark wizards out of Mountain View...

They might operate it but anyone can register a .dev domain. So being on that TLD doesn't make it obvious that it's Google.

I kept thinking that web.dev is the same as webplatform.org, which was positioned as a community-driven replacement for Mozilla's MDN Web Docs and heavily pushed by Google at the time.

Turns out webplatform.org was discontinued some time in 2015 and put up a notice pointing people at the MDN Web Docs. Then in 2017 Mozilla announced most of the key players (including Google) would now support the MDN Web Docs[0], which still seems to be true except they fired the entire MDN team in 2020[1]. It seems the advisory meetings are still happening and someone is maintaining MDN, but with Mozilla essentially only existing because Google continues to pay the bills, its future seems a lot less certain now.

Meanwhile web.dev makes no mention of MDN and instead mixes discussion of Google's proprietary "experimental" features and Chrome-specific behavior with general advice on "building better websites", duplicating some of the content already covered by the MDN Web Docs' guides section (except this gives them opportunities to cross-market their own interests while also not discussing support of features in other browsers).

I don't think Google is hiding who's behind as the footer literally has the Google Developers logo in it. They are however not acknowledging anything other than Chrome even exists and heavily blurring the lines between Chrome or Google-specific features and stable web standards. Coupled with certain public Google developers continuously chanting "use the platform" while criticizing people for using other web frameworks instead of custom elements, this certainly creates an impression of deception and dishonesty.

[0]: https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

[1]: https://www.fastcompany.com/90539632/mozilla-vows-mdn-isnt-g...

Seems to mention Google more than on Youtube. Both use Google accounts, as seen in top right corner, but only web.dev has a footer mentioning Google.

Youtube is very old and has its own reputation and a made-up trademark name. It's not trying to hijack the entire concept of a generic idea like "web dev" that existed before Google existed.