LGTM2 for step 1.
On 12/6/21 5:31 AM, Titouan Rigoudy wrote:
*assuming I get 2 more LGTMs, that is.
On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy <tito...@google.com>
wrote:
Thanks! I'll come back for further discussion with UKM data in hand.
Cheers,
Titouan
On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss
<yoavwe...@chromium.org> wrote:
I agree UKM analysis should not block step 1, as it holds
little risk. (There's still some risks that servers will choke
in the face of preflights, but that seems minor compared to
the enforcement risk)
Therefore,*LGTM1 for step 1* (preflights with no enforcement),
but not further (yet). Please come back to this thread with
any data you may have as a result of adding UKMs.
On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev
<blink-dev@chromium.org> wrote:
Yoav, do you think UKM analysis should block sending
preflights without enforcing their success? I believe
sending these will allow us to get more precise
information on the affected websites through the
usecounter recorded in crrev.com/c/3310846
<http://crrev.com/c/3310846>. I can then analyze UKM data
and use the results to inform the decision whether and
when to switch enforcement on?
Cheers,
Titouan
On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy
<tito...@google.com> wrote:
I agree!
Cheers,
Titouan
On Thu, Dec 2, 2021 at 5:17 PM Mike West
<mk...@chromium.org> wrote:
_I_ don't think we should do that, but I'd defer
to Titouan's preference. :)
-mike
On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor
<miketa...@chromium.org> wrote:
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/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%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/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org.
