- From: Igor Bukanov <igor@mir2.org>
- Date: Fri, 19 Dec 2014 12:55:44 +0100
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CADd11yWSVOc1+PQzWt=KfAwtPX8X0V1gvfsNva3K0vCjWXCMvQ@mail.gmail.com>
It is worth to consider the origin of the current warnings for bad https sites. The premise was that if a user types https:// , then she explicitly asked about security and all violations should be reported. Typing http:// was considered that user communicated that she did not care and no reports should be generated. That premise naturally lead to the current situation when a site with self-signed is reported while plain http:// is not. What went wrong with warnings was that even users that were aware that for their banking site they need to type https:, they most often than not asumed that typing https:// by itself guaranteed that everything should be fine. Any warnings about security were perceived as a problem with the browser that should be ignored, not as a problem with the site or a potential attack. This interpretation of ssl warnings as brokenness of the browser is enforced when a user follows links to a https site. A natural assumption is that the links worked for the author of the document and any warnings means that something was wrong with the browser. In view of that it is important to make very clear for the user that any warnings about plain HTTP indicates that the site operator has not done their job properly. Nothing is wrong with the browser. I suspect a message that puts a shame on the site for not implementing https would be much better then informing the user that a connection can be monitored or subverted.
Received on Friday, 19 December 2014 11:56:11 UTC