[TAG] Raising error causes

[triblondon]

From TAG review

If an iframe is permitted to use a feature but chooses to disable it in its own header, it presumably retains the power to re-enable it on an embedded iframe using an attribute, whereas if the feature was disabled by a policy in the parent document, it will not be allowed to re-enable it on a nested frame. Should there be a requirement for the UA to issue an expressive error if an allow attribute attempts to enable a feature that has been prohibited at a higher level?

[clelland]

If an iframe is permitted to use a feature but chooses to disable it in its own header, it presumably retains the power to re-enable it on an embedded iframe using an attribute

That shouldn't be allowed. I believe that the algorithms ensure that if the feature is disabled in a document, that it cannot re-enable it in its children. That's the intention, at least.

Should there be a requirement for the UA to issue an expressive error if an allow attribute attempts to enable a feature that has been prohibited at a higher level?

That might be a good idea -- what form should that error take? A console warning/error would be unobtrusive and (hopefully) discoverable by developers. An error event on document or the iframe itself might be possible, but may create backwards compat issues.

[raymeskhoury]

That shouldn't be allowed. I believe that the algorithms ensure that if the feature is disabled in a document, that it cannot re-enable it in its children. That's the intention, at least.

Specifically, by disabling a feature in a header, the website is making a guarantee that it will not use the feature. If it could be re-enabled in an iframe, then that guarantee could be broken. For example a site could guarantee that it doesn't use location in order to mitigate the damage of a successful XSS attack. But if the feature can simply be re-enabled in an iframe of that site then there is no actual protection.

[ojanvafai]

Reporting an error in this case seems reasonable. There's a few options for reporting, we could use one of the new Reporting APIs being worked on and/or log to the console.

We'd like to see if this is a problem developers complain about before doing so though.

[loonybear]

An update: If in the process of determining the inherited policy, a child frame is trying to enable a feature has been disabled by its ancestor frame, then a console warning / other kind of reporting API will be triggered to inform the web developer.