Sure! I went through the UKM data from Android (where we can be reasonably sure that extensions are not messing with the data) and classified a bunch of the top websites. I ended up classifying ~2/3 of the traffic in volume. Out of that, it seemed that ~7% was legitimate. There was no indication that the rest of the traffic would strongly buck that trend, I was just hitting diminishing returns for low usecount websites.
Cheers, Titouan On Wed, Oct 5, 2022 at 6:40 PM Chris Harrelson <[email protected]> wrote: > Thanks Titouan, two of them is definitely enough, no need for three. :) > > Another question: have you done an analysis of how much of the UseCounter > traffic is "illegitimate use"? Two of them are at 0.1% or 0.2%, which is a > risky level. But hopefully the percentage of "legitimate" traffic is a lot > lower? > > Chris > > On Wed, Oct 5, 2022 at 9:37 AM 'Titouan Rigoudy' via blink-dev < > [email protected]> wrote: > >> There are two enterprise policies for this [1]! One for disabling it >> entirely, and one for disabling it per origin. >> >> We have been engaging with the enterprise team since the start of PNA, a >> dozen or so milestones ago. This has been announced repeatedly in >> enterprise release notes over the past several milestones. >> >> Cheers, >> Titouan >> >> [1] >> https://developer.chrome.com/blog/private-network-access-preflight/#disable-with-enterprise-policy >> >> On Wed, Oct 5, 2022 at 6:10 PM Daniel Bratell <[email protected]> >> wrote: >> >>> I'm curious about the enterprise situation here. This seems to me like >>> something that could be in use in enterprise applications, and we would not >>> really know about it. ( >>> https://www.chromium.org/developers/enterprise-changes/ is a good >>> checklist for this) >>> >>> Is there an enterprise policy for this that can be used for those that >>> need the old behaviour, if not, could one be added? >>> >>> Also, have you reached out to the enterprise community? (See link above) >>> >>> /Daniel >>> On 2022-10-05 15:28, Jonathan Hao wrote: >>> >>> Context Since M104, we've started sending preflight requests before >>> private network access, but ignoring the preflight result (or the lack of >>> it). After analyzing the URL-keyed metrics, we found that most of them >>> don't seem legit, most likely used for fingerprinting purposes, so we >>> decided to start enforcing the preflight response, which means that the >>> websites will not be able to fetch subresources from less-public ip address >>> space without getting proper preflight responses. >>> >>> An intent focusing on the deprecation trial was sent earlier in this >>> thread: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer. >>> There, we were suggested to send a separate intent to remove the >>> functionality, and hence this intent email. >>> >>> Contact emails [email protected], [email protected], >>> [email protected], [email protected], [email protected] >>> >>> Explainer >>> https://github.com/WICG/private-network-access/blob/main/explainer.md >>> >>> Specification https://wicg.github.io/private-network-access >>> >>> Design docs >>> >>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit >>> >>> Summary >>> >>> Sends a CORS preflight request ahead of any private network requests for >>> subresources, asking for explicit permission from the target server. A >>> private network request is any request from a public website to a private >>> IP address or localhost, or from a private website (e.g. intranet) to >>> localhost. Sending a preflight request mitigates the risk of cross-site >>> request forgery attacks against private network devices such as routers, >>> which are often not prepared to defend against this threat. >>> >>> >>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> >>> >>> TAG review https://github.com/w3ctag/design-reviews/issues/572 >>> >>> TAG review status Issues addressed >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> The main interoperability risk, as always, is if other browser engines >>> do not implement this. Compat risk is straightforward: web servers that do >>> not handle the new preflight requests will eventually break, once the >>> feature ships. The plan to address this is as follows: 1. Send preflight >>> request, ignore result, always send actual request. Failed preflight >>> requests will result in a warning being shown in devtools. 2. Wait for 3 >>> milestones. 3. Gate actual request on preflight request success, with >>> deprecation trial for developers to buy some more time. 4. End deprecation >>> trial 4 milestones later. UseCounters: >>> https://chromestatus.com/metrics/feature/timeline/popularity/3753 >>> https://chromestatus.com/metrics/feature/timeline/popularity/3755 >>> https://chromestatus.com/metrics/feature/timeline/popularity/3757 The >>> above measure pages that make at least one private network request for >>> which we would now send a preflight request. >>> >>> >>> *Gecko*: Worth prototyping ( >>> https://github.com/mozilla/standards-positions/issues/143) >>> >>> *WebKit*: No signal ( >>> https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) >>> Pending response. >>> >>> *Web developers*: No signals Anecdotal evidence so far suggests that >>> most web developers are OK with this new requirement, though some do not >>> control the target endpoints and would be negatively impacted. >>> >>> *Other signals*: >>> >>> Ergonomics >>> >>> None. >>> >>> >>> Activation >>> >>> Gating access to the private network overnight on preflight requests >>> would likely result in widespread breakage. This is why the plan is to >>> first send requests but not act on their result, giving server developers >>> time to implement code handling these requests. Deprecation warnings will >>> be surfaced in DevTools to alert web/client developers when the potential >>> for breakage later on is detected. Enforcement will be turned on later >>> (aiming for 3 milestones), along with a deprecation trial for impacted web >>> developers to buy themselves some more time. Experience suggests a large >>> fraction of developers will not notice the advance deprecation warnings >>> until things break. >>> >>> >>> Security >>> >>> This change aims to be security-positive, preventing CSRF attacks >>> against soft and juicy targets such as router admin interfaces. It does not >>> cover navigation requests and workers, which are to be addressed in >>> followup launches. DNS rebinding threats were of particular concern during >>> the design of this feature: >>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9 >>> >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> Not going to ship on Android WebView >>> >>> Goals for experimentation Give websites time to make sure they respond >>> to the preflights >>> >>> Reason this experiment is being extended N/A >>> >>> Ongoing technical constraints N/A >>> >>> Debuggability >>> >>> Relevant information (client and resource IP address space) is already >>> piped into the DevTools network panel. Deprecation warnings and errors will >>> be surfaced in the DevTools issues panel explaining the problem when it >>> arises. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? No >>> >>> Not on Android WebView given previous difficulty in supporting PNA >>> changes due to the lack of support for deprecation trials. Support for >>> WebView will be considered separately. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? Yes >>> >>> DevTrial instructions >>> https://github.com/WICG/private-network-access/blob/main/HOWTO.md >>> >>> Flag name PrivateNetworkAccessRespectPreflightResults >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://crbug.com/591068 >>> >>> Launch bug https://crbug.com/1274149 >>> >>> Estimated milestones >>> OriginTrial desktop last 112 >>> OriginTrial desktop first 109 >>> DevTrial on desktop 98 >>> OriginTrial Android last 112 >>> OriginTrial Android first 109 >>> DevTrial on Android 98 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5737414355058688 >>> >>> Links to previous Intent discussions Intent to prototype: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ >>> Intent to Ship: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/72CK2mxD47c >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9dKw30wJL3Aj5OOmYeT5Gxy1Bb7Yf%2B7VFEmAjAEyySFWw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9dKw30wJL3Aj5OOmYeT5Gxy1Bb7Yf%2B7VFEmAjAEyySFWw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9cU34FExUG81_MzeSRn%2BacoZ1bwzmLE2WmTBFEvejeVpQ%40mail.gmail.com.
