Thanks for getting back to us! On Wed, Oct 12, 2022 at 6:11 PM Daniel Bratell <[email protected]> wrote:
> We (Yoav, Philip, MikeT and I) discussed this at the API OWNERS meeting > today and we are still not certain about the compatibility situation. The > use counters are lower after compensating for likely malicious usage but > they are still not quite as low as we'd like them to be. > > One thing we considered was whether the data you analyzed is > representative for all platforms or whether Android is different in some > way. We don't know. Do you know? If not, could you take a look at the > Desktop data and check that it's the same pattern as for Android? > It's a good question! I'll take a look and see what I can tell from the data. > Another question is the likely impact of a failed request. That is a > question that is much harder to answer, but maybe you have an idea? > In the case of malicious usage, a failed request is a win for user security and privacy! :) Seriously though, typically it means one of two things: a) the core functionality of the page does not work, because its whole purpose was to talk to a private network server, or b) some subresources on the page fail to load because of weirdness around servers with multiple IP addresses (some private, some public) or VPN usage (site used to be public, now is on a private IP). In the case of b), a reload usually fixes the issue. > A third question is whether the situation is likely to improve or worsen > over time. Do you have any insights about that? > Optimistically, the situation should improve as a result of developers noticing the warnings we've been flashing in DevTools for a while. Pessimistically (and unfortunately this has been more our experience so far), the situation will stagnate and/or get worse until the deprecation starts, and people sign up for the deprecation trial. We can always invest some more in classifying uses and reaching out to many small websites, it's simply a tradeoff of time and effort spent trying to get ahead of the issue vs patching the security hole earlier and getting on to fixing other things. Cheers, Titouan > /Daniel > > > On 2022-10-06 12:12, Titouan Rigoudy wrote: > > 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/CAPATO9f0H%2Bu0bQAtCeg4FvF-caQ1hJXfM1h%3DTLRJ6T-ZqgowaA%40mail.gmail.com.
