New principle: separating fast code paths from safe ones

[DerekNonGeneric]

This was brought up in our discussion of @openinf/util-md-table (as an example) where we have a function that transforms some arbitrary user-provided text in string form. The project's security support has expired, and there are minimal users (even fewer in production, if any), so feel free to speak freely and frankly about any security weaknesses or product defects, etc.

In the Twitter thread that sparked this issue, i mentioned that i was torn btwx two competing function naming conventions:

• textTransform
• safeTextTransform

… where the safeTextTransform rendition of the API would perform (at minimum) additional string normalization string retokenization for the passed input while the fast rendition of this API would only perform the same run-time type checking of arguments as its secure counterpart. This is a very simple example but would like to get this issue opened sooner rather than later and intend to add additional examples and competing schools of thought shortly.

Thanks!

/cc @LeaVerou @cynthia

[DerekNonGeneric]

additional examples

• safe-stable-stringify

• fast-json-stringify

• Fast Fourier transform (will have to defer to the expertise of @dynamicwebpaige)

• autoescape overrides

competing schools of thought

[…] the better way in my opinion is to have the safe version be the default, like
React’s setInnerHTML and dangerouslySetInnerHTML
(https://legacy.reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml) or
how server side templating languages escape HTML unless it’s declared safe
—https://twitter.com/philnash/status/1653887389079851009 by @philnash

Similarly, most SQL ORMs make the easy path to make a query the sanitised way,
but you can construct your own SQL if you find you need to.
—https://twitter.com/philnash/status/1653888172944924672 by @philnash

[…] if you choose to write SQL by hand, the use of a "sql tagged template"
is good for security […] safer than writing the long version by hand […]
—https://twitter.com/cramforce/status/1654569294620135424 by @cramforce

[annevk]

Marking what is "unsafe" is what we already recommend: https://w3ctag.github.io/design-principles/#naming-unsafe.