W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Donald Stufft <donald.stufft@gmail.com>
Date: Fri, 19 Dec 2014 12:31:37 -0500
Cc: public-webappsec@w3.org, blink-dev@chromium.org, security-dev@chromium.org, dev-security@lists.mozilla.org
Message-Id: <60A67780-1E87-43D5-9537-805B20701647@gmail.com>
To: Dominick Marciano <dominickmarciano@gmail.com>

> On Dec 19, 2014, at 11:52 AM, Dominick Marciano <dominickmarciano@gmail.com> wrote:
> Good Afternoon,
> I have read the proposal regarding marking HTTP as non-secure.  I feel that it is a good step to let users know when their information is not secure, however I also feel that applying this across the board may be too broad of stroke.
> If users are on sites that are transmitting any personally identifiable information, such as geo-location information, name, address, telephone, etc., to a non-secure site that the user should definitely be informed.  However there are also plenty of cases where a site may not employ HTTPS that the user does not necessarily need to be notified about.  Good examples of this may be news sites, blogs, etc., where a user does not need to login or provide any other information.  In these cases (where no data is being transmitted) HTTPS is not necessary and if users are being warned about every site they are going to (that doesn't use HTTPS and doesn't transmit any data), I believe a lot of users will start ignoring the warning (or call their IT company) and then the warning will provide no additional benefit.
> If possible, I believe this the warning would be better used in cases where a user is on a site not using HTTPS but is still transmitting personal information (location, name, telephone, etc.) in addition to login pages not using HTTPS.  I don't know the feasibility for this, but I strongly feel that the more specific the warning could be (instead of just every HTTP site), the more useful they will and will hopefully users will be more attentive to them when they appear.

TLS does more things than just provide secrecy about information that the user is sending *to* the site.

For example, you mentioned the news. The integrity of the content of that site is extremely important. Maybe the news is posting locations and times when polls are opening for elections, or maybe there is an article talking about the performance of some companies and someone goes and uses that information to make a purchasing decision.

You’ve also mentioned blogs, It’s not unusual that I personally read some technical blogs and in the course of that they may describe commands that I should run to try something out that they are describing. Without checking the integrity of that a MITM could easily change those commands to do something malicious instead of what the blog post claims they are.

Beyond integrity, a completely anonymous HTTP request (No cookies, no geo-location, etc) can also provide some incredibly personal information. Maybe the person in question is looking up information on having a particular medical condition and now a MITM can easily see that this person went to a local doctor’s website, then went to a few websites about dealing with a specific condition, then went to a specialists website.

It’s incredibly difficult to look at any one particular website and say that all of the data that is contained within that website, all of the data that a user might send to that website, and all of the traffic analysis that shows what part of that website the user went to isn’t sensitive personal information. Given that there’s no way to determine what is important to the end user or not, there’s no real way around letting the end user make that decision. Making a decision requires being informed and what this proposal really does is tell the users the truth so they can make that informed decision instead of lying to them by omission.

Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Received on Friday, 19 December 2014 17:32:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC