You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 13, 2021. It is now read-only.
This is no longer a WIBNI, I'm upgrading it to Long-Term Goal. I'm convinced this is substantially more important for privacy and security than I previously realised.
More work needs to be done here. Ideally we want a unified way to control security policy, preferably with fine grained control. For example, users ought to be able to specify different security policy for different hosts on different schemes. This would allow users to have security policy that says something like:
If accessing twitter.com over HTTPS, verify certificate against a local copy, only allow strong ciphers, do not follow AltSvc recommendations; else
If accessing twitter.com over HTTP, use OppSec where available, verify certificate against a local copy, allow weak ciphers, follow AltSvc recommendations; else
If accessing any other site over HTTPS, verify certificate against local set of root CAs, only allow strong ciphers, do follow AltSvc recommendations; else
If accessing any other site over HTTP, use OppSec where available, do not perform cert verification, allow weak ciphers, follow AltSvc recommendations.
This form of fine-grained security policy is useful, but we need to have an intelligent API and intelligent defaults. Again, most users won't need this so they should fall into a pit of success, with secure default values and behaviours. Users who do want it should be able to set extremely fine-grained security policy.
A further benefit would be to have detailed documentation about how to use the security policy tools. This should provide users with a good idea of what actions strengthen security, what actions weaken security, and what you gain/lose in functionality when performing those actions.
HTTP/2 currently has a provision for opportunistically encrypting HTTP/2 on port 80. It'd be nice if we could do that too.
The text was updated successfully, but these errors were encountered: