Remove features gated behind enrollment in Chrome

[queengooborg]

This PR reverts the additions of BCD for the Fenced Frames, Attribution Reporting and Shared Storage APIs, reverting #20294, #20375 and #20460.

These were added in because support was detected on my local version of Chrome. However, the mdn-bcd-collector disagrees that there is support, because apparently, all versions of Chrome on BrowserStack have no support for either API.

[queengooborg]

Since these are standard features, the collector will automatically add them back in when support is detected!

[chrisdavidmills]

Since these are standard features, the collector will automatically add them back in when support is detected!

Perfect ;-)

[chrisdavidmills]

OK, I finally have an answer for you as to why support is not showing for these APIs, and why tests seemed like they were not working.

Domains that call the privacy sandbox APIs have to undergo the process of enrollment/attestation — see https://github.com/privacysandbox/attestation. Otherwise, the calls will fail with attestation errors.

I need to add information about this to my documentation.

[Elchi3]

Thanks Chris, I assume that these APIs should stay in BCD then.

[queengooborg]

Something's still not right here. If a website has to undergo an enrollment process, why did the same website under the same domain work just fine on my local devices (in any Chrome profile), but fail on BrowserStack?

[chrisdavidmills]

Something's still not right here. If a website has to undergo an enrollment process, why did the same website under the same domain work just fine on my local devices (in any Chrome profile), but fail on BrowserStack?

It depends on a few things:

• Were the examples you were running the same in both cases?
• How long ago did this testing occur?
• Were they localhost examples, or examples actually up on a server?
• Was the testing done on Canary, release, or did it behave the same in any/either?

I ask because some changes in the enrollment did occur recently. All of Chrome's own demos broke because of this, and they are currently in the process of reenrolling them all.

Also, for local testing you can get around the enrollment by enabling the chrome flag chrome://flags/#privacy-sandbox-enrollment-overrides. I wonder if this might have changed in terms of its default setting, and/or if its default setting is different between Canary and release?

[queengooborg]

Were the examples you were running the same in both cases?

Yes, it was the same code. I used the collector's test code in both cases.

How long ago did this testing occur?

I tested this a month ago, see https://github.com/mdn/browser-compat-data/pull/20460#issuecomment-1773690495.

Were they localhost examples, or examples actually up on a server?

No localhost involved; I used the public version of the collector.

Was the testing done on Canary, release, or did it behave the same in any/either?

I always use stable releases; I don't have Canary installed.

[chrisdavidmills]

Update: I've done some more testing on this (I was waiting for the Chrome team to update the enrollment on all their demos as it was causing widespread breakage). I've tested both of the following sets of demos on Chrome release:

• https://shared-storage-demo.web.app/
• https://arapi-publisher.web.app/ (Attribution reporting)

Both now work fine.

[queengooborg]

Both of these demos require a flag to be turned on:

And I can confirm on BrowserStack that the flag is required.

I still don't know why on my local machine, the same test on the same domain passes when I do not have any flags enabled (or any other configuration that should affect this), but it does not pass on BrowserStack without enabling the flag. My local device has chrome://flags/#privacy-sandbox-enrollment-overrides left blank.

[chrisdavidmills]

Both of these demos require a flag to be turned on:

Sorry, to be clear, I believe that information is out of date. I've got the flag disabled in Chrome release, and the demos work for me.

[queengooborg]

But on Chrome versions available on BrowserStack, the flag is required, so there's something odd going on here.

[chrisdavidmills]

But on Chrome versions available on BrowserStack, the flag is required, so there's something odd going on here.

Well, I really don't know what the answer is here.

[rowan-m]

Heya, Privacy Sandbox team here - my gut feeling is that this does feel like some enforcement of enrollment for that set of APIs. Is there somewhere I can poke around to see how the collector runs and what it tests against?

[queengooborg]

Hey @rowan-m! The collector's tests for these API features are super straightforward, and some can be seen here:

https://mdn-bcd-collector.gooborg.com/tests/api/HTMLAnchorElement/attributionSrc https://mdn-bcd-collector.gooborg.com/tests/api/SharedStorage

[queengooborg]

By the way @chrisdavidmills, I just tried to play around with both demos you linked, and neither of them work for me, with the flags disabled:

I am using Chrome 119.0.6045.159 on macOS (arm64).

[chrisdavidmills]

By the way @chrisdavidmills, I just tried to play around with both demos you linked, and neither of them work for me, with the flags disabled:

@queengooborg I just tried both again, with the flags disabled, on Chrome release 119.0.6045.199. They work for me fine.

[queengooborg]

Are you sure the flags are off, and that there isn't some other configuration you have on your end that's enabling the features? On my laptop, desktop and BrowserStack, I cannot confirm support for any of the features without enabling a flag.

[chrisdavidmills]

Are you sure the flags are off, and that there isn't some other configuration you have on your end that's enabling the features? On my laptop, desktop and BrowserStack, I cannot confirm support for any of the features without enabling a flag.

I checked the flags were off again. I also tried shutting Chrome down completely and restarting it from cold, just in case I had started it previously with some kind of command line switch that was enabling it. They still work for me. I have also checked to make sure I am using Chrome release and not Canary ;-)

I've asked the privacy sandbox team to write up a summary of exactly what release versions the PS APIs are enabled in, if they are ramped up to 100% of users, if they need flags, enrollment, any other weird stuff to get them working OK. I'd suggest we wait for that before spinning our wheels any further on this.

Until then, it's maybe worth asking @rowan-m — can you think of any other settings, prefs, or flags, which might be causing my release version of Chrome to run these demos successfully without the "Privacy Sandbox Ads APIs" flag turned on, whereas @queengooborg is not able to run them successfully without the flag enabled?

[github-actions[bot]]

This pull request has merge conflicts that must be resolved before it can be merged.

[queengooborg]

I've marked this PR as a draft as we are currently discussing how to handle APIs gated behind enrollment.

[github-actions[bot]]

This pull request has merge conflicts that must be resolved before it can be merged.

[queengooborg]

@100love1retodo471 Please do not use this repository as a sandbox for learning GitHub. If you are interested in contributing, please see the document about contributing first.

[github-actions[bot]]

This pull request has merge conflicts that must be resolved before it can be merged.

[Elchi3]

Let's close this. I did send a few PRs in the meantime to correct some of this data. I don't think removing these features is a good way forward. We will have to see how to deal with enrolled features. The discussion can continue in https://github.com/openwebdocs/mdn-bcd-collector/issues/986