Hey jochen: currently this is working as planned - although if we think this is going to cause too many problems we can change it. We've moved to origin scoping all content settings. As a part of that we migrated existing settings under some circumstances. See https://docs.google.com/document/d/19huEwYGuACxsl9X1KGvXtptdwpcES_xaG7k3Y-n1abw/edit

Hi jochen, you can re-add the domain exception to cookies to make it work again since the migration is only done once:-)

thanks for the update.

As I mentioned in the internal mail, this migration left me with a pretty much unusable browser, however :-/

I block third-party cookies by default and use allow exceptions to allow my login cookies. However (thankfully) all login cookie provides don't serve cookies on http...

I would vote to take a step back with the cookies.

The migration was done in a way that nothing would be accidentally allowed, but some things can be accidentally blocked (as in Jochen's case). So there isn't a privacy risk, but there can be an inconvenience for the user.

The user can re-add a wildcard exception manually from the settings, but not from within the context of the site (as the blocked cookie can come from a different origin on the same eTLD+1). As I mentioned in an earlier discussion, this problem has already existed, since the cookies exception could be scoped to any domain, not just eTLD+1. But the migration made it much more likely to cause trouble.

I do not foresee such problems with most permissions, but I think we want to be more careful with cookies because they're simply not origin-scoped themselves, so scoping the content setting to origin really does not make that much sense.

Liu, would you consider reverting to the old scoping *just for cookies*, and devising a new migration approach specifically for the cookies setting to prevent Jochen's problem from happening to Beta & Stable users?

What if we made it easier to add exceptions for cookies from the context of the site?

That won't undo the damage to the settings the migration did

Maybe we should remove the migration for cookies only? 

How about we change back to not migrate old cookie settings, so that users on Beta & Stable won't get their browser broken, but keep the scoping type of cookies as origins and new settings users made later are origins?

We would like to have all content settings to be origin scoped, the consistency across different settings would benefit much for both developers and UI. And we will also remain the feature which user can manually input domain scoped setting exceptions.

reverting the migration for cookies should be done regardless imo.

as for the origin scoping: the problem is that cookies aren't origin scoped, so making the exceptions origin scoped is kinda confusing...

(also, why not migrate [*.]google.com to https://google.com:443 because moar-tls and stuff? Or at least to both http and https)

I understand the arguments about consistency, but I wonder if consistency between the cookie setting scope and e.g. camera setting scope is more important than the consistency between the cookie setting scope and the actual cookie scope.

As a precedent, we were faced with the same dilemma in the Clear-Site-Data work. And as you can see in this paragraph https://www.w3.org/TR/clear-site-data/#clear-cookies we decided to clear cookies per domain even though everything else is cleared per origin.

I would suggest disabling the migration ASAP before we know what we're doing. Reverting the cookie scoping back to domain-based is maybe not necessary, but then we need to address users who cannot log in to sites because they need to enable cookies on one of the origins in a redirect chain (e.g. accounts.google.com for mail.google.com). For example, could allowing cookies through the site info dialog look into [site info dialog > cookies > blocked] and allow cookies from all first-party origins that appear there?

> why not migrate [*.]google.com to https://google.com:443 because moar-tls and stuff? Or at least to both http and https

When I started the patch, my consideration for this was: patterns generated from permission request prompts for http sites will have scheme wildcards (no 'http' before '[*.]'), while for https sites the generated patterns will always have a https scheme explicitly. I think for scheme wildcard patterns, even though the pattern system will also make it take effect on https sites, the decision was made originally for http sites, so it will be reasonable we now only add a http exception and make it only affect http sites. 

Also there aren't many sites that use both schemes, so adding both http and https origins for a wildcard pattern will probably pollute user's settings with duplicate entries.

But these are all from general content settings perspective, sorry for my lack of knowledge of cookies, I didn't realize cookies are so special to other content setting types:(. I've sent out a patch to revert back the migration of cookie settings, I think this would be the most safe way for dev & stable users.

As for scoping of cookies, I'm torn between two sides now. Another main reason we want to do this is to improve permission UI, especially on [Android Chrome > Settings > Site settings > All sites], where all content setting exceptions regardless of types are listed, it will be confusing if we have a lot of domain scoped settings mixed together with origin settings, and it will be worse after we sync desktop settings to Android, and I think we are also planning to introduce the 'all sites list' to desktop?

Martin gave a very good reminder, maybe we can think of more convenient ways for user to add cookie exceptions?

About scoping, we could scope cookie settings to patterns, but list them separately in the UI as exceptions. I think the number of people who turn off cookies and manually reenable them is low enough for this not to be a problem.

I think before doing this we (where we is the team in Sydney making these changes) needs to get a better understanding of how cookies work.

My understanding is that cookie scoping is complicated and not uniform. It doesn't match origins or the way content settings are scoped when using patterns.

This is what I think the scoping rule are, jochen / msramek, please take a look and let me know if this is right and about any restrictions there might be.

- by default, scope to the domain. Don't include subdomains, but do include any schemes. That is, the pattern would be *://current-domain

- but cookies can be set with a domain as well. In this case, all subdomains   are included. That is, the pattern would be *:/*.cookie-domain

- cookies with the secure flag restrict the scheme the cookie can be read from to be a secure one. However the cookie can be written from an insecure domain, so a secure cookie created without the domain flag, might be written from http://foo.com and only read-able from https://foo.com

- I think there are restrictions on the creation of super-cookies (e.g. a cookie which is readable by *.com, for example) but I don't know what they are.

Oh, forgot about third party cookies, which there is a setting to block. A third part cookie is a cookie written by one domain for another domain.

I am not sure exactly what this means though. There are two things I'm not sure of:
- is writing third party cookies blocked, or reading them?
- how this works with iframes
- whether a cookie written from a.foo.com, with a domain of foo.com, and read from b.foo.com, is a third party cookie or not.

We always block read and write

every request has a "first party for cookies" url attached which is usually the url of the main frame. third-party in that context means not same-domain-or-host as the first-party URL (see net::RegistryControlledDomain)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a068a972414767b211e60016da07676f6f7ed4fc

commit a068a972414767b211e60016da07676f6f7ed4fc
Author: lshang <lshang@chromium.org>
Date: Fri Aug 05 12:37:12 2016

Not migrate old domain scoped cookie content settings

Change back to not migrate cookie settings so that we don't make too much
inconvenience for the user.

BUG= 633680 

Review-Url: https://codereview.chromium.org/2213313002
Cr-Commit-Position: refs/heads/master@{#410041}

[modify] https://crrev.com/a068a972414767b211e60016da07676f6f7ed4fc/chrome/browser/content_settings/host_content_settings_map_unittest.cc
[modify] https://crrev.com/a068a972414767b211e60016da07676f6f7ed4fc/components/content_settings/core/browser/host_content_settings_map.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dbcf5899da35bfedada435661e903a50ed1ffc56

commit dbcf5899da35bfedada435661e903a50ed1ffc56
Author: lshang <lshang@chromium.org>
Date: Tue Aug 09 03:08:48 2016

Minor change in HostContentSettingsMapTest

This is to address a optional nit in https://codereview.chromium.org/2213313002/.

BUG= 633680 

Review-Url: https://codereview.chromium.org/2218333002
Cr-Commit-Position: refs/heads/master@{#410558}

[modify] https://crrev.com/dbcf5899da35bfedada435661e903a50ed1ffc56/chrome/browser/content_settings/host_content_settings_map_unittest.cc