On Tue, March 5, 2013 6:55 pm, Tom Ritter wrote: > On 4 March 2013 19:57, Ryan Sleevi <[email protected]> wrote: > > The authors belief is that the issues that arise from either > > implementations are artifacts of the implementation and distribution of > > preloaded pins, rather than an issue intrinsic to this specification. > > That > > is, the "correct" answer is that the preloaded pin list should be > > updated > > for Site 1 - however that information is distributed between the site > > operator and the creator of the preloaded pin list. > > > > Are there concerns with this interpretation, or can we close out Issue > > 55? > > I guess I'm just confused. I agree it's rife for implementation > differences, but I either > A) Incorrectly parse this as punting on guidance that would (try to) > achieve parity across implementations and prevent yet another thing > that webmasters need to understand when requesting preloading in > multiple browsers > b) Correctly parse it as such, but don't understand why you would punt > on expressing a standard behavior instead. > > -tom >
I think the real answer should be that preloading shouldn't be part of the spec, as it really is an implementation-specific behaviour. Certainly, it's based on our experiences in Chrome/Chromium, and it does provide an additional measure of security for the initial connection, but it doesn't really tie into the semantics of the header at all. Different applications - including such like Firefox - have already expressed interest in pursuing different schemes for preloading and the maintenance of such lists. Certainly, we've looked at alternatives ourselves. Our thinking is that we should avoid baking such behaviours into a spec, and instead focus solely on the header and observation aspects. Unlike the header - which is presumably provided to all user agents and uniform implementation expected - preloading is (at least, today) about a relationship between the site operator and individual user agents, so there's already a communication channel. If other implementations pursue different schemes - eg: such as crawling and noting pins - then they may have vastly different needs/requirements, but the overall semantics of the header itself remains the same. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
