mikewest

Happily(?), IPv4 networks are still pervasive, and this proposal seems clearly valuable in those environments.

Longer-term, it seems clear that it would be valuable to come up with ways in which we can teach browsers how to trust devices on a local network. Thus far, this hasn't been a heavy area of investment. I can imagine it becoming more important if we're able to ship restrictions like the ones described here, as they do make the capability to authenticate and encrypt communication channels to local devices more important.

The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.

To that end, we've implemented the change behind two flags (chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure) so that we can work with developers to help them migrate cookies that need to be accessible cross-site to `SameSite=None; Secure`.

Ideally, we won't unintentionally break anything when we're confident enough to ship this change.

https://tools.ietf.org/html/draft-west-cookie-incrementalism spells out the proposal in a bit more detail.

It should be unaffected by the suggestion in this document.

The next line in the document is "IPv6 loopback addresses are defined in Section 3 of [RFC5156] as '::1/128'." :)

I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.

The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)

I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.

https://twitter.com/dbrower/status/781001487157719040 raises similar concerns. The rationale is simple: I wanted to make the smallest change possible to RFC6761, and item 3 of https://tools.ietf.org/html/rfc6761#section-6.3 already contains the address query restriction.

It's probably reasonable to reconsider it, that's just a larger change than the one I was specifically trying to make. :)

I'd very much appreciate it if you could point me at things that aren't working in Canary. :)

2. I'm not sure what you mean.

3. We can't, and don't want to, change the license of code that's already been released. That said, most (all?) of WebCore isn't LGPL. See my favourite file, http://trac.webkit.org/browser/trunk/Source/WebCore/page/Con... for example.

4. WebKit and Chromium have historically had differing opinions regarding what makes a "good" comment. I think you can expect Blink's code to tend more and more towards Chromium-style as time goes on, but it's not going to happen overnight.

5. ~5 million lines of code that we don't currently compile or run in Chromium. That's a bit, but it won't have much effect on the binary size.

6. Short term, not much will change. Longer term, a few things will probably happen: for instance, the widget tree will likely be removed, and we'll likely be able to step back and reevaluate some changes in light of that.

The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits.

Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)

Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run with, Apple created its own framework. That had advantages and disadvantages.

More generally, I'd point to the Content layer as a better integration point: Opera, for instance, is building on top of our multi-process architecture successfully. Chromium Embedded Framework (https://code.google.com/p/chromiumembedded/) is another example of how other projects can leverage the work we've done.

I'm honestly quite hopeful, both about Blink, and about WebKit.

Diversity in implementation is a great way of hammering out the exact contours of the standards that govern the common project...

We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.

We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.