Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-22 Thread Daniel Bratell 
LGTM3 - I agree that those local peaks are not scary enough so this 
should be ok to ship.


(This might be a duplicate but I'm not going to wait any longer for my 
first mail to arrive!)


/Daniel

On 2022-06-22 17:56, Mike Taylor wrote:

LGTM2

On 6/22/22 11:56 AM, Chris Harrelson wrote:

LGTM1

On Thu, Jun 16, 2022 at 11:38 AM Johann Hofmann 
 wrote:


Thanks everyone, a quick update:

Thank you Martin for chiming in, I really appreciate your
comment! I updated the Chromestatus entry to reflect the browser
signals more accurately.

I also sent a request for position

to webkit-dev.

Addressing Mike's and Daniel's concern about localized hot spots
(sorry for the delay):

Looking at global usage data, it seems to be consistently low in
all countries. There are some regional differences, with Brazil,
Croatia and Belarus having slightly elevated usage at 0.2%, all
likely subject to randomness/noise as we're looking at a very
small subset of data at this point. We might be able to find out
more about those during deprecation, but overall I'm not very
concerned.

Thanks!

Johann

On Thu, Jun 9, 2022 at 1:49 AM Daniel Bratell
 wrote:


On 2022-06-09 04:22, Martin Thomson wrote:

On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell
 wrote:

If Mozilla is already shipping this behaviour, then
there is no need to ask them if they support that
change. We do assume that they approve of all
functionality they are shipping.

I want to address this point, as I think Chris Harrelson has
done.  Just because something ships in Firefox, that doesn't
mean we think that it is good for the web.  There's
something of a long list of things we don't like, but ship
for various reasons despite that.  To pick an example that
isn't particularly controversial, we still ship unsecured HTTP.

So we do appreciate you asking directly rather than making
inferences and then potentially misrepresenting our position.

To save a bit of time on this bit of minutiae: this change
is good and the work that Johann, Mike, and others on the
Chrome team have done to improve compatibility with cookies
is greatly appreciated.


Correction appreciated! I was way too cavalier with that
statement.

/Daniel

-- 
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/CAD_OO4hs%2BgbCuXxWgOmVoVQ9zv9hRnnKYwi%2BMS9ciX76%3DVD%2Buw%40mail.gmail.com

.





--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d331ba4c-593a-f7f6-ad28-4c42c991b05d%40gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-22 Thread Mike Taylor 

LGTM2

On 6/22/22 11:56 AM, Chris Harrelson wrote:

LGTM1

On Thu, Jun 16, 2022 at 11:38 AM Johann Hofmann 
 wrote:


Thanks everyone, a quick update:

Thank you Martin for chiming in, I really appreciate your comment!
I updated the Chromestatus entry to reflect the browser signals
more accurately.

I also sent a request for position

to webkit-dev.

Addressing Mike's and Daniel's concern about localized hot spots
(sorry for the delay):

Looking at global usage data, it seems to be consistently low in
all countries. There are some regional differences, with Brazil,
Croatia and Belarus having slightly elevated usage at 0.2%, all
likely subject to randomness/noise as we're looking at a very
small subset of data at this point. We might be able to find out
more about those during deprecation, but overall I'm not very
concerned.

Thanks!

Johann

On Thu, Jun 9, 2022 at 1:49 AM Daniel Bratell
 wrote:


On 2022-06-09 04:22, Martin Thomson wrote:

On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell
 wrote:

If Mozilla is already shipping this behaviour, then there
is no need to ask them if they support that change. We do
assume that they approve of all functionality they are
shipping.

I want to address this point, as I think Chris Harrelson has
done.  Just because something ships in Firefox, that doesn't
mean we think that it is good for the web.  There's something
of a long list of things we don't like, but ship for various
reasons despite that.  To pick an example that isn't
particularly controversial, we still ship unsecured HTTP.

So we do appreciate you asking directly rather than making
inferences and then potentially misrepresenting our position.

To save a bit of time on this bit of minutiae: this change is
good and the work that Johann, Mike, and others on the Chrome
team have done to improve compatibility with cookies is
greatly appreciated.


Correction appreciated! I was way too cavalier with that
statement.

/Daniel

-- 
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/CAD_OO4hs%2BgbCuXxWgOmVoVQ9zv9hRnnKYwi%2BMS9ciX76%3DVD%2Buw%40mail.gmail.com

.



--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ea519522-320a-8592-30cd-4684ff459724%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-22 Thread Chris Harrelson 
LGTM1

On Thu, Jun 16, 2022 at 11:38 AM Johann Hofmann 
wrote:

> Thanks everyone, a quick update:
>
> Thank you Martin for chiming in, I really appreciate your comment! I
> updated the Chromestatus entry to reflect the browser signals more
> accurately.
>
> I also sent a request for position
>  to
> webkit-dev.
>
> Addressing Mike's and Daniel's concern about localized hot spots (sorry
> for the delay):
>
> Looking at global usage data, it seems to be consistently low in all
> countries. There are some regional differences, with Brazil, Croatia and
> Belarus having slightly elevated usage at 0.2%, all likely subject to
> randomness/noise as we're looking at a very small subset of data at this
> point. We might be able to find out more about those during
> deprecation, but overall I'm not very concerned.
>
> Thanks!
>
> Johann
>
> On Thu, Jun 9, 2022 at 1:49 AM Daniel Bratell  wrote:
>
>>
>> On 2022-06-09 04:22, Martin Thomson wrote:
>>
>> On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell 
>> wrote:
>>
>>> If Mozilla is already shipping this behaviour, then there is no need to
>>> ask them if they support that change. We do assume that they approve of all
>>> functionality they are shipping.
>>>
>> I want to address this point, as I think Chris Harrelson has done.  Just
>> because something ships in Firefox, that doesn't mean we think that it is
>> good for the web.  There's something of a long list of things we don't
>> like, but ship for various reasons despite that.  To pick an example that
>> isn't particularly controversial, we still ship unsecured HTTP.
>>
>> So we do appreciate you asking directly rather than making inferences and
>> then potentially misrepresenting our position.
>>
>> To save a bit of time on this bit of minutiae: this change is good and
>> the work that Johann, Mike, and others on the Chrome team have done to
>> improve compatibility with cookies is greatly appreciated.
>>
>> Correction appreciated! I was way too cavalier with that statement.
>>
>> /Daniel
>>
> --
> 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/CAD_OO4hs%2BgbCuXxWgOmVoVQ9zv9hRnnKYwi%2BMS9ciX76%3DVD%2Buw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9hv1%3DsbnTf_36t8%2B5dVC-N6iCA5aFznw6SHTB%2BpuySFA%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-16 Thread Johann Hofmann 
Thanks everyone, a quick update:

Thank you Martin for chiming in, I really appreciate your comment! I
updated the Chromestatus entry to reflect the browser signals more
accurately.

I also sent a request for position
 to
webkit-dev.

Addressing Mike's and Daniel's concern about localized hot spots (sorry for
the delay):

Looking at global usage data, it seems to be consistently low in all
countries. There are some regional differences, with Brazil, Croatia and
Belarus having slightly elevated usage at 0.2%, all likely subject to
randomness/noise as we're looking at a very small subset of data at this
point. We might be able to find out more about those during
deprecation, but overall I'm not very concerned.

Thanks!

Johann

On Thu, Jun 9, 2022 at 1:49 AM Daniel Bratell  wrote:

>
> On 2022-06-09 04:22, Martin Thomson wrote:
>
> On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell 
> wrote:
>
>> If Mozilla is already shipping this behaviour, then there is no need to
>> ask them if they support that change. We do assume that they approve of all
>> functionality they are shipping.
>>
> I want to address this point, as I think Chris Harrelson has done.  Just
> because something ships in Firefox, that doesn't mean we think that it is
> good for the web.  There's something of a long list of things we don't
> like, but ship for various reasons despite that.  To pick an example that
> isn't particularly controversial, we still ship unsecured HTTP.
>
> So we do appreciate you asking directly rather than making inferences and
> then potentially misrepresenting our position.
>
> To save a bit of time on this bit of minutiae: this change is good and the
> work that Johann, Mike, and others on the Chrome team have done to improve
> compatibility with cookies is greatly appreciated.
>
> Correction appreciated! I was way too cavalier with that statement.
>
> /Daniel
>

-- 
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/CAD_OO4hs%2BgbCuXxWgOmVoVQ9zv9hRnnKYwi%2BMS9ciX76%3DVD%2Buw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-09 Thread Martin Thomson 
On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell  wrote:

> If Mozilla is already shipping this behaviour, then there is no need to
> ask them if they support that change. We do assume that they approve of all
> functionality they are shipping.
>
I want to address this point, as I think Chris Harrelson has done.  Just
because something ships in Firefox, that doesn't mean we think that it is
good for the web.  There's something of a long list of things we don't
like, but ship for various reasons despite that.  To pick an example that
isn't particularly controversial, we still ship unsecured HTTP.

So we do appreciate you asking directly rather than making inferences and
then potentially misrepresenting our position.

To save a bit of time on this bit of minutiae: this change is good and the
work that Johann, Mike, and others on the Chrome team have done to improve
compatibility with cookies is greatly appreciated.

-- 
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/CAPLxc%3DVS9cAg7tGDRoT43sgKFeBscaExMMsgOjaX3YR-_dH6OQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-08 Thread Daniel Bratell 


On 2022-06-09 04:22, Martin Thomson wrote:
On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell  
wrote:


If Mozilla is already shipping this behaviour, then there is no
need to ask them if they support that change. We do assume that
they approve of all functionality they are shipping.

I want to address this point, as I think Chris Harrelson has done.  
Just because something ships in Firefox, that doesn't mean we think 
that it is good for the web.  There's something of a long list of 
things we don't like, but ship for various reasons despite that.  To 
pick an example that isn't particularly controversial, we still ship 
unsecured HTTP.


So we do appreciate you asking directly rather than making inferences 
and then potentially misrepresenting our position.


To save a bit of time on this bit of minutiae: this change is good and 
the work that Johann, Mike, and others on the Chrome team have done to 
improve compatibility with cookies is greatly appreciated.


Correction appreciated! I was way too cavalier with that statement.

/Daniel

--
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/92317aa0-bb65-9f43-92c4-31fb3f0dd8b8%40gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-08 Thread Johann Hofmann 
Understood, thanks for clarifying that, Chris!

On Wed, Jun 8, 2022 at 5:28 PM Chris Harrelson 
wrote:

>
>
> On Wed, Jun 8, 2022 at 12:14 AM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, June 6, 2022 at 6:57:53 AM UTC+2 Johann Hofmann wrote:
>>
>>> Hi Mike and Yoav, thank you for the guidance.
>>>
>>> Regarding public use counters, devtools messaging, reporting and getting
>>> more precise information on domains:
>>> I'm working on getting a devtools deprecation warning in place, and the
>>> other pieces should be easy to integrate from there, according to sbingler.
>>> Happy to report back once that's done.
>>>
>>
>> That's great, thanks!!
>>
>>
>>>
>>> > What's the deprecation period you had in mind?
>>>
>>> Usage is quite low but there's also no particular rush on this, so I was
>>> thinking of a deprecation period of two releases after we get developer
>>> warnings in place, which might happen by M105, so estimated M107.
>>>
>>
>> Sounds reasonable.
>>
>>
>>>
>>> > Our typical process for getting such signals is
>>> https://bit.ly/blink-signals
>>>
>>> Huh! I read that document and interpreted "Statement made through an
>>> Official Standards Process for that implementation" as given since both
>>> Mozilla and Apple voiced their support in the HTTP WG. If this is the case,
>>> asking them to confirm via their standards positions channels feels
>>> somewhat noisy, no?
>>>
>>
>> IIRC, WebKit folks were fine with quoting support from webkit engineers
>> as a replacement for an official request, but Mozilla were not. In this
>> case, this may be sufficient.
>> Chris - do I remember correctly? Should we add such an exception to our
>> docs?
>>
>
> Unfortunately this doesn't count as a signal. An email to webkit-dev is
> required, with response, to count as anything other than "No signals". I'm
> glad they agreed to this change in the HTTP WG though, that's a good sign.
>
> Also, I can see how "Official Standards Process" can be construed as an
> ambiguous term; I've clarified to "Official Standards Signal Process" in
> the signals document that it means the process spelled out in the last
> section there.
>
>
>>
>>
>>>
>>> > At the same time, as you said above, Mozilla is already shipping
>>> 
>>>  the
>>> behavior you want to align on here.
>>>
>>> Right, I'll update the status to "Shipping", apologies.
>>>
>>> > Can you send a request to webkit-dev, letting them know that we're
>>> moving on that front?
>>>
>>> I'm happy to do that, or alternatively ping John on the GitHub issue if
>>> you agree with me that this is preferable (being more targeted and less
>>> noisy) to an email to webkit-dev.
>>>
>>> Thanks!
>>>
>>>
>>> On Fri, Jun 3, 2022 at 3:09 PM Mike Taylor 
>>> wrote:
>>>
 On 6/3/22 6:42 AM, Yoav Weiss wrote:

 What's the deprecation period you had in mind?

 Also, from a technical perspective, it might be worthwhile to talk to
 folks that did past cookie related deprecations, to make sure you're
 reusing the same path for reporting them to the devtools. Also also, it'd
 be great if that deprecation would result in Deprecation Reports, if at all
 feasible.

 On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
 wrote:

> Contact emails johann...@chromium.org
>
> Explainer None
>
> Specification
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5
>
> Summary
>
> To align with the latest specification in RFC 6265bis, Chromium will
> reject cookies with a "Domain" attribute that contains a non-ASCII
> character (e.g. Domain=éxample.com
> ).
>
>
> Blink component Blink>Network
> 
>
> Motivation
>
> Support for IDN domain attributes in cookies has been long
> unspecified, with Chromium, Safari and Firefox all behaving differently.
> https://github.com/httpwg/http-extensions/issues/1707 fixes this
> issue by standardizing Firefox's behavior of rejecting cookies with
> non-ASCII domain attributes. Since Chromium has previously accepted
> non-ASCII characters and tried to convert them to normalized punycode for
> storage, we will now apply stricter rules and require valid ASCII 
> (punycode
> if applicable) domain attributes.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is a general risk of breakage compared to past Chromium versions
> from rejecting previously accepted cookies, but UMA measurements show the
> percentage of cookies with non-ASCII characters (including potentially
> invalid cookies) to be below 0.0001%.
>

 Any public use counters you could share?

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-08 Thread Chris Harrelson 
On Wed, Jun 8, 2022 at 12:14 AM Yoav Weiss  wrote:

>
>
> On Monday, June 6, 2022 at 6:57:53 AM UTC+2 Johann Hofmann wrote:
>
>> Hi Mike and Yoav, thank you for the guidance.
>>
>> Regarding public use counters, devtools messaging, reporting and getting
>> more precise information on domains:
>> I'm working on getting a devtools deprecation warning in place, and the
>> other pieces should be easy to integrate from there, according to sbingler.
>> Happy to report back once that's done.
>>
>
> That's great, thanks!!
>
>
>>
>> > What's the deprecation period you had in mind?
>>
>> Usage is quite low but there's also no particular rush on this, so I was
>> thinking of a deprecation period of two releases after we get developer
>> warnings in place, which might happen by M105, so estimated M107.
>>
>
> Sounds reasonable.
>
>
>>
>> > Our typical process for getting such signals is
>> https://bit.ly/blink-signals
>>
>> Huh! I read that document and interpreted "Statement made through an
>> Official Standards Process for that implementation" as given since both
>> Mozilla and Apple voiced their support in the HTTP WG. If this is the case,
>> asking them to confirm via their standards positions channels feels
>> somewhat noisy, no?
>>
>
> IIRC, WebKit folks were fine with quoting support from webkit engineers as
> a replacement for an official request, but Mozilla were not. In this case,
> this may be sufficient.
> Chris - do I remember correctly? Should we add such an exception to our
> docs?
>

Unfortunately this doesn't count as a signal. An email to webkit-dev is
required, with response, to count as anything other than "No signals". I'm
glad they agreed to this change in the HTTP WG though, that's a good sign.

Also, I can see how "Official Standards Process" can be construed as an
ambiguous term; I've clarified to "Official Standards Signal Process" in
the signals document that it means the process spelled out in the last
section there.


>
>
>>
>> > At the same time, as you said above, Mozilla is already shipping
>> 
>>  the
>> behavior you want to align on here.
>>
>> Right, I'll update the status to "Shipping", apologies.
>>
>> > Can you send a request to webkit-dev, letting them know that we're
>> moving on that front?
>>
>> I'm happy to do that, or alternatively ping John on the GitHub issue if
>> you agree with me that this is preferable (being more targeted and less
>> noisy) to an email to webkit-dev.
>>
>> Thanks!
>>
>>
>> On Fri, Jun 3, 2022 at 3:09 PM Mike Taylor 
>> wrote:
>>
>>> On 6/3/22 6:42 AM, Yoav Weiss wrote:
>>>
>>> What's the deprecation period you had in mind?
>>>
>>> Also, from a technical perspective, it might be worthwhile to talk to
>>> folks that did past cookie related deprecations, to make sure you're
>>> reusing the same path for reporting them to the devtools. Also also, it'd
>>> be great if that deprecation would result in Deprecation Reports, if at all
>>> feasible.
>>>
>>> On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
>>> wrote:
>>>
 Contact emails johann...@chromium.org

 Explainer None

 Specification
 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5

 Summary

 To align with the latest specification in RFC 6265bis, Chromium will
 reject cookies with a "Domain" attribute that contains a non-ASCII
 character (e.g. Domain=éxample.com
 ).


 Blink component Blink>Network
 

 Motivation

 Support for IDN domain attributes in cookies has been long unspecified,
 with Chromium, Safari and Firefox all behaving differently.
 https://github.com/httpwg/http-extensions/issues/1707 fixes this issue
 by standardizing Firefox's behavior of rejecting cookies with non-ASCII
 domain attributes. Since Chromium has previously accepted non-ASCII
 characters and tried to convert them to normalized punycode for storage, we
 will now apply stricter rules and require valid ASCII (punycode if
 applicable) domain attributes.


 Initial public proposal

 TAG review

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility

 There is a general risk of breakage compared to past Chromium versions
 from rejecting previously accepted cookies, but UMA measurements show the
 percentage of cookies with non-ASCII characters (including potentially
 invalid cookies) to be below 0.0001%.

>>>
>>> Any public use counters you could share?
>>> Or is that something we couldn't add due to cookies being processed
>>> outside the renderer?
>>>
>>> Usage is quite low, but it would be good to know if there are any
>>> patterns that might affect certain locales more than others. Is there any
>>> way we can

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-05 Thread Johann Hofmann 
Hi Mike and Yoav, thank you for the guidance.

Regarding public use counters, devtools messaging, reporting and getting
more precise information on domains:
I'm working on getting a devtools deprecation warning in place, and the
other pieces should be easy to integrate from there, according to sbingler.
Happy to report back once that's done.

> What's the deprecation period you had in mind?

Usage is quite low but there's also no particular rush on this, so I was
thinking of a deprecation period of two releases after we get developer
warnings in place, which might happen by M105, so estimated M107.

> Our typical process for getting such signals is
https://bit.ly/blink-signals

Huh! I read that document and interpreted "Statement made through an
Official Standards Process for that implementation" as given since both
Mozilla and Apple voiced their support in the HTTP WG. If this is the case,
asking them to confirm via their standards positions channels feels
somewhat noisy, no?

> At the same time, as you said above, Mozilla is already shipping

the
behavior you want to align on here.

Right, I'll update the status to "Shipping", apologies.

> Can you send a request to webkit-dev, letting them know that we're moving
on that front?

I'm happy to do that, or alternatively ping John on the GitHub issue if you
agree with me that this is preferable (being more targeted and less noisy)
to an email to webkit-dev.

Thanks!


On Fri, Jun 3, 2022 at 3:09 PM Mike Taylor  wrote:

> On 6/3/22 6:42 AM, Yoav Weiss wrote:
>
> What's the deprecation period you had in mind?
>
> Also, from a technical perspective, it might be worthwhile to talk to
> folks that did past cookie related deprecations, to make sure you're
> reusing the same path for reporting them to the devtools. Also also, it'd
> be great if that deprecation would result in Deprecation Reports, if at all
> feasible.
>
> On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
> wrote:
>
>> Contact emails johann...@chromium.org
>>
>> Explainer None
>>
>> Specification
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5
>>
>> Summary
>>
>> To align with the latest specification in RFC 6265bis, Chromium will
>> reject cookies with a "Domain" attribute that contains a non-ASCII
>> character (e.g. Domain=éxample.com 
>> ).
>>
>>
>> Blink component Blink>Network
>> 
>>
>> Motivation
>>
>> Support for IDN domain attributes in cookies has been long unspecified,
>> with Chromium, Safari and Firefox all behaving differently.
>> https://github.com/httpwg/http-extensions/issues/1707 fixes this issue
>> by standardizing Firefox's behavior of rejecting cookies with non-ASCII
>> domain attributes. Since Chromium has previously accepted non-ASCII
>> characters and tried to convert them to normalized punycode for storage, we
>> will now apply stricter rules and require valid ASCII (punycode if
>> applicable) domain attributes.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is a general risk of breakage compared to past Chromium versions
>> from rejecting previously accepted cookies, but UMA measurements show the
>> percentage of cookies with non-ASCII characters (including potentially
>> invalid cookies) to be below 0.0001%.
>>
>
> Any public use counters you could share?
> Or is that something we couldn't add due to cookies being processed
> outside the renderer?
>
> Usage is quite low, but it would be good to know if there are any patterns
> that might affect certain locales more than others. Is there any way we can
> get a sample list of domains to spot check?
>
>
>
>> This change improves interoperability by aligning with what Firefox is
>> shipping and what Safari aims to ship as well.
>>
>>
>> *Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>>
>> *WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707
>> )
>>
>
> Our typical process for getting such signals is
> https://bit.ly/blink-signals
> At the same time, as you said above, Mozilla is already shipping
> 
> the behavior you want to align on here.
> Can you send a request to webkit-dev, letting them know that we're moving
> on that front?
>
>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> TBD
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> Flag name
>>
>> Requires

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-03 Thread Mike Taylor 

On 6/3/22 6:42 AM, Yoav Weiss wrote:

What's the deprecation period you had in mind?

Also, from a technical perspective, it might be worthwhile to talk to 
folks that did past cookie related deprecations, to make sure you're 
reusing the same path for reporting them to the devtools. Also also, 
it'd be great if that deprecation would result in Deprecation Reports, 
if at all feasible.


On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
 wrote:



Contact emails

johann...@chromium.org


Explainer

None


Specification


https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5


Summary

To align with the latest specification in RFC 6265bis, Chromium
will reject cookies with a "Domain" attribute that contains a
non-ASCII character (e.g. Domain=éxample.com
).



Blink component

Blink>Network




Motivation

Support for IDN domain attributes in cookies has been long
unspecified, with Chromium, Safari and Firefox all behaving
differently. https://github.com/httpwg/http-extensions/issues/1707
fixes this issue by standardizing Firefox's behavior of rejecting
cookies with non-ASCII domain attributes. Since Chromium has
previously accepted non-ASCII characters and tried to convert them
to normalized punycode for storage, we will now apply stricter
rules and require valid ASCII (punycode if applicable) domain
attributes.



Initial public proposal



TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium
versions from rejecting previously accepted cookies, but UMA
measurements show the percentage of cookies with non-ASCII
characters (including potentially invalid cookies) to be below
0.0001%.


Any public use counters you could share?
Or is that something we couldn't add due to cookies being processed 
outside the renderer?
Usage is quite low, but it would be good to know if there are any 
patterns that might affect certain locales more than others. Is there 
any way we can get a sample list of domains to spot check?


This change improves interoperability by aligning with what
Firefox is shipping and what Safari aims to ship as well.



/Gecko/: Positive
(https://github.com/httpwg/http-extensions/issues/1707)

/WebKit/: Positive
(https://github.com/httpwg/http-extensions/issues/1707)


Our typical process for getting such signals is 
https://bit.ly/blink-signals
At the same time, as you said above, Mozilla is already shipping 
 
the behavior you want to align on here.
Can you send a request to webkit-dev, letting them know that we're 
moving on that front?



/Web developers/: No signals

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?



Debuggability

TBD



Is this feature fully tested by web-platform-tests

?

Yes


Flag name



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1296537


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5534966262792192

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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com

.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-03 Thread Yoav Weiss 
What's the deprecation period you had in mind?

Also, from a technical perspective, it might be worthwhile to talk to folks
that did past cookie related deprecations, to make sure you're reusing the
same path for reporting them to the devtools. Also also, it'd be great if
that deprecation would result in Deprecation Reports, if at all feasible.

On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
wrote:

> Contact emailsjohann...@chromium.org
>
> ExplainerNone
>
> Specification
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5
>
> Summary
>
> To align with the latest specification in RFC 6265bis, Chromium will
> reject cookies with a "Domain" attribute that contains a non-ASCII
> character (e.g. Domain=éxample.com ).
>
>
> Blink componentBlink>Network
> 
>
> Motivation
>
> Support for IDN domain attributes in cookies has been long unspecified,
> with Chromium, Safari and Firefox all behaving differently.
> https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by
> standardizing Firefox's behavior of rejecting cookies with non-ASCII domain
> attributes. Since Chromium has previously accepted non-ASCII characters and
> tried to convert them to normalized punycode for storage, we will now apply
> stricter rules and require valid ASCII (punycode if applicable) domain
> attributes.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is a general risk of breakage compared to past Chromium versions
> from rejecting previously accepted cookies, but UMA measurements show the
> percentage of cookies with non-ASCII characters (including potentially
> invalid cookies) to be below 0.0001%.
>

Any public use counters you could share?
Or is that something we couldn't add due to cookies being processed outside
the renderer?


> This change improves interoperability by aligning with what Firefox is
> shipping and what Safari aims to ship as well.
>
>
> *Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>
> *WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>

Our typical process for getting such signals is https://bit.ly/blink-signals
At the same time, as you said above, Mozilla is already shipping

the behavior you want to align on here.
Can you send a request to webkit-dev, letting them know that we're moving
on that front?


> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Debuggability
>
> TBD
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1296537
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5534966262792192
>
> 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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com.

[blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

2022-06-03 Thread Johann Hofmann 
Contact emailsjohann...@chromium.org

ExplainerNone

Specification
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5

Summary

To align with the latest specification in RFC 6265bis, Chromium will reject
cookies with a "Domain" attribute that contains a non-ASCII character (e.g.
Domain=éxample.com ).


Blink componentBlink>Network


Motivation

Support for IDN domain attributes in cookies has been long unspecified,
with Chromium, Safari and Firefox all behaving differently.
https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by
standardizing Firefox's behavior of rejecting cookies with non-ASCII domain
attributes. Since Chromium has previously accepted non-ASCII characters and
tried to convert them to normalized punycode for storage, we will now apply
stricter rules and require valid ASCII (punycode if applicable) domain
attributes.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium versions from
rejecting previously accepted cookies, but UMA measurements show the
percentage of cookies with non-ASCII characters (including potentially
invalid cookies) to be below 0.0001%. This change improves interoperability
by aligning with what Firefox is shipping and what Safari aims to ship as
well.


*Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)

*WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707)

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability

TBD


Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1296537

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5534966262792192

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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com.