On Fri, Sep 17, 2021 at 6:36 PM Steven Bingler <bing...@chromium.org>
wrote:
Hi Ian and Yoav,
I believe the general guidance now for warning users of some
change is to use DevTools Issues rather than console warnings.
Would using Issues, instead of console warnings, be acceptable to
you? (This would be in addition to the reports.)
I don't believe the API OWNERS have a stand on console warnings vs.
issues for deprecations. Whatever is the general guidance that will
make this visible for developers seems good to me, assuming that
issues are prominent in the UI and manage to grab the median
developer's attention.
Also, for posterity, it is possible to emit a console warning
starting from EmitCookieWarningsAndMetrics() with a little work.
We used to do just that for SameSite warnings before we
transitioned them to DevTools Issue [1
<https://chromium.googlesource.com/chromium/src.git/+/1cc31f46c2e6ae658a97b92fbc8c556eba382d3e/content/browser/frame_host/cookie_utils.cc#128>]
[2
<https://chromium.googlesource.com/chromium/src.git/+/1cc31f46c2e6ae658a97b92fbc8c556eba382d3e/content/browser/frame_host/render_frame_host_impl.cc#8309>]
(many refactors ago). It looks like most of the necessary
functions still exist, so it shouldn't be too hard to recreate
that functionality if needed.
Thanks,
Steven
On Friday, September 17, 2021 at 8:45:10 AM UTC-7 Andrew Williams
wrote:
Thanks for the feedback Mike, Yoav, and Ian. I will explore
the feasibility of using CountDeprecation (or something
similar) from the cookie-related code and will report back
once I have an update on this.
-Andrew
On Fri, Sep 10, 2021 at 10:11 AM Ian Clelland
<iclell...@chromium.org> wrote:
That looks right -- that code path won't get you anywhere
near adding a console message, as far as I can tell, but
you would be able to queue a report that way. Ideally,
we'd have something like deprecation.cc for browser-side
that would handle the UMA as well as formatting the report
body consistently. As a first pass, until we have more
that one browser-generated deprecation report, just
generating and queuing it would work.
On Fri, Sep 10, 2021 at 6:42 AM Yoav Weiss
<yoavwe...@chromium.org> wrote:
I may very well be wrong, but it seems like
CookieUtils::EmitCookieWarningsAndMetrics
<https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/cookie_utils.cc;l=97;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a;bpv=1;bpt=1>
has
the right plumbing to reach RenderFrameHost, and from
it, get a ReportingSource
<https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=1730;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a?q=RenderFrameHost&ss=chromium%2Fchromium%2Fsrc>
that
can enable us to send
<https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=10676;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a;bpv=1;bpt=1?q=RenderFrameHost&ss=chromium%2Fchromium%2Fsrc>
deprecation reports (even if through a different
mechanism than CountDeprecation).
Ian - thoughts on the above?
On Thu, Sep 9, 2021 at 9:21 PM Mike West
<mk...@chromium.org> wrote:
I don't think `countDeprecation` is going to work
here, insofar as that's a Blink-layer concept, and
the network stack isn't going to have an
understanding of page views or use counters or
etc. If we've wired things up such that
deprecation reports can be triggered from the
network stack, lovely, but I'm not sure that's the
case.
Another approach that might be reasonable to
approach might be to roll this out on a
percentage-basis, starting with a substantial
portion of beta, then rolling to stable iff we're
confident in that experience?
This feels like both the right directional and
philosophical thing to do with cookies. I'd like
to see it ship, and a staged rollout might well be
a reasonable way of gaining confidence in our
ability to do so?
-mike
On Thu, Sep 9, 2021 at 1:03 PM Yoav Weiss
<yoavwe...@chromium.org> wrote:
Sounds good! Can you please ping this thread
once results start coming in? Thanks! :)
On Wednesday, September 8, 2021 at 3:59:36 AM
UTC+2 Andrew Williams wrote:
Sounds good - we will add the
CountDeprecation metrics. Thanks for the
suggestion, Yoav, and thank you Ian for
the additional info.
-Andrew
On Fri, Sep 3, 2021 at 10:07 AM Ian
Clelland <iclell...@chromium.org> wrote:
On Fri, Sep 3, 2021 at 4:55 AM Yoav
Weiss <yoavwe...@chromium.org> wrote:
Hey Andrew,
Given that the metrics are not a
superset of what you're trying to
deprecate, could you please add
CountDeprecation
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation.cc;drc=f6f22e82bcd0d50f390b23ee9688c58de5ae0bdc;bpv=1;bpt=1;l=702?q=deprecation&ss=chromium>
metrics of the case you are
intending to deprecate? That would
ensure .e.g deprecation reports
are sent to folks that happen to
have such cookies.
Even though you haven't really
asked, from my perspective, it's
also fine to add a console
deprecation message at this point,
in parallel to the metrics.
FYI, CountDeprecation will take care
of adding that console message for
you, as well as:
- Generating a report object which
can be seen with a ReportingObserver,
- Sending that report to any
configured endpoints for the document, and
- Counting the usage for UMA, so that
we can track the (hopefully) declining
usage of the deprecated feature.
Ian
Cheers :)
Yoav
On Wednesday, September 1, 2021 at
5:05:44 PM UTC+2 Andrew Williams
wrote:
Here is the percentage for the
metric mentioned in my last
email: over a 7 day period,
0.00004% of cookies seen in
the stable version of Chrome
had truncated names and/or values.
Ultimately our plan is to ship
this feature behind a kill
switch that we could flip if
major issues are reported.
With that in mind, and given
the low number of truncated
cookie names/values observed
via our existing metrics,
would it make sense to
implement and collect the new
metrics in parallel with
rolling out the changes
described in this I2P&S? Or do
you think taking the more
cautious approach and
implementing/collecting the
new metrics before landing
this change is a better way
forward (despite taking more
time)?
-Andrew
On Fri, Aug 27, 2021 at 1:45
PM Andrew Williams
<awil...@chromium.org> wrote:
Thanks for the
feedback/questions Yoav
and Daniel.
We have some metrics
<https://source.chromium.org/chromium/chromium/src/+/700dc7fe1578ab5e0e50a6304f2a1960005b8f8b:tools/metrics/histograms/metadata/cookie/histograms.xml;l=56;bpv=1;bpt=0>
on Chrome's existing
behavior to truncate
cookie lines containing
\x00, \x0d, and \x0a
(specifically, in cases
where the truncation
affects the cookie name or
the cookie value). The
percentage of cookies with
truncated names or values
is quite low, although I'm
still waiting on approval
to release the exact
percentage. We don't have
any metrics for cases
where truncation affected
cookie attribute parsing
(for example, the
malicious case this intent
aims to address) or where
truncation was harmless
(for example, a newline as
the last character in the
cookie line), though.
Especially for the latter
case, it does seem
plausible that certain
sites could be
constructing cookie lines
in such a way that control
characters slip in
unnoticed. We will add
new metrics to cover these
cases so that we can
better predict the level
of breakage that these
changes may have.
-Andrew
On Thu, Aug 26, 2021 at
2:22 PM Daniel Bratell
<bratel...@gmail.com> wrote:
Even if browsers are
currently slightly
incompatible, it seems
this change will short
term make them more
incompatible. As Yoav
said, it would be good
to have an idea about
how common this is,
i.e. how often will
cookies that are today
truncated instead be
rejected?
/Daniel
On 2021-08-25 16:18,
Yoav Weiss wrote:
Hey Andrew! Thanks
for working on this,
this seems like a
significant
compatibility gap
(with security
implications) that
would be great to close.
On Tuesday, August
24, 2021 at 3:45:50
PM UTC+2 Andrew
Williams wrote:
Contact
emailsawil...@chromium.org,
miketa...@chromium.org
Explainer
https://github.com/httpwg/http-extensions/issues/1531
<https://github.com/httpwg/http-extensions/issues/1531>
https://github.com/httpwg/http-extensions/pull/1589
<https://github.com/httpwg/http-extensions/pull/1589>
Specification
https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md
<https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md>
Summary
Updates how
control
characters in
cookie data are
handled.
Specifically, the
tab character is
now permitted,
but all other
control
characters cause
the entire cookie
to be rejected
(previously the
\x00, \x0D, and
\x0A characters
in a cookie line
caused it to be
truncated instead
of rejected
entirely, which
could have
enabled malicious
behavior in
certain
circumstances).
This behavior is
also in line with
the latest drafts
of RFC6265bis.
Blink
component
Internals>Network>Cookies
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies>
Motivation
In the case where
attacker
controlled data
is used to set a
new cookie,
having certain
control
characters
truncate the
cookie line could
result in
security-related
cookie attributes
being ignored.
This behavior may
also lead to
cookie data
corruption when
control
characters are
introduced, which
may cause
unpredictable
behavior on the
application side
(more so than
cookies not being
set, which is a
case that
applications
should already
handle). Having
control
characters result
in the whole
cookie being
rejected helps
mitigate these
concerns and
aligns Chrome
with RFC6265bis.
For the tab
character,
although it falls
in the control
character range
(\x00 - \x1F,
\x7F), it’s a
printable
character and
allowed by other
browsers.
Treating it the
same way that the
space character
is treated makes
sense
intuitively,
eliminates a
potential
fingerprinting
vector, and
aligns Chrome
with RFC6265bis.
In the past, moving
to a stricter models
that forbade certain
characters resulted
in at least some
breakage of
non-malicious
content. I doubt this
one would be
significantly different.
Do you have a sense
of the resulting
breakage? If not, I
think it'd make sense
to add metrics to our
cookie parsing
algorithm and see
what that breakage
would look like.
Initial
public
proposal
TAG review
N/A
<https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uBxq9uCpKx0/m/A5LI0NbyAAAJ>:
this change is
already specified
in RFC 6265bis
and is a
relatively minor
change to what's
already
implemented in
Chrome (to
improve spec
compliance).
I agree that this
change is in lower
layers than those the
TAG usually deals with.
TAG
review
statusNot
applicable
Risks
N/A
Interoperability
and
Compatibility
WebKit / Safari:
- All control
characters except
the tab character
cause the cookie
to be rejected if
present in the
name and cause
the rest of the
cookie line to be
truncated if
present in the value
Gecko / Firefox:
- 0x00 in the
cookie value
causes the rest
of the value to
be truncated (but
subsequent
attributes are
preserved)
- 0x00 in the
cookie name
causes the rest
of the name and
the value to be
truncated (but
subsequent
attributes are
preserved)
- 0x0d and 0x0a
cause the entire
cookie line to be
truncated
(attributes ignored)
- 0x01 through
0x09 (the tab
character), 0x0b
through 0x0c, and
0x0e through 0x1f
cause the cookie
to be rejected if
they are present
in the name, but
are allowed in
the cookie value
- 0x7f is
allowed in the
cookie name and
cookie value
The following
issues exist
reporting these
differences:
*
Firefox -
https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1
<https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1>
*
WebKit -
https://bugs.webkit.org/show_bug.cgi?id=229088
<https://bugs.webkit.org/show_bug.cgi?id=229088>
Allowing tab
characters in
cookie names
aligns Chrome
with Safari but
not Firefox, and
allowing tabs in
the cookie value
aligns Chrome
with both.
Regarding control
characters (not
including tab),
what will change
in Chrome is the
handling of 0x00,
0x0d, and 0x0a
characters.
Today, Chrome
truncates cookie
lines when these
characters are
encountered, and
this intent
proposes having
these characters
result in cookie
rejection
instead.
Rejecting cookie
names containing
these characters
aligns Chrome
with Safari but
not Firefox, but
rejecting cookie
values containing
these characters
is inconsistent
with existing
Safari or Firefox
behavior.
However, these
changes unify
Chrome’s control
character
handling
behavior, better
align Chrome with
RFC6265bis, and
also help prevent
a class of cookie
attribute removal
attacks (when
malicious input
is used to build
a cookie line
under certain
conditions).
Gecko: N/A -
these changes
seem too small to
justify this
effortWebKit: N/A
- these changes
seem too small to
justify this effort
I somewhat agree that
asking for a position
here would be an
overkill, but would
love to get a signal
from both Mozilla and
Safari on their
intents to align with
the RFC. (the former
seems more likely
than the latter, as
this seems like a
CFNetwork issue)
At the same time, the
issues seem
sufficient for that
purpose, assuming
folks there respond.
Web developers:
N/A - these
changes are
relatively small
and are in
alignment with
the RFC, other
browsers, and/or
existing behavior
Yeah, developers are
unlikely to be happy
about this from a
breakage perspective,
even if it'd reduce
compat issues. The
main thing we can do
about that is ensure
breakage is minimal
before shipping.
Debuggability
DevTools
debugging support
will be
implemented along
with this change.
Rejected response
cookies are
already shown in
DevTools in the
Network panel,
with a status
explaining why
they were
rejected. Another
status will be
added to annotate
cookies rejected
due to control
characters.
Is this
feature
fully
tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
In Progress -
https://chromium-review.googlesource.com/c/chromium/src/+/3084521
Flag name
UpdatedCookieControlCharacterChecks
Requires
code in
//chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1233602
<https://bugs.chromium.org/p/chromium/issues/detail?id=1233602>
Estimated
milestones
M96
Link to
entry on
the
Chrome
Platform
Status
https://www.chromestatus.com/feature/5709264560586752
<https://www.chromestatus.com/feature/5709264560586752>
Requesting
approval to ship?
Yes
This intent
message was
generated by
Chrome Platform
Status
<https://www.chromestatus.com/>.
--
You received this
message because you
are subscribed to the
Google Groups
"blink-dev" group.
To unsubscribe from
this group and stop
receiving emails from
it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this
discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2de8b96-8878-47fe-99e2-5497b96c9adcn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2de8b96-8878-47fe-99e2-5497b96c9adcn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this
message because you
are subscribed to the
Google Groups
"blink-dev" group.
To unsubscribe from
this group and stop
receiving emails from
it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this
discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because
you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and
stop receiving emails from it,
send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/984b9bba-57f7-4145-9e1e-ee50601aae68n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/984b9bba-57f7-4145-9e1e-ee50601aae68n%40chromium.org?utm_medium=email&utm_source=footer>.
