[wg/css] CSS Working Group Charter

[svgeesus]

New charter proposal, reviewers please take note.

Charter Review

Charter:

If applicable:
diff from previous charter and diff from template

chair dashboard

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing

• Existing WG recharter

Communities suggested for outreach:

Known or potential areas of concern:

Where would charter proponents like to see issues raised? CSSWG issue

Anything else we should think about as we review?

Note: proposed chairs should be copied @... on this issue.

@astearns @atanassov

[ruoxiran]

There is an extra < in section 1. There are no other comments from APA.

[himorin]

no comment or request from i18n, with great thanks for all of your works!

[svgeesus]

Thanks, typo fixed

[svgeesus]

@simoneonofri any security comments? @plehegar any comments from PING?

[simoneonofri]

Hi, @svgeesus, on the charter, it's indicated the need for Security Considerations, and that's fine.
I'm quickly looking at the various deliverables.

There are quite a few, and in general, as written in the various Security Considerations.

To summarize.

Common Threats / Attacks

Information Disclosure (aka Information Leakage)

on several levels (say Infokeak is a Security-Privacy hybrid threat):

• Installed fonts: e.g. the font-face then device information, or coeme @media, @support
• Visited Links: other times in combination with JavaScript leak on user navigation or via CSS Paint
• User Dictionary: as for [pseudo-elements](pseudo
• Images via Timing Attack

Perhaps we can consider it more at the implementation level, infoleak leading to memory corruption, as is specified Transitions, and it would be useful to specify good standards at the implementation level, as happened on WebGPU?

Tampering Data

• CSS Injection, in general
• Loading files from the local network/internet? e.g., Cascading and Inheritance, Values and Units

If we use STRIDE, we also have Spoof Identity, Repudiation, DoS, and Elevation of Privilege. I'm pondering whether they can be applied to CSS as well, if you think of this model, broadly speaking, can you think of anything? (e.g., for DoS, we often implement limitations so as not to saturate resources)

Security Considerations

Some deliverables:

• Still need Security Considerations, e.g., CSS Speech Module
• Have the statement “This specification introduces no new privacy leaks, or security considerations beyond ‘implement it correctly’” e.g., Writing Modes. The directives for correct implementations are specified somewhere, such as in Transforms Module or on Filter Effects? I like this approach.
• Others indicate “introduces no new privacy leaks, or security considerations,” though in that case, it would be useful to point to “known” ones such as on Geometry Interfaces Module.

[svgeesus]

@simoneonofri thank you. As these are comments on individual deliverables it would be helpful to raise them on csswg repo against the relevant spec, so that they don't get lost.

On your more general points:

“introduces no new privacy leaks, or security considerations,”

I hate when people write that, such a bold and unsubstantiated claim. Instead I encourage

No privacy concerns have been raised against this specification
No security concerns have been raised against this specification

In other words statements which are provably true or false.

Some old/unmaintained specs still have one section for both Privacy and Security, or indeed no section at all; I fix these as they get published to /TR.

[simoneonofri]

@svgeesus thank you for your answer.

In general, I think that raising concerns, it seems more an "external" think, even if this should be a joint work between the specs developer and security experts.

And it can make sense that there are no new considerations, but it can be good a reference to the old one.\

However there are some points maybe we should work on, I'll write to the Strategy Team.

[svgeesus]

@tjwhalen any comments on this draft charter from a privacy perspective?