- From: David Walp <David.Walp@microsoft.com>
- Date: Thu, 15 Jan 2015 22:04:37 +0000
- To: Mike West <mkwst@google.com>
- CC: Anne van Kesteren <annevk@annevk.nl>, Chris Palmer <palmer@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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 Thursday, 15 January 2015 22:05:46 UTC