If a site knows it may have been compromised, it could simply force users to change their passwords on the next login. There is precedent for this (Adobe is one I recall), and it doesn't require any new smarts on the client side.
Great, and how do the users keep track of which of the hundreds of sites they use have done that? With the idea I'm proposing, it's possible to automate this _in the client_, such that users can proactively defend themselves against sites that haven't patched themselves or even indicated whether they were ever vulnerable in the first place.
"Do you want to visit this web site? It may by vulnerable to the CVE-2014-0160 (a.k.a. 'the Heartbleed bug')." or the like.
What site operator would install something which turns users away? Users will just click OK anyway, and if there is no OK button, users will decide their client is broken and go back to using Internet Explorer.
I'm trying to understand what the workflow and incentives are here. Not every site operator is very security-savvy, and to a first approximation no users are.
What site operator would install something which turns users away?
The point of this proposal is mostly to enable sites to tell users that they _have_ been fixed (and when), not to tell users that they _haven't_.
Having said that, site operators pay to install valid SSL certificates from valid CAs because they know that if they won't, the browsers will increase the friction necessary for users to access their site.
If something like what I am proposing is widely adopted, then not patching their sites and notifying users that they have done so will similarly increase friction, so site operators will have an incentive to do it.
Not every site operator is very security-savvy, and to a first approximation no users are.
The penetration of password management apps like LastPass continues to increase. The fact that many users do not choose to avail themselves of better security is no justification for not implementing better for security for the users who do.
If that were not the case then SSL would not exist.
Comments
If a site knows it may have been compromised, it could simply force users to change their passwords on the next login. There is precedent for this (Adobe is one I recall), and it doesn't require any new smarts on the client side.
Great, and how do the users keep track of which of the hundreds of sites they use have done that? With the idea I'm proposing, it's possible to automate this _in the client_, such that users can proactively defend themselves against sites that haven't patched themselves or even indicated whether they were ever vulnerable in the first place.
"Do you want to visit this web site? It may by vulnerable to the CVE-2014-0160 (a.k.a. 'the Heartbleed bug')." or the like.
What site operator would install something which turns users away? Users will just click OK anyway, and if there is no OK button, users will decide their client is broken and go back to using Internet Explorer.
I'm trying to understand what the workflow and incentives are here. Not every site operator is very security-savvy, and to a first approximation no users are.
The point of this proposal is mostly to enable sites to tell users that they _have_ been fixed (and when), not to tell users that they _haven't_.
Having said that, site operators pay to install valid SSL certificates from valid CAs because they know that if they won't, the browsers will increase the friction necessary for users to access their site.
If something like what I am proposing is widely adopted, then not patching their sites and notifying users that they have done so will similarly increase friction, so site operators will have an incentive to do it.
The penetration of password management apps like LastPass continues to increase. The fact that many users do not choose to avail themselves of better security is no justification for not implementing better for security for the users who do.
If that were not the case then SSL would not exist.