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 ?
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.
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.
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
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
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:
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.