I don't get why people think this is a move with some agenda, most likely they just don't think enough people use the single cookie deletion functionality to warrant having it in the settings vs the dev tools.
https://developer.chrome.com/docs/devtools/storage/cookies/
Contrary to the headline, Chrome isn't removing the ability to do anything -- they're just removing it from the preferences interface, where I'm not sure it really ever made sense to include in the first place.
Truly, editing/deleting individual cookies isn't something any regular user ever needs to do -- just clearing per-site, which continues to exist in preferences.
I disagree. A problem just recently with a gov site req'd you delete their cookies to resolve it (as an interim solution until they get around some year to fix the issue).
The settings pane gives you a cleaner ui for quick changes (debatable, but I certainly feel this way). Dev tools can break your browser if you do things wrong. They are made for development and deep changes, not routine stuff.
That is not "nothing has changed".
If your site needs users to clear cookies, then you should fix your site. Clearing cookies is not a routine thing.
They're removing the listing of individual cookies for each site. So you can still remove all cookies from, e.g. Hacker News, but will no longer be able to see the individual names of the cookies, e.g. `ph_6CDb7STpzm64A_...`.
I do have to commend you on the bold tone while being so misleading, though. Haha, good stuff. I propose a Law of Increasing Internet Indignation: indignation is a monotonically decreasing function of knowledge.
Physician heal thyself.
> If you click the disclosure triangle for one of the entries, you see… well, basically nothing about the site data. And there are no delete buttons for individual cookies. The only button is "Clear data", an all or nothing option.
Site guidelines suggest that you ought to assume good faith on the part of your conversational partners and responsd courteously to the good faith interpretation of their words.
I suggest you have simply misunderstood what people are complaining about.
That's not good faith interpretation. That's wholesale misinterpretation which is either incompetence or malice. If you want to play the whole "good faith" game, you actually need good faith.
You're all privacy groupies. You don't know anything about actual privacy. You're just an outrage squad. You know it. I know it. But you're performing for some absent audience that supposedly can't tell.
Fine, this site is yours. Keep it. I'll go play with the shellfish.
I have had locally compiled builds break my profile data once or twice, but that's a seperate issue.
So move it somewhere where it makes more sense.
> Truly, editing/deleting individual cookies isn't something any regular user ever needs to do
No true Scotsman? If the user needs to do this, they're automatically not a regular user, or what?
Anyway, hard disagree.
>> All the functionality is already built into Chrome right here: https://developer.chrome.com/docs/devtools/storage/cookies/
It can't both be redundant and be solved by moving one of the interfaces somewhere else. Either you meant to say it's not redundant and is needed but didn't list any reasons why you think this or your idea of simply moving the redundant interface elsewhere doesn't change the point made as it'd still be rudundant and not needed, just elsewhere.
> No true Scotsman? If the user needs to do this, they're automatically not a regular user, or what?
The "No true Scotsman" fallacy comes after redefining the group once a valid counterexample from the original group is defined. It's not a fallacy in itself just to claim a group has an attribute, the claim is still falsifiable and testable by bringing forth the counter case to why a non-developer needs or wants to use a separate settings UI for it. "non-devoloper" wording chosen instead of "regular user" particularly because the ability is still in the developer UI and maybe that'll make the claim about "regular users" a little more defined.
If this were disabling the ability for users to clear cookies for a single site I'd hard disagree but I'm wracking my brain to find a realistic case a non-developer user needs/wants to view and clear individual cookies instead of site based cookies or all cached objects for that specific page. It's seemingly by definition only useful when identifying and fixing bugs from reviewing the source/dev console logs and "clear the cookies for the specific site" is already seemingly rare enough for a user to be told to do by generic troubleshooting. If being told to do it by a developer or support agent the console is still there and again I think it's fair to say we are veering far from typical things that user cares to have in a settings UI vs where it is in the dev console.
I never said it was redundant. Perhaps you mixed me with someone else?
Regardless of how you call the fallacy, I think there still is one since the vagueness of the term "regular user" seems to implicitly define out the users that would need to access the cookie dialogue.
If the wording is switched to "non-developer", then I once again disagree with this conclusion. Non-developers should definitely retain the ability to view, edit and delete their cookies.
I view this mostly as a matter of power. Yes, non-developers won't be editing or deleting individual cookies most of the time. However, if a website starts misbehaving and attempts to seize control of some part of experience from the end user, the end user must have the ability to counter that.
Having the ability to delete and edit pieces of information stored by websites on the user agent is a crucial part of that. If you take this ability away, then you ever so slightly took control out of the hands of the end user. In the end, you are making the user powerless and submitting them under your control.
Nobody who isn't a web developer is out there trying to guess what individual cookie names/values mean or wants to delete individual ones. At most, they just want to be able to clear them per-site (or across the entire browser).
Anyone else will use the Developer Tools UI that's better suited for the task.
Think facebook.com, fbcdn.net, etc.
I end up having to delete cookies for Cars.com every other week, because sometimes the search function would corrupt something and every page would return a blank white screen.
One could imagine a browser vendor who made this workflow easy because they thought it was in the users' best interest. Obviously, that browser vendor is not Google.
How many people do you really think would ever need this feature in day to day use, even if it were extremely easy to find? The number is probably vanishingly small.
This will be harder, especially where you need to clear cookies on different domains like a login page, saml page, account page, etc.
If I remember right, clearing it for one site didn't help because clearing "login.paypal.com" cookies didn't clear "some-other-thing.paypal.com" or "www.paypal.com". They seem to use www.paypal.com for everything now.
Google for: "paypal Your browser sent a request that this server could not understand" for one example
Or "paypal your last action could not be completed" for another.
> If I remember right, clearing it for one site didn't help because clearing "login.paypal.com" cookies didn't clear "some-other-thing.paypal.com" or "www.paypal.com". They seem to use www.paypal.com for everything now.
Right, but that's not a problem that this particular change is going to do anything about. Previously, you had to find all the different paypal domains and whack their cookies and now you have to do the same. The functionality you can't do in the Preferences window now (but you can in DevTools) is find a single cookie in a single site and whack that one. That's the one that would be Daily WTFy.
I believe this is how iOS development works.
Admittedly we are very far away from this scenario, but let us not delude ourselves into thinking (a) that it's impossible, or (b) that it's not in Google's interest to do this once they are confident enough in their market power.