*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>.
