tldr: Author is referring to the ability to enable the "ask me every time a site wants to set a cookie" prompt (a la Firefox). Looks like this has been disabled in the latest Chrome nightly. FUD, etc.
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.)
> I use an extensive cookie domain blocklist and that's all there and functional.
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 know you weren't asking me, but I have a similar setup. I block everything by default and only enable specific cookies when necessary for functionality. Same with javascript, which Chrome makes pretty easy. I don't have any specific reason except that it feels cleaner not to send a bunch of data over the wire that isn't really necessary.
I allow by default and simply block a (large) number of stat tracking domains and other dubious sites. (Generally I just compiled a large domain list of advertising / stat bug / malware domains, rather than actively patrol my cookies for domains I wanted to block.)
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. :)
> Author is referring to the ability to enable the "ask me every time a site wants to set a cookie" prompt (a la Firefox)
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.
Title here and there are a bit misleading. My hope is Lauren has simply missed the cookie icon, in his location bar.
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.
While I'm not familiar with which Firefox controls you are referencing, the following is a shot of the cookie+"X" and the impending modal for selecting 0..n cookies and site data to be allowed indefinitely or for this session alone:
Key thing is really to disallow third party cookies, as that (among other things) is what is being used to track you by all the advertisers, spammers, Facebookers and so on out there.
Problem with that is the surprisingly large number of legitimate sites that break without third-party cookies. Things like when verizon.com has an element from verizononline.com, which sets a login cookie that verizononline.com expects to read. "Shun brokenly-coded sites" is not an option for something as vital as paying my phone bill.
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?
An alternative to third party cookies for login sites is to do a fast forward redirect through the main site for the login and then back again to the destination.
If done properly the user will barely notice or care and it's certainly less invasive than forcing 3rd party cookies to be used.
what will the response to this be? Could the site host set a cookie that then (from the server) is read and the content reported directly to the advertiser?
Sure. But a third-party cookie does more than track your activities on the site that gave it to you. If you get a DoubleClick cookie, then DoubleClick will be able to track you on every site that runs DoubleClick ads. Ie., they'll be able to tell that the same computer is hitting all these sites. This lets them target ads to you based on your whole history across all DoubleClick-serving sites, and to market your profile to their customers.
Certainly - I have been waiting for that kind of thing for a long time. Probably it already exists. However, it would be considerably more difficult to integrate into existing web sites.
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:
The author says google is pushing out new versions of the browser automatically now. I was pretty sure I didn't enable the automatic updating feature but when I checked "About Chrome", I was informed that the browser had been updated. Seems to be no way to disable this either. Am I missing something?
This is how Chrome has worked since forever, and it's a good thing. Asking the user for confirmation for security updates leads directly to users running known-insecure versions of software. If you don't want auto-updates, use Chromium.
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?
An update procedures takes up noticeable amounts of CPU time and bandwidth. Automatic updates means your system slows down arbitrarily, often with no indication as to why. Users are able to make observations at the level of "since I installed software X, my computer doesn't work properly anymore" and interpret that as a virus infection.
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.
A pretty dim view of users, but does that mean that Chrome is not for technical people? It's for an audience that is too dumb to be capable of understanding auto-update? (This audience, incidentally, does not exist: users aren't that dumb.)
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.
> Almost any time you take control away from the user, it's bad.
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.)
Prompting, rather than running a daemon that does it automatically, is the entire point of what I said. Adding functionality isn't taking away control unless you have to color outside the lines to disable it.
Of course you can (disclaimer edition note: but it's not necessarily for the faint of heart, and isn't officially supported. On their updater and update policy, Google manages to be worse than Apple on Windows, which is already pretty fucking bad).
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.
On Windows, Autoruns from SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb963902.asp...) works fairly well for finding out about these things that happen automatically, and disabling them, as easy as unchecking a checkbox. There's at two categories relevant to googleupdate: CurrentVersion\Run, and Task Scheduler.
Ugh, of course, there are work-arounds. But if you re-read my comment, I said it is hardcoded in Chrome. I was talking about Chrome.
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.
It's not hardcoded in Chrome, at least on Windows it's not. I'm currently running 4.1.249.1045, which I gather isn't particularly recent, because I seldom use it except for Facebook and other sites I don't trust to be logged in to for general browsing.
aj, you said expressly, twice, "that is a feature that Google has hardcoded into Chrome. You CANNOT disable auto-updates", "hardcoded in 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.
I don't understand why they're taking that decision away from me. They could just enable auto update by default so most users would always be up-to-date unless they have a reason for disabling it. There are some good reasons other than money as well, such as privacy and security. I don't want my computer updated in any shape or form when I'm on an airport or in an authoritarian country for instance.
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.
Security-wise I'd be very surprised if Chrome updates weren't signed; MITMing of auto-updates isn't exactly new (see EvilGrade). So I doubt it's an issue there.
That said, I agree that there should be an option (not a prominent one) to switch it off.
Chrome's auto-update feature on Debian-based distributions at least consists of it installing its apt repository in your sources.list. Which is fine by me.
Summary: "I noticed a bug in the latest Beta version of Chrome. I know Beta versions are 100% stable and never have bugs, though, so I assume this is some conspiracy by Google to ruin my life or something. Two more pages of whining about this."
I wish everyone contributed to open source projects, so they would know when to blog and when to file a bug report.
There's actually an issue on Chromium's tracker that suggested removing this feature (which was then closed as implemented). See link somewhere in the comments.
Hi all. The original blog post on this topic is mine.
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.
I'm starting to get the impression that Chrome is the browser for inept people, and that if you want good control over the browser behaviour, it's not a good choice. Chrome's responsiveness to public feedback is similar to Google's responsiveness, i.e. not responsive at all, and tends to authoritarianism.
My worry is that Firefox may take too much of a lead from it, and similarly start removing features.
Cookie management is kind of a tin-foil hat feature that is already served by Incognito mode. For the more technically inclined that really care, there are switches to turn on cookie management (and no doubt third party extensions)
As far as I can determine, Incognito mode just creates a 2nd sandbox for cookies and history that's shared across all Incognito tabs/windows, and is only deleted once you close them all. Cookies you create in one Incognito tab or window are visible to all other Incognito tabs/windows, just as cookies created in plain tabs/windows are visible to all other plain tabs/windows. So if you go into Incognito mode and browse there for a few hours, soon you've got a bunch of cookies that are following you around the Internet until you close all your Incognito tabs. In my case, I have Chrome set up to delete all cookies on exit, so Incognito doesn't buy me much: I might as well just quit the browser and restart.
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.
As far as I can determine, Incognito mode just creates a 2nd sandbox for cookies and history that's shared across all Incognito tabs/windows, and is only deleted once you close them all. Cookies you create in one Incognito tab or window are visible to all other Incognito tabs/windows, just as cookies created in plain tabs/windows are visible to all other plain tabs/windows.
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.
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.
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).
> 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.
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.
There's really a night and day difference between CookieSafe style cookie management and what Chrome offers in terms of usability. CookieSafe is much nicer and no Chrome extensions seem to offer anything similar.
I haven't used CookieSafe but I have no doubt that its functionality is more advanced than Chrome's built-in options. Chrome doesn't expose the internal APIs required to control Cookie functionality to the extension system. So we're "stuck" with that Chrome gives us, which is more than good enough for my needs.
For the sake of brevity, I didn't go into detail about how CookieSafe works, but try it out and you'll see why it's an entirely different experience than creating a static whitelist in a browser dialog box.
I don't think it's well served by Incognito mode. You want to keep login cookies, but not J. Random Site's tracking cookies. Similarly, I need to install an extension (No History) into Chrome to disable history logging without disabling login cookies; but it isn't able to clear the "Most Visited" list that shows up in new tabs, owing to limitations in the API.
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)?