Re: [secure-contexts] Just this source, silence network communication

Hi!


>
> I've heard of this threat model before, and didn't understand it then,
> either. :) If the site operator controls their site, they can simply author
> their content such that it doesn't do this. Right?
>

I feel like a lot (most?) of the security headers and stuff we build
is to help site operators (esp security teams for webapps) not make
mistakes. Everyone could in theory write a secure site but in practice
it is very hard. The same argument applies to CSP whitelist sources,
suborigins, the referrer-policy header and so on. Setting it in one
place makes security engineering's job a lot easier and the likelihood
of bugs much lower.

> It seems like a CSP header saying "default-src none" would instruct the
> browser to enforce this goal. Does that work?

iiuc, window.open, preconnect, postMessage are a couple of cases of
data leaks not covered in CSP right now; and default-src also doesn't
cover any of the document and navigation checks (navigate-to,
form-action,base-uri).  And stuff like navigate-to isn't implemented
(is it even in Chrome yet?) afaik.

Further, I think, for this problem, it would be nice to have a
directive that is more general so that as new features are added to
the web-platform, this directive is check. Tomorrow if we add a new
feature that could cause network requests, none of the existing CSP
directives will apply.

That said, I do agree with you that I am not sure how interesting or
valuable this is and whether its worth specing out given the
complexity it adds to the platform. But I don't have a strong opinion
on this.

>> Browser plugins should be disabled (is that even feasible?).
>
> The browser is the user's agent, not the site operator's agent.
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>
>> Well, if that could happen, then the url bar could turn a different color
>> or whatever to indicate that nothing is leaking.
>
>
> The last thing we should do is to complicate security-critical UX, which
> people already have a hard time understanding, for a marginal and
> hard-to-prove security assertion. Sorry. :)


I agree to both these points!


cheers
Dev

Received on Saturday, 14 April 2018 17:03:36 UTC