Viewing profile — 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…

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 ca…

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-... ). AC…

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 probl…

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/chro…

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 sit…

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 q…

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 debug…

> 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 s…

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 …

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…

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 argu…

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.g…

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 …

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://tr…

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 proc…

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 a…

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 mod…

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…