w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
399 stars 155 forks source link

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

Open JannisBush opened 1 year ago

JannisBush commented 1 year ago

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.