Google Removes Cookie Control from Chrome
lauren.vortex.com
lauren.vortex.com
However: In general, cookie controls are still entirely there, so I'm positive that specific feature is what they're referring to. I use an extensive cookie domain blocklist and that's all there and functional. (I've never used said "ask me every time" feature in Chrome, but I went through a phase of using that on Firefox.)
-----
UPDATE:
Found the relevant checkin: https://code.google.com/p/chromium/issues/detail?id=51375
Looks like the previous behavior can be re-enabled via the "--enable-cookie-prompt" command line argument.
Perhaps support for re-enabling that by default should go in that bug (or a new one that references it)?
Care to share a rough overview of sites you're blocking, and a little of your reasoning? I tried putting fairly restrictive settings on Firefox one time to see how browsing differed - I noted a lot of sites didn't work without explicit permissions, so that's sort of a hassle. Beyond that, is it privacy considerations? Do you work in a field that you wouldn't want your browsing habits logged and cross-referenced? Vagueness on answer is ok, I'm just kind of curious what your reasoning is, and if there's any utility to me building some kind of blocklist for myself.
I’ve toyed with doing it the other way around (block by default, use whitelist) but generally it’s too much of a hassle.
This is all more or less a carryover from when I used to be really privacy paranoid — I don’t really have a valid reason outside of that these days. Force of habit. :)
Agreed. I just did "About Google Chrome" and saw that a new version was available - 7.0.517.24. Crap! Worried I would lose my cookie settings, I quit and restarted, and saw that they were there safe and sound. Only that option to prompt for each website was gone.
I had tried that option for a while but it didn't work quite right -- for certain websites it would continually prompt, "Accept Cookie?" No. "Accept Cookie?" No. etc.
When I clicked the "more info" part of the prompt, it looked like the website was trying to set a different cookie each time -- one that expires tomorrow, one next month, next year, etc.
So it may be a problem with the website, rather than Chrome. Regardless, the behavior was annoying so I selected "Block" all cookies and went with a whitelist, so this missing option doesn't bother me.
Running 7.0.536.2 (dev), in the cookie settings, I can set Chrome to "Block sites from setting any data." Now, upon browsing to a site attempting to set, in the URL (location) bar is a cookie with an "X" overlaid -- similar in style to the padlock with an "X" when an HTTPS URI is using an unsigned SSL cert. Clicking on the cookie presents me with the list of "cookies and other site data." Each can be selected and "Allowed" or "Allowed for session only."
The claim that one needs to allow "willy-nilly" or only having the option of "manually entering cookie exceptions into tables," these are just hand-waving. I'm not sure what more is needed; I certainly don't want popups for every cookie without my taking action.
I barely use chrome but I know firefox has a toggle for this.
"accept third-party cookies" (which no web developer should ever rely on)
and also available via an extension (but should be built in)
(hmm, why is imgur setting a 9-month long tracking cookie)
I'd love an option to accept third-party cookies but delete them on browser exit, while retaining legitimate first-party cookies as usual. Does any of the major browsers have that?
If done properly the user will barely notice or care and it's certainly less invasive than forcing 3rd party cookies to be used.
Ultimately, the problem is that blocking third-party cookies doesn't really buy you much (if any) privacy from folks who are motivated to track you. On the other hand, blocking third-party cookies does break some real use cases about federated identity and web sites that span more than one host name.
We decided to keep the option because it make some of our users happy, but we decided not to make it the default because we don't think the trade-off is advantageous for the majority of users.
If you'd like more information about this topic, you might be interested in reading this paper:
http://crypto.stanford.edu/safecache/sameorigin.pdf
From http://code.google.com/p/chromium/issues/detail?id=51031
Seriously, though, Google is used to web development, where they control the software and the machines running it. A new version of GMail rolls out, and everyone gets it. Like in the case of Buzz, this isn't always good, but it makes developers' lives easier.
But desktop applications are a different game. Almost any time you take control away from the user, it's bad. New version of the browser introduces a security flaw? Sorry, you've been automatically upgraded. Hate a new feature? See previous answer. Security hole found in the Google Updater daemon? Oops, we gave it admin privileges and ran it without telling you.
Has Google created so much good will over the years that people don't scream about this the way they would about similar behavior from Microsoft/Apple/DemonizedCompanyOfYourChoice?
Maybe they can't weigh the downsides of new and old versions, but they can weigh the downsides of now and later. Usually they go for later, which is a different problem.
In either case, the Right Thing was discovered long, long ago: sensible defaults. Users who don't understand the software needn't worry, and those that know what they're doing can make the appropriate decision.
It bugs me to no end when developers take this parental tack with users, as if we were not only responsible for producing the software, but also for ensuring the user doesn't do anything to harm themselves. Put an are-you-sure dialog box in the way, but don't try to force anything on your users. Even if you know better, you're over-stepping and your second-guessing of the user is misguided.
Right, that's why the App Store has been a huge flop, and its closed model isn't being duplicated by everyone who's making an OS these days as fast as they can run their copy machines.
(Yes, I know that the App Store does prompt users for updates, but in all other respects it's a much more tightly controlled system than PCs, and users love it.)
1. On Windows and OSX (at least), the actual updating is performed by a single service running in the background for all Google applications (the Google Updater). This service is installed and/or activated by all Google applications, every time you install them (or run them, in OSX, not sure for Windows). I'm sure you can find how to do the same in Windows but my know-how is not good enough, but in OSX you can disable GUS forever by uninstalling it, emptying its directory and then setting it write-only. This way, it's not possible for GUS to be reinstalled.
2. A good enough outbound firewall (I'm partial towards Little Snitch on OSX) will allow you to block connections to the update server, and make GUS unable to query it, and therefore to update Chrome without your consent.
Another point: Your method will disable all google updates (google toolbar, google talk etc) which is a good side effect imo but not necessarily desirable by all.
Else, please tell how you managed to turn off automatic updates in Google Chrome?
Your statement is factually incorrect. That's my point.
It is not "hardcoded in Chrome". It's a separate application altogether, and it's soft-configured in Windows, not hard-coded into Chrome. The fact that it's soft-configured in the Windows registry, using documented APIs, means that it is easily disabled; there's even a utility written by MS employees, on the MS website, for such software configuration. I take hard-coded to mean that there's code built in to Chrome which tries to auto-update on startup, in an unavoidable fashion. But there isn't. It's not hard coded.
(But I also agree that should be your decision to make.)
The compression Chrome uses on the diffs is pretty hardcore:
http://www.chromium.org/developers/design-documents/software...
So you can at least be reasonably certain that your browsing bandwidth dwarfs the Chrome updates, FWIW.
I don't know whether a Chrome update is dwarfed by regular browsing. The link you posted shows the size of one particular diff update they did. That's a completely worthless measure. The worst case, no doubt, is that everything has to be replaced and that would be 10MB.
That said, I agree that there should be an option (not a prominent one) to switch it off.
Any contradictory reports? Thanks.
I wish everyone contributed to open source projects, so they would know when to blog and when to file a bug report.
Let's assume you're a very "privacy conscious" person who only accepts cookies for sites where you feel they are necessary -- say ones where you're going to login, or you really want to read articles there and you can't without the cookies, or whatever. Under Firefox (and Chrome under the old modality) your cookie setting choice was "Block but notify on new cookies."
Under the old model, when you first tried to access that site, create an account, login, register, etc., you'd get the initial pop-ups that you needed to respond to, that made it very clear that there were cookies involved now that you might want to accept. This is in fact a modal decision, because not accepting those cookies at that point will have consequences (like registration sequences that keep repeating, login prompts that won't accept your input, and so on).
Now the new model. As you browse the Web the little cookie icon is constantly popping up in the bar. Sometimes it shows clear and sometimes it shows blocked -- but after a while you're just going to ignore it as you go flying from page to page. There's nothing in that icon to alert the user that they've reached an important decision point about an initial cookie from a site. Even if they think to click that icon at the right moment on a new site, they have to do more clicking to dig down into the cookie management system to accept it if they wish to.
Old model: You're on a page where you want to login. You get a pop-up that there's a cookie. One click on Yes. Finished. Easy to do, and impossible to miss that there's a key decision point.
You really do want people to make a go/no-go decision on initial cookies from sites, and not create a situation where they can easily go winging by those initial cookies and have them fall into a default blocked state -- since the consequences of doing this are a mess and require going in and deleting cookie blocks manually.
It's really initial presentation of first cookies on a new site (when the user is defaulting to blocking cookies) that is the major concern. In that situation, the user should be presented with a modal choice so that they cannot easily miss the fact that they are at an important "exception" decision point -- that is, accepting a cookie when their default is not to accept all cookies.
And remember, by not choosing the simpler "accept all cookies" option, the user has already demonstrated that they have concerns in this area, and are likely to be very accepting of UI sequences that make it easier for them to function within that choice with a minimum of confusion or risk of not noticing new initial cookie decisions for a site.
Sorry about any formatting nasties in this response -- I copied most of it in from a text-based e-mail.
Thanks.
--Lauren-- lauren@vortex.com http://lauren.vortex.com
Has he tried reporting it to http://crbug.com?
My worry is that Firefox may take too much of a lead from it, and similarly start removing features.
If Incognito mode worked in such a way that each tab were its own cookie sandbox, then I'd be reasonably satisfied with it as a cookie management solution, but as it stands, it's not good enough. (Because each tab is a separate process in Chrome, one would think that it would be reasonably easy to support that behavior.) In lieu of that, what I'd really like is a Chrome extension like Firefox's CookieSafe, where I can block all cookies by default and then whitelist them back in on a site-by-site basis, but nothing like that exists at the moment.
For now, the best I can do is the Tab Cookies extension, which removes a domain's cookies once you close the last tab that's browsing the domain. For my purposes, it's inferior to both of the other solutions I mentioned (per-tab sandboxing and whitelisting), but at least I can keep my footprint reasonably small, as long as I'm diligent about closing tabs.
Not entirely. The basic test I performed involved me logging into a site with a standard window, then opening a new window and navigating to that site. In the new window, I was logged in, because my cookie was shared and the session could be re-activated. When I opened a new Incognito window and navigated to the same site and logged in, and then opened a new Incognito window to that same site, I was not logged in.
If I was to open a link in a new tab from the logged in Incognito tab, that new tab would inherit the session from the parent tab, but opening a new window or tab and manually navigating to that site forces the site to create a new session.
Similarly, if a malicious site was have some code that tried to steal my session (via iframe or similar), it could only do so in the same incognito tab I had an active session in. I'm not entirely sure if it could do so if the malicious site was opened from a parent tab that created the session, since I have not tested that, but I assume it can since the session was inherited, and thus shared between the two Incognito tabs.
tl;dr: Incognito tabs/windows just don't create a secondary shared storage cache, they'll create as many sandboxed caches as necessary, only taking existing cache's from their parents.
Right, I can reproduce this behavior. This much works.
If I was to open a link in a new tab from the logged in Incognito tab, that new tab would inherit the session from the parent tab, but opening a new window or tab and manually navigating to that site forces the site to create a new session.
This behavior I cannot reproduce. Here is what I see:
* Open Chrome. My configuration removes cookies at exit, so I'm in a fresh session with no cookies yet defined.
* Open a new Incognito window with Command-Shift-N. Login to Gmail in this new Incognito tab.
* With the Incognito window as the focus, create a new tab with Command-T.
* In the new Incognito tab, navigate manually to http://google.com/. In this new tab, I'm still signed in to Google with same account I used to login to Gmail.
* Make the standard/plain (non-Incognito) window my focus. Create a new Incognito window with Command-Shift-N.
* In the tab in the new Incognito window, navigate to http://google.com/. In this tab, I'm still signed in to Google with the same account I used to login to Gmail.
So I'm only seeing 2 cookie contexts: one for standard tabs and one for Incognito tabs, regardless of how they're created.. For the record, I'm using the beta channel (currently on 6.0.472.63, Chrome wants me to restart so I'll be on 7).
Wait what? That functionality is built into Chrome, and you configure it in the same place that you toggle deletion of all cookies on exit. What you describe above is exactly how I browse in Chrome. No extension necessary.