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/CAL5BFfW_X2iz26EBeA0C2%2B-kOt7WN5r7mCuUZ4FGwov1u2oB7g%40mail.gmail.com.
