matrix-spec-proposals/proposals/4077-process-deprecated-html.md

MSC4077: Improved process for handling deprecated HTML features

The Matrix specification defines a subset of HTML which clients should use when rendering messages, limiting the possibility for Cross-Site Scripting (XSS) and similar attacks. Clients are always welcome to use a different subset in both their send and receive paths, however in practice the recommended set of HTML has become the baseline standard for support among Matrix client developers.

Additionally, to fix issues like tags being deprecated, the existing spec process would require an entire MSC to add or remove the tag. This has precedent through MSC2422 and MSC2184, where additional HTML features are analyzed from a security perspective. For example, whether XSS attacks are more probable or flooding/disruption attempts are made easier.

This proposal adjusts the MSC process to explicitly allow changes to the supported HTML tags where the WHATWG has deprecated a feature in favour of another, enabling more rapid iteration and reducing paperwork for everyone involved.

Proposal

Where the WHATWG has deprecated a feature of the HTML specification, a Matrix spec PR may bypass the MSC process to use the modern feature instead. In the case of issue#1492, the spec PR is explicitly able to add the s tag and remove the strike tag. Note that such changes can also bypass the deprecation policy in this way.

It is left to the discretion of the spec PR reviewer as to whether an MSC is required. In general, an MSC should be requested when the replacement HTML feature is not quite the same as the old feature. The reviewer may also decide whether to keep supporting the old, deprecated, feature for some time. For example, replacing strike with s may mean that both tags are supported for 1-2 Matrix spec versions before strike can be dropped.

For clarity, an MSC is always required to add net-new features to the HTML subset, or to remove a feature entirely. An example of this is MSC2398. These changes are subject to interoperability and security review, and cannot bypass the MSC process.

Potential issues

The author notes that this MSC might not need to exist under the banner of pragmatism, however for all the effort to not write an MSC, an MSC has been written for review.

Alternatives

Critically, without agreement that replacing deprecated HTML features can happen outside the MSC process, changes to the HTML subset become slow and burdensome for no apparent gain.

Security considerations

Special care and attention is expected to be taken by spec PR reviewers to ensure that changes are safe and in line with the semantics of this proposal's guidance.

Unstable prefix

Not applicable. This is a process MSC.

Dependencies

None applicable.