Thanks - I also don't think there's a lot of value in this particular
header being the odd-one-out, just wanted to confirm we're not going to
ship "true" first and try to change that to ?1 later (which is always
challenging).
On 12/2/21 11:11 AM, Mike West wrote:
I'm not sure it makes sense to introduce a structured header here,
given that it's layering on top of CORS headers that I don't think
there's substantial interest in changing.
-mike
On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via blink-dev
<blink-dev@chromium.org> wrote:
Hi Mike,
There is no support for structured headers so far, for consistency
reasons, and there has been no movement to deprecate the "true"
value for Access-Control-Allow-Credentials. The value of such a
deprecation seems minimal.
I could pretty easily add support for the structured "?1" value on
top of the "true" token for the new
Access-Control-Allow-Private-Network header, and specify that, but
I'm not sure it would be terribly useful. Do you think otherwise?
Cheers,
Titouan
On Thu, Dec 2, 2021 at 4:45 PM Mike Taylor
<miketa...@chromium.org> wrote:
Hi Titouan,
I'm curious what the plan is for structured headers.
https://github.com/WICG/private-network-access/issues/45 is
marked as blocked - has there been other progress or thinking
behind the scenes?
thanks,
Mike
On 11/29/21 10:36 AM, 'Titouan Rigoudy' via blink-dev wrote:
Contact emails
tito...@chromium.org, v...@chromium.org, cl...@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
Pending
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. 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
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.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/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
DevTrial on desktop 98
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
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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%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/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%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/886cabf9-85e0-9095-fd2f-a936db762d83%40chromium.org.
