mikewest

7 ms·

1.
by mikewest 6y ago
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) examini
2.
by mikewest 6y ago
That's an open question ( https://wicg.github.io/cors-rfc1918/#issue-207ba0b9 ). Feedback welcome!
3.
by mikewest 6y ago
Correct. https://wicg.github.io/cors-rfc1918/#dns-rebinding describes this reasoning.
4.
by mikewest 6y ago
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 explic
5.
by mikewest 6y ago
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 mak
6.
by mikewest 6y ago
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 p
7.
by mikewest 7y ago
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/chromiu
8.
by mikewest 7y ago
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&#x
9.
by mikewest 7y ago
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 `SameSit
10.
by mikewest 10y ago
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
11.
by mikewest 10y ago
> 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'." :)
12.
by mikewest 10y ago
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
13.
Scriptless attacks: CSSConfEU presentation on cross-site styling.(mikewest.org)
1 points by mikewest 13y ago|0 comments
14.
Solid improvements to 'window.onerror' in Blink.(mikewest.org)
2 points by mikewest 13y ago|0 comments
15.
by mikewest 13y ago
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
16.
by mikewest 13y ago
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.
17.
by mikewest 13y ago
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
18.
by mikewest 13y ago
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
19.
by mikewest 13y ago
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:/
20.
by mikewest 13y ago
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 o
21.
by mikewest 13y 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 "Garden
22.
by mikewest 13y ago
Safari is using WebKit2, and has been for some time. The "preproduction prototype" bit of that Wiki is a bit out of date.
23.
by mikewest 13y ago
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 whateve
24.
by mikewest 13y ago
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 th
25.
by mikewest 13y ago
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 ad
26.
by mikewest 13y ago
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
27.
by mikewest 13y ago
Paul Irish has a great article outlining the technical background of this sort of inter-WebKit diversity: http://paulirish.com/2013/webkit-for-developers/
28.
by mikewest 13y ago
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
29.
by mikewest 13y ago
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#n
30.
by mikewest 13y ago
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 workin

More ›