On Fri, Jan 30, 2015 at 6:45 AM, Deian Stefan <deian@cs.stanford.edu> wrote:
> Wish I was at AppSec to hear the discussion :)
>
If there was discussion, it would be nice if someone took notes and posted
them. *cough*
> Instead of overriding the pinned policy with the header-supplied policy,
> have you considered treating the pinned policy as a base policy and
> requiring the CSP header to provide an `override-base` directive to
> override the pinned policy? (I don't think that this is incompatible
> with `no-override`.) This clearly favors security over deployability,
> but I'm curious to hear if there was any discussion about this.
>
This ends up being the same as the initial proposal, but with an option on
the page's side rather than the pin's side. I guess I'd suggest that we
should just pick one of the ~3 proposed models, and run with it.
That is, either:
1. The pin always applies to every resource loaded from a set of hosts, and
can be combined with (but not overridden by) a page's policy.
2. The pin applies only to any resource loaded from a set of hosts that
doesn't contain it's own policy.
2a. The pin applies only to any resource loaded from a set of hosts that
doesn't contain it's own policy, unless 'no-override' is set, in which case
#1 applies.
3. The pin applies to every resource loaded from a set of hosts that
doesn't contain a policy with a 'override-
pin' directive.
3a. The pin applies to every resource loaded from a set of hosts that
doesn't contain a policy with a 'override-pin' directive, unless
'no-override' is set in the pin, in which case #1 applies.
For simplicity's sake, I'd vote for #2, with the option of moving to #3 in
the future. That 'no-override' model leaves the majority of the power with
the _pin_ and not the _page_, which seems like the right tradeoff.
WDYT?
-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.)