Exactly! Somewhere in the ballpark of 0.01% is my rough estimate.
Cheers,
Titouan
On Thu, Oct 6, 2022 at 11:06 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
So if the use counters are at 0.1-0.2%, we can expect only
0.007-0.014% to be legitimate (roughly speaking)?
On Thu, Oct 6, 2022 at 10:54 AM Titouan Rigoudy
<tito...@google.com> wrote:
Sure! I went through the UKM data from Android (where we can
be reasonably sure that extensions are not messing with the
data) and classified a bunch of the top websites. I ended up
classifying ~2/3 of the traffic in volume. Out of that, it
seemed that ~7% was legitimate. There was no indication that
the rest of the traffic would strongly buck that trend, I was
just hitting diminishing returns for low usecount websites.
Cheers,
Titouan
On Wed, Oct 5, 2022 at 6:40 PM Chris Harrelson
<chris...@chromium.org> wrote:
Thanks Titouan, two of them is definitely enough, no need
for three. :)
Another question: have you done an analysis of how much of
the UseCounter traffic is "illegitimate use"? Two of them
are at 0.1% or 0.2%, which is a risky level. But hopefully
the percentage of "legitimate" traffic is a lot lower?
Chris
On Wed, Oct 5, 2022 at 9:37 AM 'Titouan Rigoudy' via
blink-dev <blink-dev@chromium.org> wrote:
There are two enterprise policies for this [1]! One
for disabling it entirely, and one for disabling it
per origin.
We have been engaging with the enterprise team since
the start of PNA, a dozen or so milestones ago. This
has been announced repeatedly in enterprise release
notes over the past several milestones.
Cheers,
Titouan
[1]
https://developer.chrome.com/blog/private-network-access-preflight/#disable-with-enterprise-policy
On Wed, Oct 5, 2022 at 6:10 PM Daniel Bratell
<bratel...@gmail.com> wrote:
I'm curious about the enterprise situation here.
This seems to me like something that could be in
use in enterprise applications, and we would not
really know about it. (
https://www.chromium.org/developers/enterprise-changes/
is a good checklist for this)
Is there an enterprise policy for this that can be
used for those that need the old behaviour, if
not, could one be added?
Also, have you reached out to the enterprise
community? (See link above)
/Daniel
On 2022-10-05 15:28, Jonathan Hao wrote:
Context
Since M104, we've started sending
preflight requests before private network
access, but ignoring the preflight result
(or the lack of it). After analyzing the
URL-keyed metrics, we found that most of
them don't seem legit, most likely used
for fingerprinting purposes, so we
decided to start enforcing the preflight
response, which means that the websites
will not be able to fetch subresources
from less-public ip address space without
getting proper preflight responses.
An intent focusing on the deprecation trial was
sent earlier in this thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer
<https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer>.
There, we were suggested to send a separate
intent to remove the functionality, and hence
this intent email.
Contact emails
tito...@chromium.org, v...@chromium.org,
cl...@chromium.org, l...@chromium.org,
p...@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
Issues addressed
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. It does not cover navigation
requests and workers, which are to be
addressed in followup launches. 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
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?
Not going to ship on Android WebView
Goals for experimentation
Give websites time to make sure they
respond to the preflights
Reason this experiment is being extended
N/A
Ongoing technical constraints
N/A
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.
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
No
Not on Android WebView given previous
difficulty in supporting PNA changes due
to the lack of support for deprecation
trials. Support for WebView will be
considered separately.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/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
OriginTrial desktop last 112
OriginTrial desktop first 109
DevTrial on desktop 98
OriginTrial Android last 112
OriginTrial Android first 109
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
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/72CK2mxD47c
This intent message was generated by
Chrome Platform Status
<https://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/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%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/CAPATO9dKw30wJL3Aj5OOmYeT5Gxy1Bb7Yf%2B7VFEmAjAEyySFWw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9dKw30wJL3Aj5OOmYeT5Gxy1Bb7Yf%2B7VFEmAjAEyySFWw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
