Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org Explainer https://github.com/WICG/private-network-access/blob/main/explainer.md
Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> Motivation Private network services are often ill-equipped to deal with cross-site request forgery attacks carried out by malicious code running in users' browsers. These attacks have been used to compromise the security of hundreds of thousands of users around the world. Private Network Access proposes to solve this problem by: 1. Requiring that private network requests be initiated by secure contexts. 2. Sending an augmented CORS preflight request before the actual request. Together, this ensures that private network devices must explicitly opt into receiving requests from secure and authenticated public websites. Initial public proposal https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 TAG review statusPending 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 requests, ignore result, always send actual request. 2. Wait for 2 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/3754 https://chromestatus.com/metrics/feature/timeline/popularity/3755 https://chromestatus.com/metrics/feature/timeline/popularity/3756 https://chromestatus.com/metrics/feature/timeline/popularity/3757 https://chromestatus.com/metrics/feature/timeline/popularity/3758 The above measure pages that make at least one private network request for which we would now send a preflight request. Gecko: Under consideration ( https://github.com/mozilla/standards-positions/issues/143) WebKit: No signal Web developers: No signals Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?No Requires code in //chrome?False Tracking bughttps://crbug.com/591068 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5737414355058688 This intent message was generated by Chrome Platform Status <https://www.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/CAPATO9daMzYeoBwOpJq6iprMhrQzyOGHFkoWmVg-yUk%3D_igPVQ%40mail.gmail.com.
