LGTM to extend the deprecation trail M117-M119

On Mon, Jun 26, 2023 at 11:03 AM 'Yifan Luo' via blink-dev <
blink-dev@chromium.org> wrote:

> Hey all,
>
> I would like to clarify that the current deprecation trial ends on M116 so
> that I would like to extend it to M119.
>
> best,
> Yifan
>
> On Thursday, June 22, 2023 at 3:38:15 PM UTC+2 Yifan Luo wrote:
>
>> Contact emailstit...@chromium.org, cl...@chromium.org, mk...@chromium.org
>> , va...@chromium.org, l...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/private-network-access/blob/master/explainer.md
>>
>> Specificationhttps://wicg.github.io/private-network-access
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64
>>
>> Summary
>>
>> Requires that private network requests for subresources from public
>> websites may only be initiated from a secure context. Examples include
>> internet to intranet requests and internet to loopback requests. This is a
>> first step towards fully implementing Private Network Access:
>> https://wicg.github.io/private-network-access/
>>
>>
>> Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572
>>
>> TAG review statusIssues addressed
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> No interoperability risks. Compatibility risk is small but
>> non-negligible. UseCounters show ~0.1% of page visit making use of this
>> feature. Direct outreach to the largest users per UKM data revealed no
>> objections to this launch. Rolling this deprecation out to beta per the
>> previous I2S resulted in more feedback about the compatibility risk and the
>> need for a time extension. See the following doc for an extensive
>> discussion:
>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/143) Tentatively
>> positive, but no formal position yet.
>>
>> *WebKit*: Positive (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)
>>
>> *Web developers*: Mixed signals (
>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit)
>> In our recent survey, most of websites are able to migrate if our new
>> permission prompt can be landed as a way for them to relax mixed content
>> checks.
>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809
>>  ------------
>> Some websites, broadly falling in the category of controller webapps for
>> IoT devices, find this change incompatible with their use cases. While many
>> use cases can be solved with specific workarounds, some still require
>> further engagement.
>>
>> *Other signals*:
>>
>> Activation
>>
>> Developers of non-secure sites that rely upon local servers will need to
>> upgrade to HTTPS. This might cause some complications, as mixed-content
>> checks will begin to apply. Chrome carves out HTTP access to loopback (as
>> perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is
>> a release valve for folks who don't want to go through the effort of
>> securely-distributing certs for local servers. The initial launch in M92
>> was delayed due to compatibility risks surfaced during the rollout to beta.
>> See this doc for a lot more details:
>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
>>
>>
>> Security
>>
>> This change should be security-positive.
>>
>>
>> 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?
>>
>>
>>
>> Debuggability
>>
>> When a request is made that violates this restriction and the feature is
>> not enabled, three things happen: 1. A warning message is logged to the
>> DevTools console. 2. A depreciation report is filed against the initiator
>> website's Reporting API, if so configured. 3. An issue surfaced in the
>> DevTools Issues panel. Likewise, when the feature is enabled and a request
>> is blocked, the same happens except that the message logged to the DevTools
>> console is an error and its text is slightly different. The devtools
>> network panel shows information about the source and remote address spaces
>> at play.
>>
>>
>> *Experiment Extension Reason:*We planned a prototyped permission prompt
>> to relax mixed-content for requests from HTTPS public websites to HTTP
>> local devices. However, we've missed the M116 branch point and now have a
>> prototype on M117 for users to play around. See demo:
>> https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing
>> We request for an extension for this deprecation trial to let users be
>> able to try the new permission prototype in M117 and the OT possibly start
>> from M117/M118.
>> ------
>> We have collected 20+ developers' feedback since the last milestone.
>> 85.7% developers said that they are still migrating to HTTPS, 50% said they
>> need more time and 50% said they are not able to migrate local devices for
>> various reasons and need future help.
>>
>> In the meanwhile, we are also collecting developers' feedback on our
>> future plan for websites that cannot migrate their private devices to HTTPS
>> but would like to migrate their public websites. 11.1% websites answered
>> probably yes to our new feature and 72.2% responded might or might not. The
>> major considers are they also need the allowance on frames/iframes (Q8
>> 64.7%), want to use IP address as ids in permission (Q12 82.3%), too many
>> permission prompt might be a spam (2 answers) and need to wait for other
>> browsers supporting Private Network Access. In this case, we are also
>> actively changing our further plan and collaborating with other browsers at
>> the same time.
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Flag nameBlockInsecurePrivateNetworkRequests
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/986744
>>
>> Launch bughttps://crbug.com/1129801
>>
>> Estimated milestones
>> OriginTrial desktop last 119
>> OriginTrial desktop first 94
>> DevTrial on desktop 86
>> OriginTrial Android last 119
>> OriginTrial Android first 94
>> DevTrial on Android 86
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5436853517811712
>>
>> Links to previous Intent discussionsReady for Trial:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vlDZXlPb00k/m/1421ACiuAAAJ
>> Intent to Extend Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
>> Intent to Ship:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
>>
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>> --
>> Yifan
>>
> --
> 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/853649b1-22c3-419b-9eb6-fe1d8d9867b5n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/853649b1-22c3-419b-9eb6-fe1d8d9867b5n%40chromium.org?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/CAL5BFfWZ5O9voCCak6EME%3Dtkp7224QV16jc08nTu2dLKj-_2Ew%40mail.gmail.com.

Reply via email to