- From: 陈智昌 <willchan@chromium.org>
- Date: Wed, 21 May 2014 01:01:26 -0700
- To: Martin Nilsson <nilsson@opera.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYhfB8uo4cBgJVqNQSQ-HBncvFY0boa7GhiDwy6gnYVEqg@mail.gmail.com>
But transport security != web security, there is plenty of practical difference. Different schemes implies different web origins. The webpage is *not* equivalent with if the page were loaded as https. Now you get differences in same origin policies and CORS and referrer policies and blah blah blah. Not to mention it'd be a lame user experience to start out with a green lock and then when an insecure resource is loaded (which we'd have to allow, unless we want to block mixed content for opportunistically encrypted webpages) to remove the security indicator. We should avoid confusing the user with changing security indicators during a page load. On Tue, May 20, 2014 at 11:56 PM, Martin Nilsson <nilsson@opera.com> wrote: > On Wed, 21 May 2014 00:55:42 +0200, William Chan (陈智昌) < > willchan@chromium.org> wrote: > > > Transport security is very different from web security. For example, only > some of the resources in a webpage may be opportunistically encrypted with > strong authentication. If there's active content like script that's loaded > without transport security, that can compromise the entire page. > > > Yes, of course. I'm asking about the case where everything is equivalent > with if the page were loaded as https. Certificates check out, all > dependencies are secure, etc. Section 6.1 states that the page MUST NOT be > indicated to be secure, even though there is no practical difference. > > > /Martin Nilsson > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ >
Received on Wednesday, 21 May 2014 08:01:54 UTC