Feature detection for APIs behind enrollment

[Elchi3]

There is a new gating mechanism for certain APIs. It's called "enrollment". I think it currently affects Google Chrome Desktop, Google Chrome Android and Google Android WebView. The following APIs can't be feature detected by the collector as a consequence:

• Attribution Reporting API
• Fenced Frames API
• Protected Audience API
• Shared Storage API
• Topics API

Google says "You do not need to enroll to test privacy sandbox features locally. To allow local testing, enable the chrome://flags/#privacy-sandbox-enrollment-overrides developer flag."

What should we do? Have the collector flip the preference in Google browsers and then collect results?
Is there another way? How will web developers feature detect these APIs?

@foolip thoughts?

[queengooborg]

I think that we'd have to treat this the same way that we would treat secure_context_required, which we don't have implementation for, but we have an idea. The idea is to run the Selenium script both with HTTP and HTTPS, collecting results for both.

It will be extremely important to mark tests with enrollment enabled somehow, since we can't programmatically determine what flags had been enabled from the web app side.

[Elchi3]

It will be extremely important to mark tests with enrollment enabled somehow, since we can't programmatically determine what flags had been enabled from the web app side.

Yeah I agree. I think BCD may want to mark these features with a note saying "enrollment needed" or so as well, and it would be great if the collector could add such a note automatically if possible.

[queengooborg]

We should probably start by writing a BCD guideline for features requiring enrollment?

[foolip]

Where is the quote "You do not need to enroll to test privacy sandbox features locally. To allow local testing, enable the chrome://flags/#privacy-sandbox-enrollment-overrides developer flag." from? I can't find anything :)

I'm not sure if this is the same as origin trials, or if it's a new thing.

[Elchi3]

Where is the quote "You do not need to enroll to test privacy sandbox features locally. To allow local testing, enable the chrome://flags/#privacy-sandbox-enrollment-overrides developer flag." from? I can't find anything :)

Sorry that was in some MDN docs actually (see here), but other sources say to flip the pref, too: https://github.com/privacysandbox/attestation/blob/main/how-to-enroll.md

I looked if/how WPT solves this and it seems many tests just fail? Do you know if these get tested somehow?

• https://wpt.fyi/results/private-aggregation
• https://wpt.fyi/results/fenced-frame
• https://wpt.fyi/results/shared-storage
• https://wpt.fyi/results/browsing-topics

[Elchi3]

I don't know why these APIs are designed this way. They could have been exposed and then fail with an error that enrollment is required. That would at least have helped with feature detection. Now they are invisible until enrolled.

[Elchi3]

mdn/browser-compat-data#21194 is a good example how it's hard to verify support for APIs that are gated with enrollment.

[chrisdavidmills]

I chatted to @samdutton about these issues, and he asked me some questions and made some points that may help:

1. With the way you test features (using the collector, etc.), are you able to set browser flags before running the test?
2. Can you run Chrome with the "Privacy Sandbox Enrollment Overrides" flag set so that you don't need to enroll to test
3. Otherwise, could you use an enrolled test app to test whatever the feature is?
4. He also wondered if Permissions-Policy might be a problem? Some services block privacy sandbox stuff, for example github.io.
5. In terms of the question of whether they are enabled and rolled out to all users, he said they are enabled for all users at this point. There is a small holdback group for control purposes, but it is unlikely you'd come across it.
6. Lastly, he said he'd be happy to chat with us more about these issues.