Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in text and parsing algorithm (invalid member value) #527

Open
JannisBush opened this issue Jul 7, 2023 · 0 comments
Open

Comments

@JannisBush
Copy link
Contributor

While reading the specification I perceived an inconsistency between the text and the parsing algorithm.
If there is actually none, please explain it to me.

How should the following permission policy be interpreted: geolocation=invalid-token ?

https://www.w3.org/TR/permissions-policy/#structured-header-serialization

The Member Values represent allowlists, and must be one of:
a String containing the ASCII permissions-source-expression
the Token *
the Token self
an Inner List containing zero or more of the above items.
Any other items inside of an Inner List will be ignored by the processing steps, and the Member Value will be processed as if they were not present. Member Values of any other form will cause the entire Dictionary Member to be ignored by the processing steps.

As invalid-token is a value of any other form, the last sentence seems to take effect meaning the entire Dictionary Member should be ignored. This would mean the default value of geolocation (self) would be active.

Looking at the relevant steps from parsing results in a different outcome: https://www.w3.org/TR/permissions-policy/#algo-construct-policy

  1. Let allowlist be a new allowlist.
  2. If value is the token *, or if value is a list which contains the token *, set allowlist to the special value *.
  3. Otherwise:
    1. If value is the token self, let allowlist’s self-origin be origin.
    2. Otherwise if value is a list, then for each element in value:
      1. If element is the token self, let allowlist’s self-origin be origin.
      2. If element is a valid permissions-source-expression, append element to allowlist’s expressions.
  4. Set policy[feature] to allowlist.

We start with a new allowlist (which I assume starts empty; is this clarified somewhere?) and none of the other steps match resulting in an empty allowlist. This means the value of geolocation would be None.

Chrome seems to implement the parsing steps and the above header results in not being able to use the geolocationAPI.
It also provides the following help in the devtools:

Error with Permissions-Policy header: Invalid allowlist item(invalid-token) for feature geolocation. Allowlist item must be *, self or quoted url.
I could not find anything about error reporting in the specs and assume this is an optional feature that chrome added to help developers?

If my interpretations are correct, I would suggest updating the first text to clarify that invalid values outside of inner-lists will result in an empty allowlist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant