Exactly! Somewhere in the ballpark of 0.01% is my rough estimate. Cheers, Titouan
On Thu, Oct 6, 2022 at 11:06 AM Yoav Weiss <[email protected]> wrote: > So if the use counters are at 0.1-0.2%, we can expect only 0.007-0.014% to > be legitimate (roughly speaking)? > > On Thu, Oct 6, 2022 at 10:54 AM Titouan Rigoudy <[email protected]> > wrote: > >> 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/CAPATO9fXcX6H8sW%3D4ZDOLzrjqa7sxjd%3DF6mQMNqoHp_YHpsKgg%40mail.gmail.com.
