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 < blink-dev@chromium.org> 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 <bratel...@gmail.com> 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 tito...@chromium.org, v...@chromium.org, >> cl...@chromium.org, l...@chromium.org, p...@chromium.org >> >> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_tmAPq7Wh2B_6KzKWZqh3qi0xeMhjJ%3DQ-eUpRnxppLcw%40mail.gmail.com.
