Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Paweł Badeński]

Do I understand correctly that access to access to private network 
endpoints from secure contexts (https) is currently not in scope? That's my 
interpretation of 
https://developer.chrome.com/blog/private-network-access-update/#cors-preflight-requests
 
which is in "Plans for the future" section. Is there any more clarity of 
the timeline?

On Tuesday, 16 May 2023 at 13:49:39 UTC+1 Titouan Rigoudy wrote:

> [blink-dev@ to bcc]
>
> Hi Scott,
>
> I'll reply off list.
>
> Cheers,
> Titouan
>
> On Mon, May 15, 2023 at 2:53 PM Scott Weber  wrote:
>
>> Titouan,  et.al.
>>
>> Is this still awaiting more feedback, and/or another intent to ship?
>>
>> This post:  
>> https://developer.chrome.com/blog/private-network-access-update/ was 
>> brought to my attention by our marketing department, but appears to be 
>> concerned with mixed content.  (I do not expect our market department to be 
>> tech-savy enough to understand the difference)
>>
>> But that update does mention that RFC1918 also addresses 
>> *"websites now have to explicitly request a grant from servers on private 
>> networks before being allowed to send arbitrary requests."*
>> which would also include this topic.
>>
>> Mixed content won't be an issue our company, but preflight will.
>>
>> Since we have a large installation of devices already out in the wild, 
>> our support and marketing team are watching carefully to see if 'preflight' 
>> becomes implemented.  Because it will generate breakage at a level of a 
>> hundred thousand or more, resulting in companies having to re-certify 
>> firmware before deploying it (a process that can take up to 9 months).
>>
>> And since I'm still trying to learn how to filter all the groups emails, 
>> I'm not sure I understand that I will see when preflight is ready for the 
>> next phase.
>>
>> So that is why I ask :-)
>>
>> Thanks.
>>
>>
>> On Tuesday, April 25, 2023 at 10:01:46 AM UTC-5 Scott Weber wrote:
>>
>>> Titouan, 
>>> Excellent.  
>>> Since I am now subscribed to this blog, I will be aware of these 
>>> changes. ( although google SSO used my personal email, not my employer)
>>>
>>> I was (and still am) cautious about getting ALL the changes, since I'm 
>>> sure there are hundreds.  And our little embedded web server doesn't have 
>>> to be concerned with most of them...  but that's off topic :-)
>>>
>>>  Thanks for the details in my other, off topic, questions as well.
>>>
>>> -Scott 
>>> On Tuesday, April 25, 2023 at 7:59:35 AM UTC-5 Titouan Rigoudy wrote:
>>>
 [blink-dev@ to bcc]

 Hi Scott,

 Thanks for reaching out. Answers inline below.

 On Mon, Apr 24, 2023 at 9:32 PM Scott Weber  wrote:

> Grammar correction, sorry:
> "a brief tutorial to a newbie on *the status of* PNA and..."
>
> On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:
>
>> Forgive me if this is not the correct place to ask... 
>> I seem to have stumbled across this conversation trying to find 
>> answers (this thread looks like an email archive chain).
>> I am new to this platform of getting early information about upcoming 
>> changes.
>>
>> Originally, PNA was supposed to "go live" in Version 113.  When I 
>> heard about it back in Nov '22, we tested it in Chrome v104 and placed 
>> support in our firmware back then.
>>
>> So, is this now what could be called "on hold" ? 
>>
>
 The timeline has been paused, but work has not. We are 
 currently working on reducing the compatibility impact of the change, i.e. 
 the amount of websites that would be broken by it. Were we to enforce that 
 PNA preflights must succeed tomorrow, too many existing websites would 
 experience issues.
  

> (while we updated our firmware, there is no assurance the 1000's and 
>> 1000's of devices in the wild are being updated in a timely manner)
>>
>> On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:
>>
>> Just wanted to state here that we'll send a different intent to ship 
>>
>>
>> What is "intent to ship" ?   And what is meant my "send"?  Send to 
>> who?  Is there a mailing list?
>>
>
 This email thread is entitled "Intent to ship". I sent it to this 
 mailing list (blin...@chromium.org) to announce that we were planning 
 to change Chromium's web-facing behavior, and to get approval for this 
 change.

 See this blog post for an in-depth explanation of Chromium's launch 
 process: 
 https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html
  

> Titouan and others mention things like M100, M101.  Is this the same 
>> designation as version number (v104, and v113).
>>
>
 That's right. M stands for milestone.
  

> In summary, my supervisor is asking me to find out if we need to be 
>> ready to tell a plethora of customers they have to upgrade our fi

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

[blink-dev@ to bcc]

Hi Scott,

I'll reply off list.

Cheers,
Titouan

On Mon, May 15, 2023 at 2:53 PM Scott Weber  wrote:

> Titouan,  et.al.
>
> Is this still awaiting more feedback, and/or another intent to ship?
>
> This post:
> https://developer.chrome.com/blog/private-network-access-update/ was
> brought to my attention by our marketing department, but appears to be
> concerned with mixed content.  (I do not expect our market department to be
> tech-savy enough to understand the difference)
>
> But that update does mention that RFC1918 also addresses
> *"websites now have to explicitly request a grant from servers on private
> networks before being allowed to send arbitrary requests."*
> which would also include this topic.
>
> Mixed content won't be an issue our company, but preflight will.
>
> Since we have a large installation of devices already out in the wild, our
> support and marketing team are watching carefully to see if 'preflight'
> becomes implemented.  Because it will generate breakage at a level of a
> hundred thousand or more, resulting in companies having to re-certify
> firmware before deploying it (a process that can take up to 9 months).
>
> And since I'm still trying to learn how to filter all the groups emails,
> I'm not sure I understand that I will see when preflight is ready for the
> next phase.
>
> So that is why I ask :-)
>
> Thanks.
>
>
> On Tuesday, April 25, 2023 at 10:01:46 AM UTC-5 Scott Weber wrote:
>
>> Titouan,
>> Excellent.
>> Since I am now subscribed to this blog, I will be aware of these changes.
>> ( although google SSO used my personal email, not my employer)
>>
>> I was (and still am) cautious about getting ALL the changes, since I'm
>> sure there are hundreds.  And our little embedded web server doesn't have
>> to be concerned with most of them...  but that's off topic :-)
>>
>>  Thanks for the details in my other, off topic, questions as well.
>>
>> -Scott
>> On Tuesday, April 25, 2023 at 7:59:35 AM UTC-5 Titouan Rigoudy wrote:
>>
>>> [blink-dev@ to bcc]
>>>
>>> Hi Scott,
>>>
>>> Thanks for reaching out. Answers inline below.
>>>
>>> On Mon, Apr 24, 2023 at 9:32 PM Scott Weber  wrote:
>>>
 Grammar correction, sorry:
 "a brief tutorial to a newbie on *the status of* PNA and..."

 On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:

> Forgive me if this is not the correct place to ask...
> I seem to have stumbled across this conversation trying to find
> answers (this thread looks like an email archive chain).
> I am new to this platform of getting early information about upcoming
> changes.
>
> Originally, PNA was supposed to "go live" in Version 113.  When I
> heard about it back in Nov '22, we tested it in Chrome v104 and placed
> support in our firmware back then.
>
> So, is this now what could be called "on hold" ?
>

>>> The timeline has been paused, but work has not. We are currently working
>>> on reducing the compatibility impact of the change, i.e. the amount of
>>> websites that would be broken by it. Were we to enforce that PNA preflights
>>> must succeed tomorrow, too many existing websites would experience issues.
>>>
>>>
 (while we updated our firmware, there is no assurance the 1000's and
> 1000's of devices in the wild are being updated in a timely manner)
>
> On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:
>
> Just wanted to state here that we'll send a different intent to ship
>
>
> What is "intent to ship" ?   And what is meant my "send"?  Send to
> who?  Is there a mailing list?
>

>>> This email thread is entitled "Intent to ship". I sent it to this
>>> mailing list (blin...@chromium.org) to announce that we were planning
>>> to change Chromium's web-facing behavior, and to get approval for this
>>> change.
>>>
>>> See this blog post for an in-depth explanation of Chromium's launch
>>> process:
>>> https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html
>>>
>>>
 Titouan and others mention things like M100, M101.  Is this the same
> designation as version number (v104, and v113).
>

>>> That's right. M stands for milestone.
>>>
>>>
 In summary, my supervisor is asking me to find out if we need to be
> ready to tell a plethora of customers they have to upgrade our firmware
> when it stops working in the next day or two  (or have doc ready telling
> them how to disable this requirement).
>
> Please, could someone give a brief tutorial to a newbie on PNA and how
> to be "in the loop" on these things?
>

>>> My previous email was trying to clarify that there will be no further
>>> changes to PNA preflights without a new Intent to Ship thread and
>>> associated chromestatus.com feature. Nothing will change in 113, and
>>> there is no emergency for you to jump on right now. You can stay in the
>>> loop either by looking a

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Scott Weber]

Titouan,  et.al.

Is this still awaiting more feedback, and/or another intent to ship?

This 
post:  https://developer.chrome.com/blog/private-network-access-update/ was 
brought to my attention by our marketing department, but appears to be 
concerned with mixed content.  (I do not expect our market department to be 
tech-savy enough to understand the difference)

But that update does mention that RFC1918 also addresses 
*"websites now have to explicitly request a grant from servers on private 
networks before being allowed to send arbitrary requests."*
which would also include this topic.

Mixed content won't be an issue our company, but preflight will.

Since we have a large installation of devices already out in the wild, our 
support and marketing team are watching carefully to see if 'preflight' 
becomes implemented.  Because it will generate breakage at a level of a 
hundred thousand or more, resulting in companies having to re-certify 
firmware before deploying it (a process that can take up to 9 months).

And since I'm still trying to learn how to filter all the groups emails, 
I'm not sure I understand that I will see when preflight is ready for the 
next phase.

So that is why I ask :-)

Thanks.


On Tuesday, April 25, 2023 at 10:01:46 AM UTC-5 Scott Weber wrote:

> Titouan, 
> Excellent.  
> Since I am now subscribed to this blog, I will be aware of these changes. 
> ( although google SSO used my personal email, not my employer)
>
> I was (and still am) cautious about getting ALL the changes, since I'm 
> sure there are hundreds.  And our little embedded web server doesn't have 
> to be concerned with most of them...  but that's off topic :-)
>
>  Thanks for the details in my other, off topic, questions as well.
>
> -Scott 
> On Tuesday, April 25, 2023 at 7:59:35 AM UTC-5 Titouan Rigoudy wrote:
>
>> [blink-dev@ to bcc]
>>
>> Hi Scott,
>>
>> Thanks for reaching out. Answers inline below.
>>
>> On Mon, Apr 24, 2023 at 9:32 PM Scott Weber  wrote:
>>
>>> Grammar correction, sorry:
>>> "a brief tutorial to a newbie on *the status of* PNA and..."
>>>
>>> On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:
>>>
 Forgive me if this is not the correct place to ask... 
 I seem to have stumbled across this conversation trying to find answers 
 (this thread looks like an email archive chain).
 I am new to this platform of getting early information about upcoming 
 changes.

 Originally, PNA was supposed to "go live" in Version 113.  When I heard 
 about it back in Nov '22, we tested it in Chrome v104 and placed support 
 in 
 our firmware back then.

 So, is this now what could be called "on hold" ? 

>>>
>> The timeline has been paused, but work has not. We are currently working 
>> on reducing the compatibility impact of the change, i.e. the amount of 
>> websites that would be broken by it. Were we to enforce that PNA preflights 
>> must succeed tomorrow, too many existing websites would experience issues.
>>  
>>
>>> (while we updated our firmware, there is no assurance the 1000's and 
 1000's of devices in the wild are being updated in a timely manner)

 On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:

 Just wanted to state here that we'll send a different intent to ship 


 What is "intent to ship" ?   And what is meant my "send"?  Send to 
 who?  Is there a mailing list?

>>>
>> This email thread is entitled "Intent to ship". I sent it to this mailing 
>> list (blin...@chromium.org) to announce that we were planning to change 
>> Chromium's web-facing behavior, and to get approval for this change.
>>
>> See this blog post for an in-depth explanation of Chromium's launch 
>> process: 
>> https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html
>>  
>>
>>> Titouan and others mention things like M100, M101.  Is this the same 
 designation as version number (v104, and v113).

>>>
>> That's right. M stands for milestone.
>>  
>>
>>> In summary, my supervisor is asking me to find out if we need to be 
 ready to tell a plethora of customers they have to upgrade our firmware 
 when it stops working in the next day or two  (or have doc ready telling 
 them how to disable this requirement).

 Please, could someone give a brief tutorial to a newbie on PNA and how 
 to be "in the loop" on these things?

>>>
>> My previous email was trying to clarify that there will be no further 
>> changes to PNA preflights without a new Intent to Ship thread and 
>> associated chromestatus.com feature. Nothing will change in 113, and 
>> there is no emergency for you to jump on right now. You can stay in the 
>> loop either by looking at chromestatus.com or by following along on this 
>> mailing list (blin...@chromium.org).
>>
>> Cheers,
>> Titouan
>>  
>>
>>> Thanks.



-- 
You received this message because you are subscribed to the Google

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Scott Weber]

Titouan, 
Excellent.  
Since I am now subscribed to this blog, I will be aware of these changes. ( 
although google SSO used my personal email, not my employer)

I was (and still am) cautious about getting ALL the changes, since I'm sure 
there are hundreds.  And our little embedded web server doesn't have to be 
concerned with most of them...  but that's off topic :-)

 Thanks for the details in my other, off topic, questions as well.

-Scott 
On Tuesday, April 25, 2023 at 7:59:35 AM UTC-5 Titouan Rigoudy wrote:

> [blink-dev@ to bcc]
>
> Hi Scott,
>
> Thanks for reaching out. Answers inline below.
>
> On Mon, Apr 24, 2023 at 9:32 PM Scott Weber  wrote:
>
>> Grammar correction, sorry:
>> "a brief tutorial to a newbie on *the status of* PNA and..."
>>
>> On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:
>>
>>> Forgive me if this is not the correct place to ask... 
>>> I seem to have stumbled across this conversation trying to find answers 
>>> (this thread looks like an email archive chain).
>>> I am new to this platform of getting early information about upcoming 
>>> changes.
>>>
>>> Originally, PNA was supposed to "go live" in Version 113.  When I heard 
>>> about it back in Nov '22, we tested it in Chrome v104 and placed support in 
>>> our firmware back then.
>>>
>>> So, is this now what could be called "on hold" ? 
>>>
>>
> The timeline has been paused, but work has not. We are currently working 
> on reducing the compatibility impact of the change, i.e. the amount of 
> websites that would be broken by it. Were we to enforce that PNA preflights 
> must succeed tomorrow, too many existing websites would experience issues.
>  
>
>> (while we updated our firmware, there is no assurance the 1000's and 
>>> 1000's of devices in the wild are being updated in a timely manner)
>>>
>>> On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:
>>>
>>> Just wanted to state here that we'll send a different intent to ship 
>>>
>>>
>>> What is "intent to ship" ?   And what is meant my "send"?  Send to who?  
>>> Is there a mailing list?
>>>
>>
> This email thread is entitled "Intent to ship". I sent it to this mailing 
> list (blin...@chromium.org) to announce that we were planning to change 
> Chromium's web-facing behavior, and to get approval for this change.
>
> See this blog post for an in-depth explanation of Chromium's launch 
> process: 
> https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html
>  
>
>> Titouan and others mention things like M100, M101.  Is this the same 
>>> designation as version number (v104, and v113).
>>>
>>
> That's right. M stands for milestone.
>  
>
>> In summary, my supervisor is asking me to find out if we need to be ready 
>>> to tell a plethora of customers they have to upgrade our firmware when it 
>>> stops working in the next day or two  (or have doc ready telling them how 
>>> to disable this requirement).
>>>
>>> Please, could someone give a brief tutorial to a newbie on PNA and how 
>>> to be "in the loop" on these things?
>>>
>>
> My previous email was trying to clarify that there will be no further 
> changes to PNA preflights without a new Intent to Ship thread and 
> associated chromestatus.com feature. Nothing will change in 113, and 
> there is no emergency for you to jump on right now. You can stay in the 
> loop either by looking at chromestatus.com or by following along on this 
> mailing list (blin...@chromium.org).
>
> Cheers,
> Titouan
>  
>
>> Thanks.
>>>
>>>

-- 
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/c8f6bd36-f2a7-48a9-9e0e-75e9a5a11cd3n%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

[blink-dev@ to bcc]

Hi Scott,

Thanks for reaching out. Answers inline below.

On Mon, Apr 24, 2023 at 9:32 PM Scott Weber  wrote:

> Grammar correction, sorry:
> "a brief tutorial to a newbie on *the status of* PNA and..."
>
> On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:
>
>> Forgive me if this is not the correct place to ask...
>> I seem to have stumbled across this conversation trying to find answers
>> (this thread looks like an email archive chain).
>> I am new to this platform of getting early information about upcoming
>> changes.
>>
>> Originally, PNA was supposed to "go live" in Version 113.  When I heard
>> about it back in Nov '22, we tested it in Chrome v104 and placed support in
>> our firmware back then.
>>
>> So, is this now what could be called "on hold" ?
>>
>
The timeline has been paused, but work has not. We are currently working on
reducing the compatibility impact of the change, i.e. the amount of
websites that would be broken by it. Were we to enforce that PNA preflights
must succeed tomorrow, too many existing websites would experience issues.


> (while we updated our firmware, there is no assurance the 1000's and
>> 1000's of devices in the wild are being updated in a timely manner)
>>
>> On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:
>>
>> Just wanted to state here that we'll send a different intent to ship
>>
>>
>> What is "intent to ship" ?   And what is meant my "send"?  Send to who?
>> Is there a mailing list?
>>
>
This email thread is entitled "Intent to ship". I sent it to this mailing
list (blink-dev@chromium.org) to announce that we were planning to change
Chromium's web-facing behavior, and to get approval for this change.

See this blog post for an in-depth explanation of Chromium's launch
process:
https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html


> Titouan and others mention things like M100, M101.  Is this the same
>> designation as version number (v104, and v113).
>>
>
That's right. M stands for milestone.


> In summary, my supervisor is asking me to find out if we need to be ready
>> to tell a plethora of customers they have to upgrade our firmware when it
>> stops working in the next day or two  (or have doc ready telling them how
>> to disable this requirement).
>>
>> Please, could someone give a brief tutorial to a newbie on PNA and how to
>> be "in the loop" on these things?
>>
>
My previous email was trying to clarify that there will be no further
changes to PNA preflights without a new Intent to Ship thread and
associated chromestatus.com feature. Nothing will change in 113, and there
is no emergency for you to jump on right now. You can stay in the loop
either by looking at chromestatus.com or by following along on this mailing
list (blink-dev@chromium.org).

Cheers,
Titouan


> Thanks.
>>
>>

-- 
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/CAPATO9eJpJvcvwuqGv-sHuLJ_0Cf%2B7pj3-9AYGiKV8Qyu5L5MA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Scott Weber]

Grammar correction, sorry:
"a brief tutorial to a newbie on *the status of* PNA and..."

On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:

> Forgive me if this is not the correct place to ask... 
> I seem to have stumbled across this conversation trying to find answers 
> (this thread looks like an email archive chain).
> I am new to this platform of getting early information about upcoming 
> changes.
>
> Originally, PNA was supposed to "go live" in Version 113.  When I heard 
> about it back in Nov '22, we tested it in Chrome v104 and placed support in 
> our firmware back then.
>
> So, is this now what could be called "on hold" ? 
> (while we updated our firmware, there is no assurance the 1000's and 
> 1000's of devices in the wild are being updated in a timely manner)
>
> On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:
>
> Just wanted to state here that we'll send a different intent to ship 
>
>
> What is "intent to ship" ?   And what is meant my "send"?  Send to who?  
> Is there a mailing list?
>
> Titouan and others mention things like M100, M101.  Is this the same 
> designation as version number (v104, and v113).
>
> In summary, my supervisor is asking me to find out if we need to be ready 
> to tell a plethora of customers they have to upgrade our firmware when it 
> stops working in the next day or two  (or have doc ready telling them how 
> to disable this requirement).
>
> Please, could someone give a brief tutorial to a newbie on PNA and how to 
> be "in the loop" on these things?
>
> Thanks.
>
>

-- 
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/384e16c8-52b6-4040-86a6-b30f7296cd81n%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Scott Weber]

Forgive me if this is not the correct place to ask... 
I seem to have stumbled across this conversation trying to find answers 
(this thread looks like an email archive chain).
I am new to this platform of getting early information about upcoming 
changes.

Originally, PNA was supposed to "go live" in Version 113.  When I heard 
about it back in Nov '22, we tested it in Chrome v104 and placed support in 
our firmware back then.

So, is this now what could be called "on hold" ? 
(while we updated our firmware, there is no assurance the 1000's and 1000's 
of devices in the wild are being updated in a timely manner)

On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:

Just wanted to state here that we'll send a different intent to ship 


What is "intent to ship" ?   And what is meant my "send"?  Send to who?  Is 
there a mailing list?

Titouan and others mention things like M100, M101.  Is this the same 
designation as version number (v104, and v113).

In summary, my supervisor is asking me to find out if we need to be ready 
to tell a plethora of customers they have to upgrade our firmware when it 
stops working in the next day or two  (or have doc ready telling them how 
to disable this requirement).

Please, could someone give a brief tutorial to a newbie on PNA and how to 
be "in the loop" on these things?

Thanks.

-- 
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/6d9682db-cd11-41e1-a92c-1aa698ec86efn%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi blink-dev,

Just wanted to state here that we'll send a different intent to ship when
we want to enforce that preflights succeed, instead of re-using this one
(there is already an intent to deprecate thread [1]). PNA has been
launching bit by bit to manage compatibility risk, and having a
chromestatus entry / intents for each stage separately will help clarify
the current status.

I've updated the associated chromestatus feature [2] to focus on
warning-only preflights, as well.

Cheers,
Titouan

[1]
https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ
[2] https://chromestatus.com/feature/5737414355058688

On Fri, Oct 28, 2022 at 1:52 PM José Luis Campanello <
jose.luis.campane...@gmail.com> wrote:

> Thanks for the response!!! Have a nice weekend!
>
> On Friday, October 28, 2022 at 7:25:20 AM UTC-3 Titouan Rigoudy wrote:
>
>> Meant to link to this other thread [1] as the one on which we need 3
>> LGTMs.
>>
>> Cheers,
>> Titouan
>>
>> [1]
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ
>>
>> On Fri, Oct 28, 2022 at 6:22 AM Titouan Rigoudy 
>> wrote:
>>
>>> [blink-dev to bcc]
>>>
>>> Hi José,
>>>
>>> Thanks for reaching out, and sorry for the confusion!
>>>
>>> To be clear, the blog post states that this would be enabled in 107 *at
>>> the earliest*, which reflected our best estimate back when we wrote the
>>> post.
>>>
>>> We are now aiming to ship and start a deprecation trial in 109 at the
>>> earliest, if this thread gets 3 LGTMs by the end of next week. You can stay
>>> tuned here to know when this will ship, or follow along on Chromestatus
>>> [1]. The deprecation trial would allow you to request an extension until
>>> 113.
>>>
>>> Happy to answer any other questions you may have!
>>>
>>> Cheers,
>>> Titouan
>>>
>>> [1] https://chromestatus.com/feature/5737414355058688
>>>
>>> On Mon, Oct 24, 2022 at 3:31 PM José Luis Campanello <
>>> jose.luis@gmail.com> wrote:
>>>
 Hi all,

 i've been working to fix an application that will be affected by PNA
 preflights (we have an application that talks to a private server and a
 local -127.0.0.1- server).

 As I understood from this blog post (
 https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan),
 it seems PNA preflights will be enabled starting with release 107, but i
 can't find any reference as to whether it is being actually released in 107
 or later (I've seen 109, 112 and shipping on 113). I think I'm probably not
 understanding correctly all the details of what I'm reading.

 Can you confirm when this feature will enabled in the standard chrome?


 On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote:

> Hi there,
>
> Thanks for reaching out.
>
> Andrew: Indeed, this was crbug.com/1329248, apologies for the
> oversight. The change has been rolled back on Friday. Chrome 102 should
> pick up the configuration change upon restart.
>
> cpmtatest: by default, script fetches are made in no-cors mode with
> credentials. I believe [1] and [2] are the relevant specification bits
> here. If you think this should not be how PNA works, please file an issue
> in the GitHub repo [3].
>
> Cheers,
> Titouan
>
> [1]
> https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
> [2]
> https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
> [3] https://github.com/WICG/private-network-access/issues
>
> On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:
>
>> Hi,
>> Now when chrome 102 is out I wanted to test it so I ran it with
>> *--enable-features=PrivateNetworkAccessRespectPreflightResults*
>> There's one thing I'm trying to understand,
>> I have an HTML page with a script tag, the src of this tag points to
>> a more private network, the default behavior of script tags is not to
>> trigger CORS and since v102 they do trigger it which is expected.
>> My question is:
>> I'm getting this error: *"Response to preflight request doesn't pass
>> access control check: The value of the 'Access-Control-Allow-Credentials'
>> header in the response is '' which must be 'true' when the request's
>> credentials mode is 'include'."*
>> I never asked to send credentials in my script tag, I guess I can
>> force not send it by adding *crossorigin="" *to the tag but
>> shouldn't the default behavior be not to send it with credentials?
>>
> On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
>>
>>> Hi all -
>>>
>>> Just want to call out that this assumption...
>>> Chrome 102 should also not break anything, since we are sending
>>> preflights in warning-only mode. If the preflight fails, a warning is
>>> displayed in DevTools but the request proceed

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[José Luis Campanello]

Thanks for the response!!! Have a nice weekend!

On Friday, October 28, 2022 at 7:25:20 AM UTC-3 Titouan Rigoudy wrote:

> Meant to link to this other thread [1] as the one on which we need 3 LGTMs.
>
> Cheers,
> Titouan
>
> [1] 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ
>
> On Fri, Oct 28, 2022 at 6:22 AM Titouan Rigoudy  wrote:
>
>> [blink-dev to bcc]
>>
>> Hi José,
>>
>> Thanks for reaching out, and sorry for the confusion!
>>
>> To be clear, the blog post states that this would be enabled in 107 *at 
>> the earliest*, which reflected our best estimate back when we wrote the 
>> post.
>>
>> We are now aiming to ship and start a deprecation trial in 109 at the 
>> earliest, if this thread gets 3 LGTMs by the end of next week. You can stay 
>> tuned here to know when this will ship, or follow along on Chromestatus 
>> [1]. The deprecation trial would allow you to request an extension until 
>> 113.
>>
>> Happy to answer any other questions you may have!
>>
>> Cheers,
>> Titouan
>>
>> [1] https://chromestatus.com/feature/5737414355058688
>>
>> On Mon, Oct 24, 2022 at 3:31 PM José Luis Campanello <
>> jose.luis@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> i've been working to fix an application that will be affected by PNA 
>>> preflights (we have an application that talks to a private server and a 
>>> local -127.0.0.1- server).
>>>
>>> As I understood from this blog post (
>>> https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan),
>>>  
>>> it seems PNA preflights will be enabled starting with release 107, but i 
>>> can't find any reference as to whether it is being actually released in 107 
>>> or later (I've seen 109, 112 and shipping on 113). I think I'm probably not 
>>> understanding correctly all the details of what I'm reading.
>>>
>>> Can you confirm when this feature will enabled in the standard chrome?
>>>
>>>
>>> On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote:
>>>
 Hi there,

 Thanks for reaching out.

 Andrew: Indeed, this was crbug.com/1329248, apologies for the 
 oversight. The change has been rolled back on Friday. Chrome 102 should 
 pick up the configuration change upon restart.

 cpmtatest: by default, script fetches are made in no-cors mode with 
 credentials. I believe [1] and [2] are the relevant specification bits 
 here. If you think this should not be how PNA works, please file an issue 
 in the GitHub repo [3].

 Cheers,
 Titouan

 [1] 
 https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
 [2] 
 https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
 [3] https://github.com/WICG/private-network-access/issues

 On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:

> Hi,
> Now when chrome 102 is out I wanted to test it so I ran it with 
> *--enable-features=PrivateNetworkAccessRespectPreflightResults*
> There's one thing I'm trying to understand,
> I have an HTML page with a script tag, the src of this tag points to a 
> more private network, the default behavior of script tags is not to 
> trigger 
> CORS and since v102 they do trigger it which is expected.
> My question is:
> I'm getting this error: *"Response to preflight request doesn't pass 
> access control check: The value of the 'Access-Control-Allow-Credentials' 
> header in the response is '' which must be 'true' when the request's 
> credentials mode is 'include'."*
> I never asked to send credentials in my script tag, I guess I can 
> force not send it by adding *crossorigin="" *to the tag but shouldn't 
> the default behavior be not to send it with credentials?
>
 On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
>
>> Hi all -
>>
>> Just want to call out that this assumption...
>> Chrome 102 should also not break anything, since we are sending 
>> preflights in warning-only mode. If the preflight fails, a warning is 
>> displayed in DevTools but the request proceeds as before
>> ... turned out to be false.
>>
>> The change recently deployed DOES break things. It has broken our 
>> internal admin tool our CS teams use to manage customer accounts. 
>>
>> Bug opened here > 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248
>>
>> In meantime, I have my users moving to other browsers because this 
>> has broken a critical function for them. 
>>
>> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy 
>> wrote:
>>
>>> Hi there,
>>>
>>> John: that's due to another facet of Private Network Access (not 
>>> this intent) that started a deprecation trial in Chrome 94. See 
>>> https://chromestatus.com/feature/5436853517811712. Unless signed up 
>>> for the deprecatio

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Meant to link to this other thread [1] as the one on which we need 3 LGTMs.

Cheers,
Titouan

[1]
https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ

On Fri, Oct 28, 2022 at 6:22 AM Titouan Rigoudy  wrote:

> [blink-dev to bcc]
>
> Hi José,
>
> Thanks for reaching out, and sorry for the confusion!
>
> To be clear, the blog post states that this would be enabled in 107 *at
> the earliest*, which reflected our best estimate back when we wrote the
> post.
>
> We are now aiming to ship and start a deprecation trial in 109 at the
> earliest, if this thread gets 3 LGTMs by the end of next week. You can stay
> tuned here to know when this will ship, or follow along on Chromestatus
> [1]. The deprecation trial would allow you to request an extension until
> 113.
>
> Happy to answer any other questions you may have!
>
> Cheers,
> Titouan
>
> [1] https://chromestatus.com/feature/5737414355058688
>
> On Mon, Oct 24, 2022 at 3:31 PM José Luis Campanello <
> jose.luis.campane...@gmail.com> wrote:
>
>> Hi all,
>>
>> i've been working to fix an application that will be affected by PNA
>> preflights (we have an application that talks to a private server and a
>> local -127.0.0.1- server).
>>
>> As I understood from this blog post (
>> https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan),
>> it seems PNA preflights will be enabled starting with release 107, but i
>> can't find any reference as to whether it is being actually released in 107
>> or later (I've seen 109, 112 and shipping on 113). I think I'm probably not
>> understanding correctly all the details of what I'm reading.
>>
>> Can you confirm when this feature will enabled in the standard chrome?
>>
>>
>> On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote:
>>
>>> Hi there,
>>>
>>> Thanks for reaching out.
>>>
>>> Andrew: Indeed, this was crbug.com/1329248, apologies for the
>>> oversight. The change has been rolled back on Friday. Chrome 102 should
>>> pick up the configuration change upon restart.
>>>
>>> cpmtatest: by default, script fetches are made in no-cors mode with
>>> credentials. I believe [1] and [2] are the relevant specification bits
>>> here. If you think this should not be how PNA works, please file an issue
>>> in the GitHub repo [3].
>>>
>>> Cheers,
>>> Titouan
>>>
>>> [1]
>>> https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
>>> [2]
>>> https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
>>> [3] https://github.com/WICG/private-network-access/issues
>>>
>>> On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:
>>>
 Hi,
 Now when chrome 102 is out I wanted to test it so I ran it with
 *--enable-features=PrivateNetworkAccessRespectPreflightResults*
 There's one thing I'm trying to understand,
 I have an HTML page with a script tag, the src of this tag points to a
 more private network, the default behavior of script tags is not to trigger
 CORS and since v102 they do trigger it which is expected.
 My question is:
 I'm getting this error: *"Response to preflight request doesn't pass
 access control check: The value of the 'Access-Control-Allow-Credentials'
 header in the response is '' which must be 'true' when the request's
 credentials mode is 'include'."*
 I never asked to send credentials in my script tag, I guess I can force
 not send it by adding *crossorigin="" *to the tag but shouldn't the
 default behavior be not to send it with credentials?

>>> On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:

> Hi all -
>
> Just want to call out that this assumption...
> Chrome 102 should also not break anything, since we are sending
> preflights in warning-only mode. If the preflight fails, a warning is
> displayed in DevTools but the request proceeds as before
> ... turned out to be false.
>
> The change recently deployed DOES break things. It has broken our
> internal admin tool our CS teams use to manage customer accounts.
>
> Bug opened here >
> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248
>
> In meantime, I have my users moving to other browsers because this has
> broken a critical function for them.
>
> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:
>
>> Hi there,
>>
>> John: that's due to another facet of Private Network Access (not this
>> intent) that started a deprecation trial in Chrome 94. See
>> https://chromestatus.com/feature/5436853517811712. Unless signed up
>> for the deprecation trial, HTTP websites are no longer allowed to make 
>> any
>> requests to private servers.
>>
>> Martin: there will be no breaking change in Chrome 101. I need to
>> update the blog post to make the new timeline clearer.
>>
>> Chrome 102 should also not break anything,

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

[blink-dev to bcc]

Hi José,

Thanks for reaching out, and sorry for the confusion!

To be clear, the blog post states that this would be enabled in 107 *at the
earliest*, which reflected our best estimate back when we wrote the post.

We are now aiming to ship and start a deprecation trial in 109 at the
earliest, if this thread gets 3 LGTMs by the end of next week. You can stay
tuned here to know when this will ship, or follow along on Chromestatus
[1]. The deprecation trial would allow you to request an extension until
113.

Happy to answer any other questions you may have!

Cheers,
Titouan

[1] https://chromestatus.com/feature/5737414355058688

On Mon, Oct 24, 2022 at 3:31 PM José Luis Campanello <
jose.luis.campane...@gmail.com> wrote:

> Hi all,
>
> i've been working to fix an application that will be affected by PNA
> preflights (we have an application that talks to a private server and a
> local -127.0.0.1- server).
>
> As I understood from this blog post (
> https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan),
> it seems PNA preflights will be enabled starting with release 107, but i
> can't find any reference as to whether it is being actually released in 107
> or later (I've seen 109, 112 and shipping on 113). I think I'm probably not
> understanding correctly all the details of what I'm reading.
>
> Can you confirm when this feature will enabled in the standard chrome?
>
>
> On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote:
>
>> Hi there,
>>
>> Thanks for reaching out.
>>
>> Andrew: Indeed, this was crbug.com/1329248, apologies for the oversight.
>> The change has been rolled back on Friday. Chrome 102 should pick up the
>> configuration change upon restart.
>>
>> cpmtatest: by default, script fetches are made in no-cors mode with
>> credentials. I believe [1] and [2] are the relevant specification bits
>> here. If you think this should not be how PNA works, please file an issue
>> in the GitHub repo [3].
>>
>> Cheers,
>> Titouan
>>
>> [1]
>> https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
>> [2]
>> https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
>> [3] https://github.com/WICG/private-network-access/issues
>>
>> On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:
>>
>>> Hi,
>>> Now when chrome 102 is out I wanted to test it so I ran it with
>>> *--enable-features=PrivateNetworkAccessRespectPreflightResults*
>>> There's one thing I'm trying to understand,
>>> I have an HTML page with a script tag, the src of this tag points to a
>>> more private network, the default behavior of script tags is not to trigger
>>> CORS and since v102 they do trigger it which is expected.
>>> My question is:
>>> I'm getting this error: *"Response to preflight request doesn't pass
>>> access control check: The value of the 'Access-Control-Allow-Credentials'
>>> header in the response is '' which must be 'true' when the request's
>>> credentials mode is 'include'."*
>>> I never asked to send credentials in my script tag, I guess I can force
>>> not send it by adding *crossorigin="" *to the tag but shouldn't the
>>> default behavior be not to send it with credentials?
>>>
>> On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
>>>
 Hi all -

 Just want to call out that this assumption...
 Chrome 102 should also not break anything, since we are sending
 preflights in warning-only mode. If the preflight fails, a warning is
 displayed in DevTools but the request proceeds as before
 ... turned out to be false.

 The change recently deployed DOES break things. It has broken our
 internal admin tool our CS teams use to manage customer accounts.

 Bug opened here >
 https://bugs.chromium.org/p/chromium/issues/detail?id=1329248

 In meantime, I have my users moving to other browsers because this has
 broken a critical function for them.

 On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:

> Hi there,
>
> John: that's due to another facet of Private Network Access (not this
> intent) that started a deprecation trial in Chrome 94. See
> https://chromestatus.com/feature/5436853517811712. Unless signed up
> for the deprecation trial, HTTP websites are no longer allowed to make any
> requests to private servers.
>
> Martin: there will be no breaking change in Chrome 101. I need to
> update the blog post to make the new timeline clearer.
>
> Chrome 102 should also not break anything, since we are sending
> preflights in warning-only mode. If the preflight fails, a warning is
> displayed in DevTools but the request proceeds as before. As explained
> above, this will remain the case until at least Chrome 105, at which point
> we may turn on enforcement: when a preflight fails, the request should not
> be sent and fail. That remains subjec

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[José Luis Campanello]

Hi all,

i've been working to fix an application that will be affected by PNA 
preflights (we have an application that talks to a private server and a 
local -127.0.0.1- server).

As I understood from this blog post 
(https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan),
 
it seems PNA preflights will be enabled starting with release 107, but i 
can't find any reference as to whether it is being actually released in 107 
or later (I've seen 109, 112 and shipping on 113). I think I'm probably not 
understanding correctly all the details of what I'm reading.

Can you confirm when this feature will enabled in the standard chrome?


On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote:

> Hi there,
>
> Thanks for reaching out.
>
> Andrew: Indeed, this was crbug.com/1329248, apologies for the oversight. 
> The change has been rolled back on Friday. Chrome 102 should pick up the 
> configuration change upon restart.
>
> cpmtatest: by default, script fetches are made in no-cors mode with 
> credentials. I believe [1] and [2] are the relevant specification bits 
> here. If you think this should not be how PNA works, please file an issue 
> in the GitHub repo [3].
>
> Cheers,
> Titouan
>
> [1] 
> https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
> [2] 
> https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
> [3] https://github.com/WICG/private-network-access/issues
>
> On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:
>
>> Hi,
>> Now when chrome 102 is out I wanted to test it so I ran it with 
>> *--enable-features=PrivateNetworkAccessRespectPreflightResults*
>> There's one thing I'm trying to understand,
>> I have an HTML page with a script tag, the src of this tag points to a 
>> more private network, the default behavior of script tags is not to trigger 
>> CORS and since v102 they do trigger it which is expected.
>> My question is:
>> I'm getting this error: *"Response to preflight request doesn't pass 
>> access control check: The value of the 'Access-Control-Allow-Credentials' 
>> header in the response is '' which must be 'true' when the request's 
>> credentials mode is 'include'."*
>> I never asked to send credentials in my script tag, I guess I can force 
>> not send it by adding *crossorigin="" *to the tag but shouldn't the 
>> default behavior be not to send it with credentials?
>>
> On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
>>
>>> Hi all -
>>>
>>> Just want to call out that this assumption...
>>> Chrome 102 should also not break anything, since we are sending 
>>> preflights in warning-only mode. If the preflight fails, a warning is 
>>> displayed in DevTools but the request proceeds as before
>>> ... turned out to be false.
>>>
>>> The change recently deployed DOES break things. It has broken our 
>>> internal admin tool our CS teams use to manage customer accounts. 
>>>
>>> Bug opened here > 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248
>>>
>>> In meantime, I have my users moving to other browsers because this has 
>>> broken a critical function for them. 
>>>
>>> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:
>>>
 Hi there,

 John: that's due to another facet of Private Network Access (not this 
 intent) that started a deprecation trial in Chrome 94. See 
 https://chromestatus.com/feature/5436853517811712. Unless signed up 
 for the deprecation trial, HTTP websites are no longer allowed to make any 
 requests to private servers.

 Martin: there will be no breaking change in Chrome 101. I need to 
 update the blog post to make the new timeline clearer.

 Chrome 102 should also not break anything, since we are sending 
 preflights in warning-only mode. If the preflight fails, a warning is 
 displayed in DevTools but the request proceeds as before. As explained 
 above, this will remain the case until at least Chrome 105, at which point 
 we may turn on enforcement: when a preflight fails, the request should not 
 be sent and fail. That remains subject to compatibility risk evaluation.

 Cheers,
 Titouan

 On Wed, Apr 20, 2022 at 3:06 AM Martin H  wrote:

> Hi Titouan, Blink Devs,
>
> Thank you for this news above. 
> I work for a software vendor affected by this change, our software 
> installs a small (https://localhost:60500) web server on a users 
> local machine and our https:// SAAS web application connects  to this to 
> hand off various features
> We were under the impression this change was to occur in Chrome 101 
> and have been moving to that timeline rapidly but reading the above I 
> understand this has changed (confusingly though much of the documentation 
> online still carries older dates and talks about the change as early as 
> 101 
> or 102. )
>
> Should

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Who Cares]

Hi,
Now when chrome 102 is out I wanted to test it so I ran it with 
*--enable-features=PrivateNetworkAccessRespectPreflightResults*
There's one thing I'm trying to understand,
I have an HTML page with a script tag, the src of this tag points to a more 
private network, the default behavior of script tags is not to trigger CORS 
and since v102 they do trigger it which is expected.
My question is:
I'm getting this error: *"Response to preflight request doesn't pass access 
control check: The value of the 'Access-Control-Allow-Credentials' header 
in the response is '' which must be 'true' when the request's credentials 
mode is 'include'."*
I never asked to send credentials in my script tag, I guess I can force not 
send it by adding *crossorigin="" *to the tag but shouldn't the default 
behavior be not to send it with credentials?
On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:

> Hi all -
>
> Just want to call out that this assumption...
> Chrome 102 should also not break anything, since we are sending preflights 
> in warning-only mode. If the preflight fails, a warning is displayed in 
> DevTools but the request proceeds as before
> ... turned out to be false.
>
> The change recently deployed DOES break things. It has broken our internal 
> admin tool our CS teams use to manage customer accounts. 
>
> Bug opened here > 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248
>
> In meantime, I have my users moving to other browsers because this has 
> broken a critical function for them. 
>
> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:
>
>> Hi there,
>>
>> John: that's due to another facet of Private Network Access (not this 
>> intent) that started a deprecation trial in Chrome 94. See 
>> https://chromestatus.com/feature/5436853517811712. Unless signed up for 
>> the deprecation trial, HTTP websites are no longer allowed to make any 
>> requests to private servers.
>>
>> Martin: there will be no breaking change in Chrome 101. I need to update 
>> the blog post to make the new timeline clearer.
>>
>> Chrome 102 should also not break anything, since we are sending 
>> preflights in warning-only mode. If the preflight fails, a warning is 
>> displayed in DevTools but the request proceeds as before. As explained 
>> above, this will remain the case until at least Chrome 105, at which point 
>> we may turn on enforcement: when a preflight fails, the request should not 
>> be sent and fail. That remains subject to compatibility risk evaluation.
>>
>> Cheers,
>> Titouan
>>
>> On Wed, Apr 20, 2022 at 3:06 AM Martin H  wrote:
>>
>>> Hi Titouan, Blink Devs,
>>>
>>> Thank you for this news above. 
>>> I work for a software vendor affected by this change, our software 
>>> installs a small (https://localhost:60500) web server on a users local 
>>> machine and our https:// SAAS web application connects  to this to hand off 
>>> various features
>>> We were under the impression this change was to occur in Chrome 101 and 
>>> have been moving to that timeline rapidly but reading the above I 
>>> understand this has changed (confusingly though much of the documentation 
>>> online still carries older dates and talks about the change as early as 101 
>>> or 102. )
>>>
>>> Should I now understand that *if* this makes Chrome 102 as hoped, you 
>>> will have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship 
>>> "private network access" changes in 105?  
>>> I would understand it's just an estimate based on feedback around this 
>>> change but as it stands our business is anticipating change as early as 
>>> next week as this is when 101 was due to ship production. 
>>> it would therefore be extremely beneficial if we understand we have more 
>>> time to work with customers around this, we have produced updated compliant 
>>> local components on our end and released this in the past few weeks but as 
>>> you might expect we need time to address this with every single one of our 
>>> customers, as Chromium based browsers form the overwhelming majority of 
>>> users. 
>>>
>>> Ultimately my requirement is to advise customers on the change as best 
>>> as possible, including how to ensure the change is not deployed as some 
>>> will need time to update their entire fleets. 
>>> When I install Chrome dev 102 build, it seems like our software still 
>>> works as is today. I assume as it's not on yet. Would someone be able to 
>>> state which flags I should enable to replicate what will happen when this 
>>> change goes live?
>>>
>>> Is it just the #block-insecure-private-network-requests 
>>> Do I need to 
>>> configure #private-network-access-send-preflights or 
>>> #private-network-access-respect-preflight-results
>>> Today all these settings are just "Default
>>>
>>> Thanks in advance, please let me know if there is a better forum for 
>>> this request.
>>> Martin
>>>
>>>
>>> On Wednesday, April 20, 2022 at 3:28:37 AM UTC+10 John Doe wrote:
>>>
 Sor

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi there,

Thanks for reaching out.

Andrew: Indeed, this was crbug.com/1329248, apologies for the oversight.
The change has been rolled back on Friday. Chrome 102 should pick up the
configuration change upon restart.

cpmtatest: by default, script fetches are made in no-cors mode with
credentials. I believe [1] and [2] are the relevant specification bits
here. If you think this should not be how PNA works, please file an issue
in the GitHub repo [3].

Cheers,
Titouan

[1]
https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request
[2]
https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script
[3] https://github.com/WICG/private-network-access/issues

On Mon, May 30, 2022 at 10:46 AM Who Cares  wrote:

> Hi,
> Now when chrome 102 is out I wanted to test it so I ran it with
> *--enable-features=PrivateNetworkAccessRespectPreflightResults*
> There's one thing I'm trying to understand,
> I have an HTML page with a script tag, the src of this tag points to a
> more private network, the default behavior of script tags is not to trigger
> CORS and since v102 they do trigger it which is expected.
> My question is:
> I'm getting this error: *"Response to preflight request doesn't pass
> access control check: The value of the 'Access-Control-Allow-Credentials'
> header in the response is '' which must be 'true' when the request's
> credentials mode is 'include'."*
> I never asked to send credentials in my script tag, I guess I can force
> not send it by adding *crossorigin="" *to the tag but shouldn't the
> default behavior be not to send it with credentials?
> On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
>
>> Hi all -
>>
>> Just want to call out that this assumption...
>> Chrome 102 should also not break anything, since we are sending
>> preflights in warning-only mode. If the preflight fails, a warning is
>> displayed in DevTools but the request proceeds as before
>> ... turned out to be false.
>>
>> The change recently deployed DOES break things. It has broken our
>> internal admin tool our CS teams use to manage customer accounts.
>>
>> Bug opened here >
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248
>>
>> In meantime, I have my users moving to other browsers because this has
>> broken a critical function for them.
>>
>> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:
>>
>>> Hi there,
>>>
>>> John: that's due to another facet of Private Network Access (not this
>>> intent) that started a deprecation trial in Chrome 94. See
>>> https://chromestatus.com/feature/5436853517811712. Unless signed up for
>>> the deprecation trial, HTTP websites are no longer allowed to make any
>>> requests to private servers.
>>>
>>> Martin: there will be no breaking change in Chrome 101. I need to update
>>> the blog post to make the new timeline clearer.
>>>
>>> Chrome 102 should also not break anything, since we are sending
>>> preflights in warning-only mode. If the preflight fails, a warning is
>>> displayed in DevTools but the request proceeds as before. As explained
>>> above, this will remain the case until at least Chrome 105, at which point
>>> we may turn on enforcement: when a preflight fails, the request should not
>>> be sent and fail. That remains subject to compatibility risk evaluation.
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Wed, Apr 20, 2022 at 3:06 AM Martin H  wrote:
>>>
 Hi Titouan, Blink Devs,

 Thank you for this news above.
 I work for a software vendor affected by this change, our software
 installs a small (https://localhost:60500) web server on a users local
 machine and our https:// SAAS web application connects  to this to
 hand off various features
 We were under the impression this change was to occur in Chrome 101 and
 have been moving to that timeline rapidly but reading the above I
 understand this has changed (confusingly though much of the documentation
 online still carries older dates and talks about the change as early as 101
 or 102. )

 Should I now understand that *if* this makes Chrome 102 as hoped, you
 will have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship
 "private network access" changes in 105?
 I would understand it's just an estimate based on feedback around this
 change but as it stands our business is anticipating change as early as
 next week as this is when 101 was due to ship production.
 it would therefore be extremely beneficial if we understand we have
 more time to work with customers around this, we have produced updated
 compliant local components on our end and released this in the past few
 weeks but as you might expect we need time to address this with every
 single one of our customers, as Chromium based browsers form the
 overwhelming majority of users.

 Ultimately my requirement is to advise customers on the change as best
>

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Andrew Boeger' via blink-dev]

Hi all -

Just want to call out that this assumption...
Chrome 102 should also not break anything, since we are sending preflights 
in warning-only mode. If the preflight fails, a warning is displayed in 
DevTools but the request proceeds as before
... turned out to be false.

The change recently deployed DOES break things. It has broken our internal 
admin tool our CS teams use to manage customer accounts. 

Bug opened here 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248

In meantime, I have my users moving to other browsers because this has 
broken a critical function for them. 

On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote:

> Hi there,
>
> John: that's due to another facet of Private Network Access (not this 
> intent) that started a deprecation trial in Chrome 94. See 
> https://chromestatus.com/feature/5436853517811712. Unless signed up for 
> the deprecation trial, HTTP websites are no longer allowed to make any 
> requests to private servers.
>
> Martin: there will be no breaking change in Chrome 101. I need to update 
> the blog post to make the new timeline clearer.
>
> Chrome 102 should also not break anything, since we are sending preflights 
> in warning-only mode. If the preflight fails, a warning is displayed in 
> DevTools but the request proceeds as before. As explained above, this will 
> remain the case until at least Chrome 105, at which point we may turn on 
> enforcement: when a preflight fails, the request should not be sent and 
> fail. That remains subject to compatibility risk evaluation.
>
> Cheers,
> Titouan
>
> On Wed, Apr 20, 2022 at 3:06 AM Martin H  wrote:
>
>> Hi Titouan, Blink Devs,
>>
>> Thank you for this news above. 
>> I work for a software vendor affected by this change, our software 
>> installs a small (https://localhost:60500) web server on a users local 
>> machine and our https:// SAAS web application connects  to this to hand off 
>> various features
>> We were under the impression this change was to occur in Chrome 101 and 
>> have been moving to that timeline rapidly but reading the above I 
>> understand this has changed (confusingly though much of the documentation 
>> online still carries older dates and talks about the change as early as 101 
>> or 102. )
>>
>> Should I now understand that *if* this makes Chrome 102 as hoped, you 
>> will have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship 
>> "private network access" changes in 105?  
>> I would understand it's just an estimate based on feedback around this 
>> change but as it stands our business is anticipating change as early as 
>> next week as this is when 101 was due to ship production. 
>> it would therefore be extremely beneficial if we understand we have more 
>> time to work with customers around this, we have produced updated compliant 
>> local components on our end and released this in the past few weeks but as 
>> you might expect we need time to address this with every single one of our 
>> customers, as Chromium based browsers form the overwhelming majority of 
>> users. 
>>
>> Ultimately my requirement is to advise customers on the change as best as 
>> possible, including how to ensure the change is not deployed as some will 
>> need time to update their entire fleets. 
>> When I install Chrome dev 102 build, it seems like our software still 
>> works as is today. I assume as it's not on yet. Would someone be able to 
>> state which flags I should enable to replicate what will happen when this 
>> change goes live?
>>
>> Is it just the #block-insecure-private-network-requests 
>> Do I need to 
>> configure #private-network-access-send-preflights or 
>> #private-network-access-respect-preflight-results
>> Today all these settings are just "Default
>>
>> Thanks in advance, please let me know if there is a better forum for this 
>> request.
>> Martin
>>
>>
>> On Wednesday, April 20, 2022 at 3:28:37 AM UTC+10 John Doe wrote:
>>
>>> Sorry seems I accidently switched the S sides in the first question, I 
>>> meant from public HTTP to private HTTPS so it shouldn't be mixed content, 
>>> and in such case there's no preflight request.
>>> As I mentioned I installed chrome 98 to test it, when accessing a 
>>> resource from public HTTPS to private HTTPS there's a preflight request but 
>>> no such request on an access from public HTTP to private HTTPS.
>>>
>>> On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote:
>>>
 Hi there,

 1. Such requests are blocked by mixed content. This launch does not 
 change that.
 2. You will want to respond 200 OK to PNA preflight requests to your 
 private HTTPS server with the right headers. See the blog post [1] for 
 details.

 Cheers,
 Titouan

 [1] 
 https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests

 On Sun, Apr 17, 2022 at 4:56 PM John Doe  wrote:

> 1. In Chrome 98, there wer

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi there,

John: that's due to another facet of Private Network Access (not this
intent) that started a deprecation trial in Chrome 94. See
https://chromestatus.com/feature/5436853517811712. Unless signed up for the
deprecation trial, HTTP websites are no longer allowed to make any requests
to private servers.

Martin: there will be no breaking change in Chrome 101. I need to update
the blog post to make the new timeline clearer.

Chrome 102 should also not break anything, since we are sending preflights
in warning-only mode. If the preflight fails, a warning is displayed in
DevTools but the request proceeds as before. As explained above, this will
remain the case until at least Chrome 105, at which point we may turn on
enforcement: when a preflight fails, the request should not be sent and
fail. That remains subject to compatibility risk evaluation.

Cheers,
Titouan

On Wed, Apr 20, 2022 at 3:06 AM Martin H  wrote:

> Hi Titouan, Blink Devs,
>
> Thank you for this news above.
> I work for a software vendor affected by this change, our software
> installs a small (https://localhost:60500) web server on a users local
> machine and our https:// SAAS web application connects  to this to hand
> off various features
> We were under the impression this change was to occur in Chrome 101 and
> have been moving to that timeline rapidly but reading the above I
> understand this has changed (confusingly though much of the documentation
> online still carries older dates and talks about the change as early as 101
> or 102. )
>
> Should I now understand that *if* this makes Chrome 102 as hoped, you will
> have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship
> "private network access" changes in 105?
> I would understand it's just an estimate based on feedback around this
> change but as it stands our business is anticipating change as early as
> next week as this is when 101 was due to ship production.
> it would therefore be extremely beneficial if we understand we have more
> time to work with customers around this, we have produced updated compliant
> local components on our end and released this in the past few weeks but as
> you might expect we need time to address this with every single one of our
> customers, as Chromium based browsers form the overwhelming majority of
> users.
>
> Ultimately my requirement is to advise customers on the change as best as
> possible, including how to ensure the change is not deployed as some will
> need time to update their entire fleets.
> When I install Chrome dev 102 build, it seems like our software still
> works as is today. I assume as it's not on yet. Would someone be able to
> state which flags I should enable to replicate what will happen when this
> change goes live?
>
> Is it just the #block-insecure-private-network-requests
> Do I need to
> configure #private-network-access-send-preflights or 
> #private-network-access-respect-preflight-results
> Today all these settings are just "Default
>
> Thanks in advance, please let me know if there is a better forum for this
> request.
> Martin
>
>
> On Wednesday, April 20, 2022 at 3:28:37 AM UTC+10 John Doe wrote:
>
>> Sorry seems I accidently switched the S sides in the first question, I
>> meant from public HTTP to private HTTPS so it shouldn't be mixed content,
>> and in such case there's no preflight request.
>> As I mentioned I installed chrome 98 to test it, when accessing a
>> resource from public HTTPS to private HTTPS there's a preflight request but
>> no such request on an access from public HTTP to private HTTPS.
>>
>> On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote:
>>
>>> Hi there,
>>>
>>> 1. Such requests are blocked by mixed content. This launch does not
>>> change that.
>>> 2. You will want to respond 200 OK to PNA preflight requests to your
>>> private HTTPS server with the right headers. See the blog post [1] for
>>> details.
>>>
>>> Cheers,
>>> Titouan
>>>
>>> [1]
>>> https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests
>>>
>>> On Sun, Apr 17, 2022 at 4:56 PM John Doe  wrote:
>>>
 1. In Chrome 98, there were no preflight requests when accessing from
 public HTTPS to private HTTP, will the same be true in the final version?
 2. In the case when I have a private HTTPS server that I want everyone
 to have access to (also via public HTTP), what options do I have ?

 On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:

> Hi all,
>
> Thanks for the timely question, I was about to send an update here.
>
> We have fixed nearly all of the blockers identified in the above doc.
> The only outstanding issue is the aforementioned crash, which required a
> bit more design work than the rest. That work has been completed and CLs 
> to
> fix the problem are now in review; they should land shortly and make it in
> Chrome 102.
>
> We would like to ship again 

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Martin H]

Hi Titouan, Blink Devs,

Thank you for this news above. 
I work for a software vendor affected by this change, our software installs 
a small (https://localhost:60500) web server on a users local machine and 
our https:// SAAS web application connects  to this to hand off various 
features
We were under the impression this change was to occur in Chrome 101 and 
have been moving to that timeline rapidly but reading the above I 
understand this has changed (confusingly though much of the documentation 
online still carries older dates and talks about the change as early as 101 
or 102. )

Should I now understand that *if* this makes Chrome 102 as hoped, you will 
have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship 
"private network access" changes in 105?  
I would understand it's just an estimate based on feedback around this 
change but as it stands our business is anticipating change as early as 
next week as this is when 101 was due to ship production. 
it would therefore be extremely beneficial if we understand we have more 
time to work with customers around this, we have produced updated compliant 
local components on our end and released this in the past few weeks but as 
you might expect we need time to address this with every single one of our 
customers, as Chromium based browsers form the overwhelming majority of 
users. 

Ultimately my requirement is to advise customers on the change as best as 
possible, including how to ensure the change is not deployed as some will 
need time to update their entire fleets. 
When I install Chrome dev 102 build, it seems like our software still works 
as is today. I assume as it's not on yet. Would someone be able to state 
which flags I should enable to replicate what will happen when this change 
goes live?

Is it just the #block-insecure-private-network-requests 
Do I need to 
configure #private-network-access-send-preflights or 
#private-network-access-respect-preflight-results
Today all these settings are just "Default

Thanks in advance, please let me know if there is a better forum for this 
request.
Martin


On Wednesday, April 20, 2022 at 3:28:37 AM UTC+10 John Doe wrote:

> Sorry seems I accidently switched the S sides in the first question, I 
> meant from public HTTP to private HTTPS so it shouldn't be mixed content, 
> and in such case there's no preflight request.
> As I mentioned I installed chrome 98 to test it, when accessing a resource 
> from public HTTPS to private HTTPS there's a preflight request but no such 
> request on an access from public HTTP to private HTTPS.
>
> On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote:
>
>> Hi there,
>>
>> 1. Such requests are blocked by mixed content. This launch does not 
>> change that.
>> 2. You will want to respond 200 OK to PNA preflight requests to your 
>> private HTTPS server with the right headers. See the blog post [1] for 
>> details.
>>
>> Cheers,
>> Titouan
>>
>> [1] 
>> https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests
>>
>> On Sun, Apr 17, 2022 at 4:56 PM John Doe  wrote:
>>
>>> 1. In Chrome 98, there were no preflight requests when accessing from 
>>> public HTTPS to private HTTP, will the same be true in the final version?
>>> 2. In the case when I have a private HTTPS server that I want everyone 
>>> to have access to (also via public HTTP), what options do I have ?
>>>
>>> On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:
>>>
 Hi all,

 Thanks for the timely question, I was about to send an update here.

 We have fixed nearly all of the blockers identified in the above doc. 
 The only outstanding issue is the aforementioned crash, which required a 
 bit more design work than the rest. That work has been completed and CLs 
 to 
 fix the problem are now in review; they should land shortly and make it in 
 Chrome 102.

 We would like to ship again in Chrome 102 in warning-only mode, just as 
 we last tried in Chrome 98. Preflights will be sent but their results will 
 not be enforced. Failed preflights will show warnings in DevTools, but 
 requests will otherwise continue unimpeded.

 Things will stay that way for at least 3 milestones. We will gather 
 compatibility data by monitoring failed preflights, then circle back here 
 to garner approvals to turn on enforcement. That launch will be 
 accompanied 
 by a deprecation trial for web developers to sign up for a time extension 
 if they failed to notice the warnings in time.

 Cheers,
 Titouan

 On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:

> Hello,  is there now an updated timeline to roll out this change?  
> Will the trial restart in Chrome 102 or a later version?  
>
> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>
>> Hi all,
>>
>> Here's the promised doc: 
>> h

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[John Doe]

Sorry seems I accidently switched the S sides in the first question, I 
meant from public HTTP to private HTTPS so it shouldn't be mixed content, 
and in such case there's no preflight request.
As I mentioned I installed chrome 98 to test it, when accessing a resource 
from public HTTPS to private HTTPS there's a preflight request but no such 
request on an access from public HTTP to private HTTPS.

On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote:

> Hi there,
>
> 1. Such requests are blocked by mixed content. This launch does not change 
> that.
> 2. You will want to respond 200 OK to PNA preflight requests to your 
> private HTTPS server with the right headers. See the blog post [1] for 
> details.
>
> Cheers,
> Titouan
>
> [1] 
> https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests
>
> On Sun, Apr 17, 2022 at 4:56 PM John Doe  wrote:
>
>> 1. In Chrome 98, there were no preflight requests when accessing from 
>> public HTTPS to private HTTP, will the same be true in the final version?
>> 2. In the case when I have a private HTTPS server that I want everyone to 
>> have access to (also via public HTTP), what options do I have ?
>>
>> On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:
>>
>>> Hi all,
>>>
>>> Thanks for the timely question, I was about to send an update here.
>>>
>>> We have fixed nearly all of the blockers identified in the above doc. 
>>> The only outstanding issue is the aforementioned crash, which required a 
>>> bit more design work than the rest. That work has been completed and CLs to 
>>> fix the problem are now in review; they should land shortly and make it in 
>>> Chrome 102.
>>>
>>> We would like to ship again in Chrome 102 in warning-only mode, just as 
>>> we last tried in Chrome 98. Preflights will be sent but their results will 
>>> not be enforced. Failed preflights will show warnings in DevTools, but 
>>> requests will otherwise continue unimpeded.
>>>
>>> Things will stay that way for at least 3 milestones. We will gather 
>>> compatibility data by monitoring failed preflights, then circle back here 
>>> to garner approvals to turn on enforcement. That launch will be accompanied 
>>> by a deprecation trial for web developers to sign up for a time extension 
>>> if they failed to notice the warnings in time.
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:
>>>
 Hello,  is there now an updated timeline to roll out this change?  Will 
 the trial restart in Chrome 102 or a later version?  

 On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:

> Hi all,
>
> Here's the promised doc: 
> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>  
> (public, comment access for committers only)
>
> Cheers,
> Titouan
>
> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  
> wrote:
>
>> Thanks for the update Titouan. Looking forward to reading your doc.
>>
>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>>
>> Hi all, 
>>
>> Just to let you know that due to a couple issues, chief among which a 
>> renderer crash (crbug.com/1279376), we are rolling this feature back 
>> from Chrome 98.
>>
>> A few issues have been identified and will block our next attempt at 
>> shipping this. In the meantime, we gathered some useful information 
>> about 
>> impact and notified developers of the upcoming change. I'll write a doc 
>> summarizing the timeline and lessons learned, then share as appropriate 
>> here.
>>
>> Cheers,
>> Titouan
>>
>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM3 for step 1.
>>>
>>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  
>>> wrote:
>>>
 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  
 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  
> 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 <
>> blin...@chromium.org> wrote:
>>
>>

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi there,

1. Such requests are blocked by mixed content. This launch does not change
that.
2. You will want to respond 200 OK to PNA preflight requests to your
private HTTPS server with the right headers. See the blog post [1] for
details.

Cheers,
Titouan

[1]
https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests

On Sun, Apr 17, 2022 at 4:56 PM John Doe  wrote:

> 1. In Chrome 98, there were no preflight requests when accessing from
> public HTTPS to private HTTP, will the same be true in the final version?
> 2. In the case when I have a private HTTPS server that I want everyone to
> have access to (also via public HTTP), what options do I have ?
>
> On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:
>
>> Hi all,
>>
>> Thanks for the timely question, I was about to send an update here.
>>
>> We have fixed nearly all of the blockers identified in the above doc. The
>> only outstanding issue is the aforementioned crash, which required a bit
>> more design work than the rest. That work has been completed and CLs to fix
>> the problem are now in review; they should land shortly and make it in
>> Chrome 102.
>>
>> We would like to ship again in Chrome 102 in warning-only mode, just as
>> we last tried in Chrome 98. Preflights will be sent but their results will
>> not be enforced. Failed preflights will show warnings in DevTools, but
>> requests will otherwise continue unimpeded.
>>
>> Things will stay that way for at least 3 milestones. We will gather
>> compatibility data by monitoring failed preflights, then circle back here
>> to garner approvals to turn on enforcement. That launch will be accompanied
>> by a deprecation trial for web developers to sign up for a time extension
>> if they failed to notice the warnings in time.
>>
>> Cheers,
>> Titouan
>>
>> On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:
>>
>>> Hello,  is there now an updated timeline to roll out this change?  Will
>>> the trial restart in Chrome 102 or a later version?
>>>
>>> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>>>
 Hi all,

 Here's the promised doc:
 https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
 (public, comment access for committers only)

 Cheers,
 Titouan

 On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor 
 wrote:

> Thanks for the update Titouan. Looking forward to reading your doc.
>
> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>
> Hi all,
>
> Just to let you know that due to a couple issues, chief among which a
> renderer crash (crbug.com/1279376), we are rolling this feature back
> from Chrome 98.
>
> A few issues have been identified and will block our next attempt at
> shipping this. In the meantime, we gathered some useful information about
> impact and notified developers of the upcoming change. I'll write a doc
> summarizing the timeline and lessons learned, then share as appropriate
> here.
>
> Cheers,
> Titouan
>
> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson 
> wrote:
>
>> LGTM3 for step 1.
>>
>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor 
>> wrote:
>>
>>> 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 
>>> 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 
 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 <
> blin...@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. 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 
>> wrote:
>>
>>> I agree!
>>>
>>> Cheers,
>>> Titouan
>>>
>

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[John Doe]

1. In Chrome 98, there were no preflight requests when accessing from 
public HTTPS to private HTTP, will the same be true in the final version?
2. In the case when I have a private HTTPS server that I want everyone to 
have access to (also via public HTTP), what options do I have ?

On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:

> Hi all,
>
> Thanks for the timely question, I was about to send an update here.
>
> We have fixed nearly all of the blockers identified in the above doc. The 
> only outstanding issue is the aforementioned crash, which required a bit 
> more design work than the rest. That work has been completed and CLs to fix 
> the problem are now in review; they should land shortly and make it in 
> Chrome 102.
>
> We would like to ship again in Chrome 102 in warning-only mode, just as we 
> last tried in Chrome 98. Preflights will be sent but their results will not 
> be enforced. Failed preflights will show warnings in DevTools, but requests 
> will otherwise continue unimpeded.
>
> Things will stay that way for at least 3 milestones. We will gather 
> compatibility data by monitoring failed preflights, then circle back here 
> to garner approvals to turn on enforcement. That launch will be accompanied 
> by a deprecation trial for web developers to sign up for a time extension 
> if they failed to notice the warnings in time.
>
> Cheers,
> Titouan
>
> On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:
>
>> Hello,  is there now an updated timeline to roll out this change?  Will 
>> the trial restart in Chrome 102 or a later version?  
>>
>> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>>
>>> Hi all,
>>>
>>> Here's the promised doc: 
>>> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>>>  
>>> (public, comment access for committers only)
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  
>>> wrote:
>>>
 Thanks for the update Titouan. Looking forward to reading your doc.

 On 2/17/22 9:25 AM, Titouan Rigoudy wrote:

 Hi all, 

 Just to let you know that due to a couple issues, chief among which a 
 renderer crash (crbug.com/1279376), we are rolling this feature back 
 from Chrome 98.

 A few issues have been identified and will block our next attempt at 
 shipping this. In the meantime, we gathered some useful information about 
 impact and notified developers of the upcoming change. I'll write a doc 
 summarizing the timeline and lessons learned, then share as appropriate 
 here.

 Cheers,
 Titouan

 On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
 wrote:

> LGTM3 for step 1.
>
> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  
> wrote:
>
>> 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  
>> 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  
>>> 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 <
 blin...@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. 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  
> wrote:
>
>> I agree! 
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  
>> 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  
>>> 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: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi all,

Thanks for the timely question, I was about to send an update here.

We have fixed nearly all of the blockers identified in the above doc. The
only outstanding issue is the aforementioned crash, which required a bit
more design work than the rest. That work has been completed and CLs to fix
the problem are now in review; they should land shortly and make it in
Chrome 102.

We would like to ship again in Chrome 102 in warning-only mode, just as we
last tried in Chrome 98. Preflights will be sent but their results will not
be enforced. Failed preflights will show warnings in DevTools, but requests
will otherwise continue unimpeded.

Things will stay that way for at least 3 milestones. We will gather
compatibility data by monitoring failed preflights, then circle back here
to garner approvals to turn on enforcement. That launch will be accompanied
by a deprecation trial for web developers to sign up for a time extension
if they failed to notice the warnings in time.

Cheers,
Titouan

On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:

> Hello,  is there now an updated timeline to roll out this change?  Will
> the trial restart in Chrome 102 or a later version?
>
> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>
>> Hi all,
>>
>> Here's the promised doc:
>> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>> (public, comment access for committers only)
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  wrote:
>>
>>> Thanks for the update Titouan. Looking forward to reading your doc.
>>>
>>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>>>
>>> Hi all,
>>>
>>> Just to let you know that due to a couple issues, chief among which a
>>> renderer crash (crbug.com/1279376), we are rolling this feature back
>>> from Chrome 98.
>>>
>>> A few issues have been identified and will block our next attempt at
>>> shipping this. In the meantime, we gathered some useful information about
>>> impact and notified developers of the upcoming change. I'll write a doc
>>> summarizing the timeline and lessons learned, then share as appropriate
>>> here.
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson 
>>> wrote:
>>>
 LGTM3 for step 1.

 On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor 
 wrote:

> 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 
> 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 
>> 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 <
>>> blin...@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. 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 
 wrote:

> I agree!
>
> Cheers,
> Titouan
>
> On Thu, Dec 2, 2021 at 5:17 PM Mike West 
> 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 
>> 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 <
>>> blin.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Logan Wei]

Hello,  is there now an updated timeline to roll out this change?  Will the 
trial restart in Chrome 102 or a later version?  

On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:

> Hi all,
>
> Here's the promised doc: 
> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>  
> (public, comment access for committers only)
>
> Cheers,
> Titouan
>
> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  wrote:
>
>> Thanks for the update Titouan. Looking forward to reading your doc.
>>
>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>>
>> Hi all, 
>>
>> Just to let you know that due to a couple issues, chief among which a 
>> renderer crash (crbug.com/1279376), we are rolling this feature back 
>> from Chrome 98.
>>
>> A few issues have been identified and will block our next attempt at 
>> shipping this. In the meantime, we gathered some useful information about 
>> impact and notified developers of the upcoming change. I'll write a doc 
>> summarizing the timeline and lessons learned, then share as appropriate 
>> here.
>>
>> Cheers,
>> Titouan
>>
>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM3 for step 1.
>>>
>>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  wrote:
>>>
 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  
 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  
> 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 <
>> blin...@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. 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  
>>> wrote:
>>>
 I agree! 

 Cheers,
 Titouan

 On Thu, Dec 2, 2021 at 5:17 PM Mike West  
 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  
> 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 <
>> blin...@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  
>>> 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 
 sce

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi all,

Here's the promised doc:
https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
(public, comment access for committers only)

Cheers,
Titouan

On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  wrote:

> Thanks for the update Titouan. Looking forward to reading your doc.
>
> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>
> Hi all,
>
> Just to let you know that due to a couple issues, chief among which a
> renderer crash (crbug.com/1279376), we are rolling this feature back from
> Chrome 98.
>
> A few issues have been identified and will block our next attempt at
> shipping this. In the meantime, we gathered some useful information about
> impact and notified developers of the upcoming change. I'll write a doc
> summarizing the timeline and lessons learned, then share as appropriate
> here.
>
> Cheers,
> Titouan
>
> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson 
> wrote:
>
>> LGTM3 for step 1.
>>
>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor 
>> wrote:
>>
>>> 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 
>>> 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 
 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. 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 
>> wrote:
>>
>>> I agree!
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
 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
>>>

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike Taylor]

Thanks for the update Titouan. Looking forward to reading your doc.

On 2/17/22 9:25 AM, Titouan Rigoudy wrote:

Hi all,

Just to let you know that due to a couple issues, chief among which a 
renderer crash (crbug.com/1279376 ), we are 
rolling this feature back from Chrome 98.


A few issues have been identified and will block our next attempt at 
shipping this. In the meantime, we gathered some useful information 
about impact and notified developers of the upcoming change. I'll 
write a doc summarizing the timeline and lessons learned, then share 
as appropriate here.


Cheers,
Titouan

On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
wrote:


LGTM3 for step 1.

On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor
 wrote:

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
 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
 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  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 .
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
 wrote:

I agree!

Cheers,
Titouan

On Thu, Dec 2, 2021 at 5:17 PM Mike West
 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  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
 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

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi all,

Just to let you know that due to a couple issues, chief among which a
renderer crash (crbug.com/1279376), we are rolling this feature back from
Chrome 98.

A few issues have been identified and will block our next attempt at
shipping this. In the meantime, we gathered some useful information about
impact and notified developers of the upcoming change. I'll write a doc
summarizing the timeline and lessons learned, then share as appropriate
here.

Cheers,
Titouan

On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson 
wrote:

> LGTM3 for step 1.
>
> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  wrote:
>
>> 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 
>> 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 
>>> 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. 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 
> wrote:
>
>> I agree!
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
>>> 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 
> 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

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Chris Harrelson]

LGTM3 for step 1.

On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  wrote:

> 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 
> 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 
>> 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. 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 
 wrote:

> I agree!
>
> Cheers,
> Titouan
>
> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
>> 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 
 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
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/572
>
> TAG review status Pending

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike Taylor]

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  
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
 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
 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
. 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
 wrote:

I agree!

Cheers,
Titouan

On Thu, Dec 2, 2021 at 5:17 PM Mike West
 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
 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
 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  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_pQ

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

*assuming I get 2 more LGTMs, that is.

On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy  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  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. 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 
>>> wrote:
>>>
 I agree!

 Cheers,
 Titouan

 On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
> 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 
>>> 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
 

 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

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

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  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. 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 
>> wrote:
>>
>>> I agree!
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
 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 
>> 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
>>> 
>>>
>>> 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 

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Yoav Weiss]

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. 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  wrote:
>
>> I agree!
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
>>> 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 
> 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
>> 
>>
>> 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/

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

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. 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  wrote:

> I agree!
>
> Cheers,
> Titouan
>
> On Thu, Dec 2, 2021 at 5:17 PM Mike West  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 
>> 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 
 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
> 
>
> 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

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

I agree!

Cheers,
Titouan

On Thu, Dec 2, 2021 at 5:17 PM Mike West  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  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 
>>> 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
 

 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 poten

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike West]

_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  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 
>> 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
>>> 
>>>
>>> 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. Exp

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike Taylor]

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




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 o

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike West]

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  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
>> 
>>
>> 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 re

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

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  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
> 
>
> 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
> 
> ? Yes
>
> DevTrial instructions
> https://github.com/WICG/private-

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Mike Taylor]

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 




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

?

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://grou

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Thanks for the responses!

Joe: the `PrivateNetworkAccessSendPreflights` feature flag will be enabled
by default in M98 (if this intent gets 3 LGTMs). The
`PrivateNetworkAccessRespectPreflightResults` will be enabled by default
later, I am aiming for M101.

On Tue, Nov 30, 2021 at 11:42 PM Erik Anderson 
wrote:

> Given this specifically calls out subresources and the design doc lists
> “the case of navigations” as “followup work,” you’re explicitly not
> touching how navigations (top-level or an iframe) work at this stage,
> correct?
>

That is correct.


> I expect the most significant compat impact to come from Windows apps that
> delegate to the default browser to do a login flow where the last step of
> the auth flow is making a request to a localhost HTTP server to pass back
> to the app an auth ticket.
>
>
>
> I anticipate most of those are top-level navigations, but my experience
> with the first version of Microsoft Edge (pre-Chromium) which prevented
> localhost loopback for subresources (including iframes), there are apps
> that handle it some other way which we broke. Some of those may have been
> passing it back via an iframe navigation (I don’t recall—it was 6+ years
> ago) in which case they’ll potentially still work after this change.
>

If they indeed use either top-level or iframe navigations, then they will
be unaffected by this change.


> The Microsoft Edge team will work to reach out to Microsoft teams that are
> potentially impacted. If the roadmap is going to eventually force a
> preflight before allowing a navigation to a private network origin, we
> would ideally include clear guidance on what’s likely coming there as well.
> Is there a general timeline you have in mind for expanding this to
> navigations as well?
>

I don't have a very clear timeline yet, but I wish to tackle nested
navigations in particular in M100.

Cheers,
Titouan


> *From:* 'Titouan Rigoudy' via blink-dev 
> *Sent:* Monday, November 29, 2021 7:37 AM
> *To:* blink-dev 
> *Subject:* [blink-dev] Intent to Ship: Private Network Access preflight
> requests for subresources
>
>
> Contact emails
>
> tito...@chromium.org, v...@chromium.org, cl...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/private-network-access/blob/main/explainer.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fprivate-network-access%2Fblob%2Fmain%2Fexplainer.md&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2O5hAhhk14yQvQKTVhQJ4IYIrdwuM6w6cOHvkf6CXkI%3D&reserved=0>
>
>
> Specification
>
> https://wicg.github.io/private-network-access/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwicg.github.io%2Fprivate-network-access%2F&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jJlAWDJEN8BL5LbJHVZYwOuYrd6cW1HEl%2FyW74NagB8%3D&reserved=0>
>
>
> Design docs
>
>
>
> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI%2Fedit&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qciJpdsRPa%2FlD61vDfbxProY3%2BU29651d5u6GxvyWfE%3D&reserved=0>
>
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253ESecurityFeature%253ECORS%253EPrivateNetworkAccess&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988

RE: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Erik Anderson' via blink-dev]

Given this specifically calls out subresources and the design doc lists "the 
case of navigations" as "followup work," you're explicitly not touching how 
navigations (top-level or an iframe) work at this stage, correct?

I expect the most significant compat impact to come from Windows apps that 
delegate to the default browser to do a login flow where the last step of the 
auth flow is making a request to a localhost HTTP server to pass back to the 
app an auth ticket.

I anticipate most of those are top-level navigations, but my experience with 
the first version of Microsoft Edge (pre-Chromium) which prevented localhost 
loopback for subresources (including iframes), there are apps that handle it 
some other way which we broke. Some of those may have been passing it back via 
an iframe navigation (I don't recall-it was 6+ years ago) in which case they'll 
potentially still work after this change.

The Microsoft Edge team will work to reach out to Microsoft teams that are 
potentially impacted. If the roadmap is going to eventually force a preflight 
before allowing a navigation to a private network origin, we would ideally 
include clear guidance on what's likely coming there as well. Is there a 
general timeline you have in mind for expanding this to navigations as well?

From: 'Titouan Rigoudy' via blink-dev 
Sent: Monday, November 29, 2021 7:37 AM
To: blink-dev 
Subject: [blink-dev] Intent to Ship: Private Network Access preflight requests 
for subresources

Contact emails
tito...@chromium.org<mailto:tito...@chromium.org>, 
v...@chromium.org<mailto:v...@chromium.org>, 
cl...@chromium.org<mailto:cl...@chromium.org>


Explainer
https://github.com/WICG/private-network-access/blob/main/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fprivate-network-access%2Fblob%2Fmain%2Fexplainer.md&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2O5hAhhk14yQvQKTVhQJ4IYIrdwuM6w6cOHvkf6CXkI%3D&reserved=0>


Specification
https://wicg.github.io/private-network-access/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwicg.github.io%2Fprivate-network-access%2F&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jJlAWDJEN8BL5LbJHVZYwOuYrd6cW1HEl%2FyW74NagB8%3D&reserved=0>


Design docs

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI%2Fedit&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qciJpdsRPa%2FlD61vDfbxProY3%2BU29651d5u6GxvyWfE%3D&reserved=0>


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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253ESecurityFeature%253ECORS%253EPrivateNetworkAccess&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469545884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BpzABpjfTWfZBd1EXZSnRA5ZxzMBGW205bfxDJbIQeE%3D&reserved=0>


TAG review
https://github.com/w3ctag/design-reviews/issues/572<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F572&data=04%7C01%7Cerik.anderson%40microsoft.com%7Cd326417d74594f3438d708d9b34e230f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637737970469595876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jXbqAH3Yorpra2PYzN9MlrV0ciU%2B63GcXmixjqlojT4%3D&reserved=0>


TAG review status
Pending


Risks

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Joe Medley' via blink-dev]

Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available.
'Shipping' refers to when it can be used in production without web
developers or users doing anything. This can mean the flag was removed or
it can mean the flag's default was changed to 'Enabled'.

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Nov 29, 2021 at 7:37 AM 'Titouan Rigoudy' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org
>
> Explainer
> https://github.com/WICG/private-network-access/blob/main/explainer.md
>
> Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572
>
> TAG review statusPending
>
> 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
> 
> ?Yes
>
> DevTrial instructions
> https://github.com/WICG/private-network-access/blob/main/HOWTO.md
>
> Flag namePrivateNetworkAccessRespectPreflightResults
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/591068
>
> Launch bughttps://crbug.com/1274149
>
> Estimated milestones
> DevTrial on desktop 98
> DevTrial on andr

[blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org

Explainer
https://github.com/WICG/private-network-access/blob/main/explainer.md

Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572

TAG review statusPending

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

?Yes

DevTrial instructions
https://github.com/WICG/private-network-access/blob/main/HOWTO.md

Flag namePrivateNetworkAccessRespectPreflightResults

Requires code in //chrome?False

Tracking bughttps://crbug.com/591068

Launch bughttps://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 discussionsIntent 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
.

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