Contact emailstito...@chromium.org, cl...@chromium.org, mk...@chromium.org, v...@chromium.org, l...@chromium.org
Explainer https://github.com/WICG/private-network-access/blob/master/explainer.md Specificationhttps://wicg.github.io/private-network-access Design docs https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64 Summary Requires that private network requests for subresources from public websites may only be initiated from a secure context. Examples include internet to intranet requests and internet to loopback requests. This is a first step towards fully implementing Private Network Access: https://wicg.github.io/private-network-access/ Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 TAG review statusIssues addressed Link to origin trial feedback summary https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ Risks Interoperability and Compatibility No interoperability risks. Compatibility risk is small but non-negligible. UseCounters show ~0.1% of page visit making use of this feature. Direct outreach to the largest users per UKM data revealed no objections to this launch. Rolling this deprecation out to beta per the previous I2S resulted in more feedback about the compatibility risk and the need for a time extension. See the following doc for an extensive discussion: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/143) Tentatively positive, but no formal position yet. *WebKit*: Positive ( https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html) *Web developers*: Mixed signals ( https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) In our recent survey, most of websites are able to migrate if our new permission prompt can be landed as a way for them to relax mixed content checks. https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 ------------ Some websites, broadly falling in the category of controller webapps for IoT devices, find this change incompatible with their use cases. While many use cases can be solved with specific workarounds, some still require further engagement. *Other signals*: Activation Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. The initial launch in M92 was delayed due to compatibility risks surfaced during the rollout to beta. See this doc for a lot more details: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit Security This change should be security-positive. 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? Debuggability When a request is made that violates this restriction and the feature is not enabled, three things happen: 1. A warning message is logged to the DevTools console. 2. A depreciation report is filed against the initiator website's Reporting API, if so configured. 3. An issue surfaced in the DevTools Issues panel. Likewise, when the feature is enabled and a request is blocked, the same happens except that the message logged to the DevTools console is an error and its text is slightly different. The devtools network panel shows information about the source and remote address spaces at play. *Experiment Extension Reason:*We planned a prototyped permission prompt to relax mixed-content for requests from HTTPS public websites to HTTP local devices. However, we've missed the M116 branch point and now have a prototype on M117 for users to play around. See demo: https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing We request for an extension for this deprecation trial to let users be able to try the new permission prototype in M117 and the OT possibly start from M117/M118. ------ We have collected 20+ developers' feedback since the last milestone. 85.7% developers said that they are still migrating to HTTPS, 50% said they need more time and 50% said they are not able to migrate local devices for various reasons and need future help. In the meanwhile, we are also collecting developers' feedback on our future plan for websites that cannot migrate their private devices to HTTPS but would like to migrate their public websites. 11.1% websites answered probably yes to our new feature and 72.2% responded might or might not. The major considers are they also need the allowance on frames/iframes (Q8 64.7%), want to use IP address as ids in permission (Q12 82.3%), too many permission prompt might be a spam (2 answers) and need to wait for other browsers supporting Private Network Access. In this case, we are also actively changing our further plan and collaborating with other browsers at the same time. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes Flag nameBlockInsecurePrivateNetworkRequests Requires code in //chrome?False Tracking bughttps://crbug.com/986744 Launch bughttps://crbug.com/1129801 Estimated milestones OriginTrial desktop last 119 OriginTrial desktop first 94 DevTrial on desktop 86 OriginTrial Android last 119 OriginTrial Android first 94 DevTrial on Android 86 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5436853517811712 Links to previous Intent discussionsReady for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/vlDZXlPb00k/m/1421ACiuAAAJ Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- Yifan -- 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/CAG-zKU8K--EEPj%3DsPAi02pjxmMRCQGd6BmBu%3DAqPd9MnTcwKkg%40mail.gmail.com.
