- From: Mike West <mkwst@google.com>
- Date: Wed, 4 Jun 2014 10:15:22 +0200
- To: Brian Smith <brian@briansmith.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=eyH0XQjRmFTeQot+zxvV0Gk9oXgMmp1dGijKQ=wHZ5YQ@mail.gmail.com>
Thanks Brian! Forking your suggestions into separate threads for my own sanity. :) On Tue, Jun 3, 2014 at 6:31 PM, Brian Smith <brian@briansmith.org> wrote: > Change 1: I would like to have the scope expanded beyond TLS-protected vs. > non-TLS-protected. In particular, I'd like to see Firefox's rules for > blocking file:// subresources in non-file://-documents incorporated into > the specification. I'd also like to see the MSIE11's zone rules for local > (intranet) vs. non-local (internet) servers considered for incorporation > (something that Firefox is also working on adopting). This way, the > specification would completely document/define which origins a subresource > could be loaded from as a function of the document's origin. This would > also solve the problem with defining "assumed secure origin." > I think this makes sense. I certainly focused on TLS/non-TLS in the draft, but that does create problems such as those you've pointed out. I'll work on updating the draft. 'file:' URLs should certainly be blocked from web addresses, as should internal IP addresses (as defined by RFC1918). There's some discussion on the Chromium bug tracker at https://code.google.com/p/chromium/issues/detail?id=378566. Is there a similar discussion I could follow on Bugzilla? -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 4 June 2014 08:16:10 UTC