- From: Mike West <mkwst@google.com>
- Date: Fri, 16 Jan 2015 06:15:07 +0100
- To: David Walp <David.Walp@microsoft.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Chris Palmer <palmer@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=czv2aYYjmu23xXL14We--TL1Z-mw3VkW+iiiqYHbBt7w@mail.gmail.com>
Great. Thanks David! -mike -- Mike West <mkwst@google.com>, @mikewest 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.) On Thu, Jan 15, 2015 at 11:04 PM, David Walp <David.Walp@microsoft.com> wrote: > Thank you for your help Mike. I think we are closed on all the items we > raised – final comments below. > > Thursday, January 15, 2015 1:01 AM - Mike West [mailto:mkwst@google.com] > wrote: > > >> On Thu, Jan 15, 2015 at 1:27 AM, David Walp <David.Walp@microsoft.com> > wrote: > >> We understand your arguments. We already live with these issues every > day. Being able to handle the intranet different from the internet is > important to a number >> of customers. Provided we not consider out of > compliance for how we handle the intranet, we are fine with the spec as it > is. > > > There is nothing in the spec that distinguishes between private and > public networks (and, in fact, such a distinction was actively removed from > the spec), and I don't > > believe adding an intranet carveout to the spec is a good idea. > > We agree. The spec doesn't need to distinguish between private and public > networks. Work we are doing to help our customers migrate doesn't need to > cover. > > >>>>> 7) Section 5.1, Example 5 - "even though the framed data URL was > not". > >>>>> We believe the text "even though the framed data URL was not" is > incomplete. Our opinion is that data URL should be treated the same as the > web page that contains > >>>>> the data URL. > > >>>>As a.com was loaded over a secure connection, the framed data URL > inherited the secure context of its parent and hence loading from evil.com > is blocked. Make sense? > > >>>It's not clear that we're disagreeing about the conclusions here. :) Do > you still think the wording needs to be changed? > > >>We think more explicit here would be helpful. > > >Does > https://github.com/w3c/webappsec/commit/537aa36231ba52455917b9a0a81deb6b6ad475d6 > address your concern? > > Yes, that is great - thank you. >
Received on Friday, 16 January 2015 05:15:55 UTC