nitori

nitori OP wrote

Both Basic and Digest access authentication are improved to provide a better native-looking browser-based experience than form-based authentication.

Oh how I wish we got Cookie-based authentication implemented straight in HTTP itself instead of having to use forms...

The spec has been updated with a new set of accepted headers - and in a break with past tradition, any header not in the list of accepted headers is to be rejected by a compliant server.

Wait that just breaks backwards compatibility with HTTP/1.1, how can this joke protocol be 1.2 lol

2

nitori OP wrote

Actually perhaps we might not need compression for the response headers even, but some sort of ETag.. There'd be like a Headers-ETag for the unique value and Headers-ETag-Names (I'm not satisfied with this name but can't think of something better) for the list of redundant headers to not be repeated in subsequent requests

2

nitori wrote

I'm not sure about doing a warrant canary tbh. It's going to be another responsibility to keep up on a regular basis (Raddle updated their canary monthly before they've made it irregular, and other companies do it every 6 months). Updating the canary itself is not the hard part (until you get an actual gag order), but rather remembering to do it lol. If you forget, users might think jstpst got compromised when it's not

If you're going to do it anyway, it might be a good idea to have at least one admin who is outside of 14 Eyes doing the cryptographic signing, so that a government agency from those countries couldn't just force an admin here to update the canary

3