On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy < [email protected]> wrote:
> On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote: > > > Yes. This is the foundation and limit of Web Security. > > > > https://en.wikipedia.org/wiki/Same-origin_policy > > > > This is what is programatically enforced. Anything else either requires > new > > technology to technically enforce it (such as a new scheme), or is > > offloading the liability to the user. > > > > The notion that a sub-resource load of a non-EV sort should downgrade the > EV display status of the page is very questionable. > This is what Opera did until recently, and which early versions of Chrome have done, and what some Safari engineers have proposed. I agree, it's very questionable - that's part of why I was happy to see it removed - but it's not uncontroversial. > I'm not sure we need namespace separation for EV versus non-EV subresouces. > Without that separation, then you cannot be safe against EV downgrade attacks (even if ever-vigilant as an end-user, there are ways to subvert the state while maintaining the UI). Similarly, you cannot be safe against "EV confusibles". Under both attacks, the normal rejoinder is "The user should look" - but what they're looking at, they can't trust. The rejoinder from this thread is "Yes, but if most of the time they can trust, it's not so bad" - to which I reply, yes, it is bad, if they're trusting something they can't trust and just getting lucky that a stopped clock is right twice a day. > Frankly, I reduce third party origin resources to zero on web applications > on systems I design where those systems have strong security implications. > > Of course, that strategy is probably not likely to be popular at Google, > which is, in a quite high percentage of instances, the target origin of all > kinds of sub-resources loaded in pages across the web. > Nope. This is incredibly popular, both in Google at others. However, rather than needing to reduce those resources to zero, you can use things like Subresource Integrity to provide assurances. But you're correct in that it's missing the point of the discussion - those resources don't affect state, and the users assurances - even of the UI shown - has technical limits that prevent it from meeting user expectations. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
