Improve testing story

[annevk]

If we make requestStorageAccess() document-scoped (again) and define it in terms of Permissions, https://w3c.github.io/permissions/#automation becomes an attractive way of testing this feature (and some tests already assume this can be used it seems). We need to resolve these questions:

1. Is changing a permission to "granted" through WebDriver sufficient for all user agents to not have to show a prompt or do we need an additional WebDriver command that ensures a requestStorageAccess() call does not result in one? (Let's assume here that requestStorageAccess() is invoked with user activation.)
2. What changes do we need to make to Set Permission to ensure it works for the Storage Access API? (In particular we need to make that API aware of multiple keys, at least for the "storage-access" permission.)

Provided we resolve these satisfactorily I think that means https://privacycg.github.io/storage-access/#automation can be removed.

[Brandr0id]

@annevk I think in previously looking at this the use of set_permission allowed tests to avoid a prompt and auto grant/deny requests as long as the impl of set_permission is aware of the 'storage-access' permission descriptor.

The more interesting thing IMO is how to setup an environment in a WPT test where storage is blocked for certain parties that we can then execute the API (with the above permission set to avoid any prompts) and verify it actually unblocks access as expected. There was some previous WebDriver/TestDriver work done to support this with the set_storage_access API (see https://github.com/web-platform-tests/wpt/blob/master/storage-access-api/storageAccess.testdriver.sub.html and Implement Storage Access commands for TestDriver | https://chromium-review.googlesource.com/c/chromium/src/+/2253280) but this would require other implementors to support this command if they do not already.

[annevk]

That makes sense, but I don't think Set Permission is defined that way.

I'm not sure I see the point of the blocking API. The idea is after all that all cross-site cookies are blocked by default.

[johannhof]

Having looked into this on Chromium side I think @Brandr0id is correct that these two APIs (which work in Chromium) are enough to write good tests for SAA. We should make them work on other platforms as well.

I'm not sure I see the point of the blocking API. The idea is after all that all cross-site cookies are blocked by default.

We need it for these tests to work in Chromium. Other platforms could no-op it for the "block" case.

[annevk]

How would the API be useful for implementations that block cross-site cookies? If blocking cross-site cookies is the desired end state, I don't think it makes sense for us to standardize an API that ends up doing nothing in the desired end state.

[johannhof]

For one, it allows granting storage access without having to go through the SAA flow with user interaction, permission grant, etc. That seems very useful to have as a WPT feature, for anything testing third party cookies or similar.

Secondly, I think it's valid and desirable that some browsers that don't ship full cross-site cookie blocking have a path to migration to technologies like the SAA, and that we don't forego any interop with these browsers during that period.

[annevk]

That seems very useful to have as a WPT feature, for anything testing third party cookies or similar.

What kind of conformance test would it help with?

[johannhof]

What kind of conformance test would it help with?

Because cross-site cookies will continue to exist (i.e. through SAA) it's likely that tests setting them will want to use this API instead of the SAA flow. If WebKit sees no other usage then you can choose to no-op the API call (or just "fail" the separate setup task where the API is called).

[annevk]

But this API is completely unrelated to how we envision that to work with rSA. And you don't have to use rSA, you would set the "storage-access" permission which is also one API call.

[johannhof]

There are a bunch of follow-up tasks here to improve test coverage (e.g. tests for per-frame, permissions.query, etc.) as well as add set_permission support in all browsers, but I think the base task of this issue is done in that we have basic tests that simulate (user-)granted and denied storage access, see https://wpt.fyi/results/storage-access-api?label=experimental&label=master&aligned