Issue metadata
Sign in to add a comment
|
[Site settings / Cookies] Cookies no longer sorted by eTLD
Reported by
jleedev@gmail.com,
Oct 5 2016
|
||||||||||||||||||||
Issue description## Old: Cookies are sorted by eTLD (host + Public Suffix). This is useful for me because e.g. all the '*.google.com' cookies are shown together, all the '*.wikimedia.org' cookies are shown together. But for example all the '*.appspot.com' cookies are not, since 'appspot.com' is a Public Suffix. So for instance the list goes ["doubleclick.net", "download-chromium.appspot.com", "dropbox.com", "www.dropbox.com"]. As a use case, let's say that I'm trying to nuke all of my google cookies to fix a problem signing in, but I wish to avoid clearing all data if possible. I could locate these cookies in two ways, either by using the search box or by browsing the list. If I enter 'google.com' into the search box, they will all be listed and I can successfully remove them. If I browse the list, I will see all the cookies that end in 'google.com' and I will also be able to remove them. ## New: Cookies are sorted by Origin, that is the complete hostname. For instance, the list now goes ["doubleclick.net", "doubletree3.hilton.com", "download-chromium.appspot.com", "drive.google.com", "dropbox.com", "dropboxforum.com"]. To me, this is worse in several ways if I want to scroll through this list: 1) All the www sites are shown together, at the end, instead of immediately after the corresponding non-www entries. 2) Lots of advertisers like to use dozens of subdomains, and those are now scattered about the list instead of grouped together. Screenshot attached. For my use case above, if I use the search box to find the second level domain, I will still succeed, but if I browse the list I will only find the singular 'google.com' domain, and this might not fix my issue. My next step would then be to clear all browsing data, and this would be more trouble than it should be. ## I understand that there are certain changes for the site settings to exclusively be controlled at the level of the origin, instead of using wildcards all over the place, and that the notion of enabling cookies for an entire eTLD might not be the same as it once was. Nor do I fully grasp how cookie domains actually work. Still, I was not able to find any bugs related to the sorting of this list, and I feel that it was made less usable without any clear purpose.
,
Oct 19 2016
Hi Emily, can you add the Chrome engineers working on MD? Martin referred to you. Thanks, Dominic
,
Oct 19 2016
+ folks working on MD site settings. I'm not sure if this was an explicit decision or a bug that was introduced?
,
Oct 19 2016
Last known decision on I was looped on for listing cookies, which may have introduced some changes (surprising though because the bug is a year old): https://bugs.chromium.org/p/chromium/issues/detail?id=450580 I don't have strong opinions on how cookies are listed beyond that we should land on a visible pattern that's easy to parse. Happy to talk with someone on the security team about the preferred pattern.
,
Oct 20 2016
I don't recall a decision about how the cookies should be ordered in the new md-settings. This is just what came naturally at the time. In hindsight, eTLD seems more appropriate.
,
Jan 7 2017
,
Mar 29 2017
Removing myself and adding maxwalker as the primary security design contact
,
Jun 27 2017
Just stumbled upon this issue after updating to version 59 of Chrome. Has there been any headway into changing back to eTLD ordering perchance? |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 Deleted