New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 98241 link

Starred by 28 users

Issue metadata

Status: Fixed
Buried. Ping if important.
Closed: Nov 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 103215

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Changing third-party cookie blocking behavior to prevent reading as well as setting.

Project Member Reported by, Sep 27 2011

Issue description

what the summary says

Comment 1 by, Sep 27 2011

I was going to bang this out tonight, but `kBlockReadingThirdPartyCookies` isn't a pref. It's a switch, and requires a restart. I doubt that's a good idea as-is... :)

I'll swing by your desk tomorrow to chat, Jochen. Maybe you have brilliant ideas!

Comment 2 by, Sep 28 2011

Labels: -Feature-Extensions Internals-Network-Cookies
Summary: Changing third-party cookie blocking behavior to prevent reading as well as setting.
I talked with Jochen about this this morning. I'd like to just rip out the flag entirely and change the behavior, then give it a cycle or three on canary to see if we Break The Web™.

Renaming the bug.

Comment 3 by, Sep 28 2011

I think we still should move this to a pref and offer the ability the chose the desired behavior over an extension API

Comment 4 by, Sep 28 2011

Ah. Then I misunderstood. In that case, you can probably ignore the CL I just sent your way.
Project Member

Comment 5 by, Sep 28 2011

The following revision refers to this bug:

r103112 | | Wed Sep 28 06:49:55 PDT 2011

Changed paths:

Experimentally strictify third-party cookie blocking.

This CL turns on strict third-party cookie blocking by forcing the inclusion of
the `kBlockReadingThirdPartyCookies` command-line flag. The goal is to determine
the effect of a change in cookie-blocking behavior; if we Break The Web™ for
Canary users, we'll drop it. If not, we'll re-evaluate the default behavior of
the `kBlockThirdPartyCookies` pref.

I intend to revert this change after a few Canary cycles.

BUG= 98241 
TEST=Start Chrome. Is the command-line flag set?

Review URL:

Comment 6 by, Oct 3 2011

Status: Started
mkwst: could you add a Mstone label?

abarth: just FYI since you are often consulted on cookie policy changes.
@wtc: Thanks.

Comment 8 by, Oct 3 2011

Labels: Mstone-17
We haven't talked with enough people about this yet to decide if it's a reasonable change... I'd guess M17. Jochen?
Labels: -Mstone-17 Mstone-16
Let's put M16 there, we can still punt it later.

Comment 10 by, Oct 17 2011

 Issue 99684  has been merged into this issue.

Comment 11 by, Oct 17 2011

I can confirm that enabling the setting "Block all third-party cookies" in chrome://flags fixes my use-case described in  Issue 99684 .  IMO, this should be the default setting because it is a security hole, but alternatively it should be available via the normal user settings.

Comment 12 by, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17
Blocking: 103215
Status: Fixed
 Issue 113401  has been merged into this issue.
 Issue 113401  has been merged into this issue.
 Issue 113401  has been merged into this issue.
 Issue 113401  has been merged into this issue.

Comment 20 by, Aug 13 2012

 Issue 113401  has been merged into this issue.
Project Member

Comment 21 by, Oct 13 2012

Blocking: -chromium:103215 chromium:103215
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 22 by, Mar 10 2013

Labels: -Area-Internals -Feature-Privacy -Internals-Network-Cookies -Mstone-17 Cr-Privacy Cr-Internals-Network-Cookies Cr-Internals M-17
Project Member

Comment 23 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment