Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

17.12.2014, 20:19, "Anne van Kesteren" <annevk@annevk.nl>:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>>  I respectfully, but strongly, disagree :) If you want to separate the
>>  states, I'd say that C is better than B. C has *some* security, B has
>>  *none*.
>
> You would advocate not blocking on certificate failures and just hand
> over credentials to network attackers? What would happen exactly when
> you visit e.g. google.com from the airport (connected to something
> with a shitty captive portal)?

This is a pretty interesting use case. When you connect at the airport, the typical first thing that happens is you get a warning saying that the site you want to connect to has the wrong certificate (you went to pogoda.yandex.ru but the certtificate is for airport.logins.aero, or 1.1.1.1).

If you are me, you wrestle with the interface until you find out how to connect anyway, and hope that it doesn't remember this for other places (and that I do).

so having handed over your credit card details to get 30 minutes of connection time, you're in a hurry (your plane will leave soon, and you still haven't told Mum you're hoping she will collect you when you land).

If you're visiting google.com, it's hard to see what the next interstitial does that is useful. To take the standard Coast example, if you went to myAe.ro every day for the last month, and their certificate expired yesterday but hasn't changed, I think the answer is pretty clear. 

If it expired last month, and you've been using it for a year, there may be an issue. If it is brand new and registered to someone else, there might well be an issue even though the certificate itself looks good…

just some thinking out loud…

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 17 December 2014 18:45:21 UTC