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+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--kouhei
Also, do you have data on how many page views have "X-XSS-Protection: 0"? That can be a good measure of how much the current thing is worked around.
On Tue, Oct 11, 2016 at 7:58 PM Rick Byers <rby...@chromium.org> wrote:Do you have any stats on how often we'd be blocking loads (either UMA or via some crawl)?
It would be nice to put an upper bound on the possible breakage. I agree that it's generally going to be better to block the page load than filter the script. But if, for example, there was some popular analytics library that was getting blocked on many sites without any user-visible breakage, then we might need to do some outreach in advance of breaking all those sites. If there's data indicating this is very rare, then I'm happy proceeding without any further compat analysis.
In other words, put this on hold for a bit until more data is available?
Just as a note, Google enables the behavior Mike is talking about (mode=block) at the framework level and we've been setting it for almost all our applications for many years. We've also been hit by IE-specific XSS-es in a few places where we forgot to enable blocking mode and the default filtering behavior kicked in.It seems like a good idea to go forward with this.On Thu, Oct 13, 2016 at 9:18 AM, Mike West <mk...@chromium.org> wrote:On Wed, Oct 12, 2016 at 4:30 PM, Philip Jägenstedt <foo...@chromium.org> wrote:In other words, put this on hold for a bit until more data is available?If it makes you more comfortable to wait for the metrics to hit stable, sure.
That said, the XSS metrics are in the latest dev build, so let me give you a little more data from the last 7 days on that channel:* We filtered reflected script 2,617 times.
* We blocked the entire page 16 times.* ~2.1% of page views turned the auditor off.* ~0.04% of page views turned the auditor on in filter mode (~no-op).* ~4.8% of page views turned the auditor on in block mode.* ~0.009% of page views had an invalid header value.Rick, one note: the data from the hot new metric (https://crbug.com/597963) is radically different. According to that metric:
On Thu, Oct 13, 2016 at 10:39 AM, Artur Janc <a...@google.com> wrote:Just as a note, Google enables the behavior Mike is talking about (mode=block) at the framework level and we've been setting it for almost all our applications for many years. We've also been hit by IE-specific XSS-es in a few places where we forgot to enable blocking mode and the default filtering behavior kicked in.It seems like a good idea to go forward with this.On Thu, Oct 13, 2016 at 9:18 AM, Mike West <mk...@chromium.org> wrote:On Wed, Oct 12, 2016 at 4:30 PM, Philip Jägenstedt <foo...@chromium.org> wrote:In other words, put this on hold for a bit until more data is available?If it makes you more comfortable to wait for the metrics to hit stable, sure.If the metrics from dev channel suggest the compat risk is low, I'm fine making tentative decisions based on that (and just double-checking once we have beta or stable metrics that it's not radically different).
That said, the XSS metrics are in the latest dev build, so let me give you a little more data from the last 7 days on that channel:* We filtered reflected script 2,617 times.So for the compat risk of the proposed change, it's primarily this value that matters, right? Virtually all of these will be turned into blocking the entire page. Is this a FeatureObserver bucket or some other histogram? Just trying to put the number in context (eg. as % of PageVisits).
What kinds of pages are typically blocked? Out of that small number, can you make any guess as to how many will translate to sad users?On Thu, Oct 13, 2016 at 5:16 PM 'Mike West' via blink-dev <blin...@chromium.org> wrote:On Thu, Oct 13, 2016 at 5:08 PM, Rick Byers <rby...@chromium.org> wrote:On Thu, Oct 13, 2016 at 10:39 AM, Artur Janc <a...@google.com> wrote:Just as a note, Google enables the behavior Mike is talking about (mode=block) at the framework level and we've been setting it for almost all our applications for many years. We've also been hit by IE-specific XSS-es in a few places where we forgot to enable blocking mode and the default filtering behavior kicked in.It seems like a good idea to go forward with this.On Thu, Oct 13, 2016 at 9:18 AM, Mike West <mk...@chromium.org> wrote:On Wed, Oct 12, 2016 at 4:30 PM, Philip Jägenstedt <foo...@chromium.org> wrote:In other words, put this on hold for a bit until more data is available?If it makes you more comfortable to wait for the metrics to hit stable, sure.If the metrics from dev channel suggest the compat risk is low, I'm fine making tentative decisions based on that (and just double-checking once we have beta or stable metrics that it's not radically different).SGTM.That said, the XSS metrics are in the latest dev build, so let me give you a little more data from the last 7 days on that channel:* We filtered reflected script 2,617 times.So for the compat risk of the proposed change, it's primarily this value that matters, right? Virtually all of these will be turned into blocking the entire page. Is this a FeatureObserver bucket or some other histogram? Just trying to put the number in context (eg. as % of PageVisits).This is `UseCounter::XSSAuditorBlockedScript`. It turns into something like 0.0003% of page views in the old metric, and 0.0007% in the new metric that I'm not worrying about until later. :)
On Thu, Oct 13, 2016 at 11:40 AM, Philip Jägenstedt <foo...@chromium.org> wrote:What kinds of pages are typically blocked? Out of that small number, can you make any guess as to how many will translate to sad users?
This is `UseCounter::XSSAuditorBlockedScript`. It turns into something like 0.0003% of page views in the old metric, and 0.0007% in the new metric that I'm not worrying about until later. :)Ah, perfect - thanks. This is exactly what I was looking for - a reasonably low bound on the compat risk.When a page is blocked I assume developers will see an error (at least when reproducing with the inspector open) which they can search on to get advice like this showing how to disable the XSS auditor, right? Any doc / guidance updates you think we need to take this change into account? We may want to mention this in Joe's "deprecations and removes for Chrome 56" articles.
Given these three properties, I'm now convinced that we've done the necessary due diligence to mitigate the compat risk. LGTM1 to ship.
Given these three properties, I'm now convinced that we've done the necessary due diligence to mitigate the compat risk. LGTM1 to ship.LGTM2, I think, since Jochen already LGTM1'd? Thanks!