[css-contain] Security/Privacy considerations of css-contain misuse?

[svgeesus]

From Ralph Swick, on the css-contain CR transition call:

Security considerations should include something about risks and counter-measures if a bad actor misuses these new features; e.g. to alter (and misrepresent) what is rendered to the user.

Would it be appropriate to have some test cases that misuse the features and test what the implementation does in those situations?

[tabatkins]

This applies to every single CSS draft; all of them can be "misused" to alter/misrepresent what is rendered to the user (that is, in fact, precisely what CSS is defined to do ^_^).

Contain doesn't do anything special in this regard. If this is a legit criticism we must answer, then it should be added to the CSSWG boilerplate, not manually added to every spec.

[astearns]

I don't think it would be useful to have a boilerplate "CSS can be misused" mention. The security section should either have the boilerplate "no new things here" or call out new specifics.

I think there might be some new things in css-contain with regards to security. Style containment gives people a new way to alter displayed counters. Size containment is a new way of creating overflow. Paint is a new way of clipping. Are any of these capabilities security concerns?

Perhaps we should have a list of CSS capabilities that do raise security concerns, and note when a draft creates a new way of invoking a capability.

[dbaron]

Security concerns might also include "things that people sanitizing untrusted CSS for various security reasons need to pay attention to", although it might be that the working group doesn't have the necessary expertise to know what's important there.

[tabatkins]

@astearns There is nothing new in Contain that needs to be called out. All of the functions you call out can be accomplished with existing CSS properties. None of the specs that define those other properties call these functions out specially, because there's no real need to; the abilities are essentially "format the page", which is CSS's core remit.

@dbaron Yeah, that's legit. Contain's intrinsically local effects do not, I believe, require any special attention in this regard; the worst it can do is mess up your own HTML. (Assuming that you're restricted to posting only style attributes or similarly localized CSS; if you can give page-global CSS that isn't sanitized with a careful whitelist, the page is already pwned in general.)

[frivoal]

I agree with Tab, and I do not think there is anything in this draft regarding security and privacy that needs addressing.

That said, to prove that we've considered it carefully, we could expand the current "nothing to see, move along" one liner and answer all the questions in the security and privacy questionnaire prepared by the TAG https://www.w3.org/TR/security-privacy-questionnaire/#questions.

@svgeesus, do you think this would satisfy Ralf?

[svgeesus]

We could add that, but a long questionnaire where all the answers are "no" does not really add something. And it would be the same for pretty much every CSS module, implying it would be seen as boilerplate.

However, we could add such an appendix to the next CSS Snapshot, covering the whole of CSS.

[frivoal]

As far as I understand, this is what the security and privacy questionnaire prepared by the TAG is for, and it's already been used on a few specs. Should we stop doing that? should we do it systematically?