mikewest

IPv6 does indeed complicate things. I suspect we'll end up trying a few things before finding the right answer, starting with a) allowing network admins to configure IP ranges that correspond to the network they control, and b) examining the local network to infer a private range.

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

That's an open question (https://wicg.github.io/cors-rfc1918/#issue-207ba0b9). Feedback welcome!

Correct. https://wicg.github.io/cors-rfc1918/#dns-rebinding describes this reasoning.

The core assertion behind this proposal is that devices and services running on a local network can continue making themselves available to external networks if and only if they can update themselves to make that desired relationship explicit. If they can't update themselves, they also can't fix security bugs, and really must not be exposed to the web.

Correct. In the status quo, you will be best-served by looking at solutions similar to what Plex is shipping (https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...). ACME's DNS-based challenges might even make this easier today than it was when that mechanism was designed.

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 not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately.

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.

We did just clarify this in the spec: https://github.com/httpwg/http-extensions/commit/49bcb4fddb8.... Hopefully that, plus the tests we'll add in https://bugs.chromium.org/p/chromium/issues/detail?id=960375 will help other vendors align their behavior with developer expectations.

Unfortunately, crawling isn't a terribly effective way of evaluating breakage, as the crawler doesn't sign-in, and therefore doesn't attempt to federate sign-in across multiple sites. That's part of the reason that we're not shipping this change today, but proposing it as a (near-)future step.

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.

We're proposing treating cookies as `SameSite=Lax` by default (https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03...). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well.

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

That's done via port-forwarding. That is, Chrome is talking to the loopback interface on a particular port. The server listening at that port forwards the requests across the debugging bridge to the phone, and ferries the response back across in the same way.

It should be unaffected by the suggestion in this document.

Did you just assume IPv4? That's IPist!

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

That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services.

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. :)

Does a page's CSP break your extension in Chrome Canary? We've done quite a bit of work to allow extensions to transparently bypass a page's policy, and I'd much prefer to fix the bugs in Chrome than for you to kill a page's policy via the WebRequest API.

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

The user agent string is, for the moment, remaining exactly the same format. For better or worse, all those crufty bits are currently necessary for compatibility with sites doing a poor job of sniffing out functionality.

Hi Maciej. Sorry if my comments read as though I was implying that you were wrong or bullheaded to choose WebKit2. That wasn't my intention; there are of course good technical arguments for choosing either architecture, and I'll choose my words more carefully next time the question comes up.

My expectation is that we'll be posting more design docs to chromium.org more frequently. The best way to stay on top of that will be to join the blink-dev group (https://groups.google.com/a/chromium.org/forum/?fromgroups#!...) which will be ramping up shortly.

1. Chromium will continue to build via gyp.

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.

Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair.

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. :)

WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.

Safari is using WebKit2, and has been for some time. The "preproduction prototype" bit of that Wiki is a bit out of date.

Also: these sorts of deep technical questions would be great for tomorrow's hangout: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer whatever you can throw at them. Add questions to the Moderator at: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&....

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc.

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.

The two engines will diverge, yes. I think it'll be better for both in the long run, as we simply have fundamentally different architectural approaches to some pretty core problems the engines are meant to solve. There will be short term adjustments on both sides as we get used to the new options that are now available.

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

The Chromium team will be running a Hangout tomorrow to answer any questions that pop up. Hit this Moderator page to ask whatever's on your mind: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&...

Paul Irish has a great article outlining the technical background of this sort of inter-WebKit diversity: http://paulirish.com/2013/webkit-for-developers/

The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means.

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

Blink remains very much open source: the repository should be visible in a minute or three.

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're a bit worried about compatibility, certainly. One important thing to note is that WebKit has _tens of thousands_ of layout tests; all of those tests exist right now in the Blink repository, and we're certainly going to continue working with browser vendors in general and the W3C to ensure that we can agree on exactly what standards mean, and how they should be rendered.

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.

http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.

Chrome 28 will be the first blinking release.