LGTM1
I especially appreciate the use of a field trial here. If you have new uncertainty or concern, I assume you could easily start with a 1% trial and listen for feedback before ramping up?
I assume the metric indicates that some resource failed, not necessarily the main resource, right? So this doesn't necessarily mean 0.001% of page loads will be completely broken?
Rick
LGTM1
I especially appreciate the use of a field trial here. If you have new uncertainty or concern, I assume you could easily start with a 1% trial and listen for feedback before ramping up?
I assume the metric indicates that some resource failed, not necessarily the main resource, right? So this doesn't necessarily mean 0.001% of page loads will be completely broken?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Thu, Feb 4, 2016 at 8:01 PM Rick Byers <rby...@google.com> wrote:LGTM1
I especially appreciate the use of a field trial here. If you have new uncertainty or concern, I assume you could easily start with a 1% trial and listen for feedback before ramping up?
I was mostly thinking an emergency off switch, but that's certainly another option.
My gut feeling is sharding by population rather than time risks admins not reproducing the problem (or the trial is so small the admin doesn't even notice). But I've no experience to support or counter that. I can certainly try it if the numbers change or something comes up.I assume the metric indicates that some resource failed, not necessarily the main resource, right? So this doesn't necessarily mean 0.001% of page loads will be completely broken?
Yeah, it's out of HTTPS requests rather than page loads. (The metric lives in the net stack which doesn't know about groupings into pages.)
More specifically, it's: for each HTTPS request that ultimately succeeded (we still have the fallback today, so affected requests still go through), it records whether it succeeded normally or if it failed (on a fallback triggering-error) and then succeeded on the subsequent fallback attempt.
Oh, something I forgot to mention: ERR_CONNECTION_CLOSED is a fallback trigger, so some transient network hiccups are indistinguishable from version-intolerant servers. This means metrics have some false-positive noise. I suspect much of that noise is swallowed by how we measure deprecated cipher suites (a different kind of fallback), but it's hard to measure this. But this can only make the true number lower, and I figured 0.001% is pretty low. :-)
On Thu, Feb 4, 2016 at 8:01 PM Rick Byers <rby...@google.com> wrote:LGTM1
I especially appreciate the use of a field trial here. If you have new uncertainty or concern, I assume you could easily start with a 1% trial and listen for feedback before ramping up?
I was mostly thinking an emergency off switch, but that's certainly another option.
My gut feeling is sharding by population rather than time risks admins not reproducing the problem (or the trial is so small the admin doesn't even notice). But I've no experience to support or counter that. I can certainly try it if the numbers change or something comes up.
The way the metric is implemented, it sounds like it doesn't distinguish at all between the top-level resource and sub-resources? If up to 0.001% of page loads are fatally wounded either by the top-level fetch or some necessary sub-resource, that could be a very large number of affected users and servers.
What will this look like for non-Chrome browsers? Will flag for insecure TLS version fallback be off by default until the field trial has concluded and the flag is cleaned out of the source code?
On Fri, Feb 5, 2016 at 8:42 AM Philip Jägenstedt <phi...@opera.com> wrote:The way the metric is implemented, it sounds like it doesn't distinguish at all between the top-level resource and sub-resources? If up to 0.001% of page loads are fatally wounded either by the top-level fetch or some necessary sub-resource, that could be a very large number of affected users and servers.That's true. Though this is all a property of the host, not the full URL (we don't even send the path over the wire until the handshake happens), so it's not every random subresource in a page, just the distinct hosts. I don't recall a problem from decisions based on net-stack vs. page-level metrics before (even when we look at connection-level rather than request-level metrics), and I think the current numbers have quite a lot of wiggle room.
The alternative is a huge amount of effort plumbing all this information up the stack. The low-level parts of the net stack and Blink are quite far apart.What will this look like for non-Chrome browsers? Will flag for insecure TLS version fallback be off by default until the field trial has concluded and the flag is cleaned out of the source code?My intention was for the flag to be a temporary emergency off switch rather than a custom roll-out (the usual release rollout seems fine), so I'm expecting to have the fallback disabled by default, yeah.
Oh... I don't know much about Chrome field trials, is it such that you can flip the flag without making a new release in case disaster strikes? For any Chromium-based browser without an equivalent mechanism, it would be stuck in the storm until an emergency release can be made, it sounds like.Would it be possible to leave the fallback enabled by default and change it once the field trial has proven it web compatible on stable? I realize that this amount to Opera taking not sharing in the risk, but the alternative seems to be taking a much higher risk.
Juniper Networks Firewall has blocked the URL:
10.107.121.80(52371)->50.87.248.174(80) www.cedip.cl
CATEGORY: Enhanced_Search_Engines_and_Portals REASON: BY_SITE_REPUTATION
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/11107fb3-d3dc-45fa-9635-35a048d2b380%40chromium.org.
This is not a technical support group. Seek help elsewhere.
☆Phist
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOemBWgYR8J0qo9EMiSvPEFoHLxOD08qnL1bZ4JCrZphqFSZzQ%40mail.gmail.com.
Primary eng (and PM) emails
Primary eng (and PM) emails
Primary eng (and PM) emails