Feds May Soon Be Allowed To Use Cookies 181
fast66 writes "The White House may lift its policy barring federal Web sites from tracking users' online behavior. In place since 2000, the cookie policy issued by the Office of Management and Budget was intended to protect citizen privacy but has sparked criticism — even from White House officials — for hampering citizen outreach. On Friday, Bev Godwin, the director of online resources and interagency development at the White House's new media office, blogged on the White House Web site, 'We want to use cookies for good, not evil' — and invited the public to comment on cookies through various online channels, including the Office of Science and Technology Policy blog."
Dupe? (Score:3, Informative)
Re:For the computer savvy, this isn't even an issu (Score:5, Informative)
> such that all the Flash cookies (yes Flash cookies) are also deleted.
Good point. Too few people even know about Flash cookies. There's also a Firefox extension called BetterPrivacy [mozilla.org] that'll do this, for those that can't be bothered with scripts.
I know that some shadier ad networks also use Java local storage to store tracking info, if your browser has a Java plugin. Solution: disable storing temporary files on your computer using the Java control panel icon.
Honestly, I do all of this, but I wonder how many others would even bother. It's almost like Scott "You have no privacy. Get over it." McNealy was right.
Re:No problem (Score:5, Informative)
I posted a response to a comment on the parent griping about flash and javascript--they are a security risk. I'll ignore cookies--that gets a bit...difficult to explain.
But because you don't seem to get it--let's make the javascript answer so simple even a programmer can understand it...
1) go to www.slashdot.org /. to be loading content off of another site--that can edit my DOM and run the driveby exploit du-jour.
2) hit view source
3) search for "ad.doubleclick.net"
4) you should see a call to document.write at a dynamic URL slashdot doesn't control
5) understand that a LOT of these go out through resellers--who go through other resellers--and so on...and all you have to do is buy a single script that gets into an ad rotation at a site like CNN or
Even if the script was safe when they checked it--it might not be safe five hours later when my browser pulls it down from a different IP address or netblock. The javascript isn't the risk--the third party javascript writing to my DOM to open an iframe with a driveby exploit is.
(and FWIW, there are actual javascript vulnerabilities--but I figured I'd stick to the obvious in this post)
As long as people continue to use things this way--they're a security risk.
Re:No problem (Score:5, Informative)
Cookies should be replaced by a standard for web page preferences, where the web page specifies which options there are and what the possible values are. Then the users can set the preferences they care about in their browser and leave others (like tracking IDs) unset. Logins should never be implemented with cookies.
Not to sound trollish, but seriously, are you a web coder? Strict online security in connection with login-protected content is simply not possible without a cookie*. Cookies are so standard that ASP even places cookies without telling the coder it's doing so (the 'application' variables).
:-P ;-)
Cookies are a necessary part of the Internet. The only problems with them is that they 1) aren't encoded by default, 2) can be set to expire whenever the coder wants, which can fill directories quickly if you do much browsing, and 3) can be made accessible to websites other than those who issued them.
If web browsers would just encode all cookies by default, then decode them whenever sending them back to a server, that would keep spyware from reading their contents from your computer. Then, if the browsers would store a 'touched date', and automatically delete all cookies over X age (configurable by the user?), many useless cookies would go away automatically. Finally, if cookies were only able to be read/written to by their issuing server, there would be no possibility for exploit (except to track your movements through pages which contain some content served by the issuing server, such as the much beloved doubleclick.net cookies -- which could easily be done-away-with by adding the rule that cookies cannot be accessed by any page displayed within an iframe/object/etc.)
Everyone always seems to believe that cookies are small programs or some such nonsense. Cookies are nothing but tiny databases stored on the user's computer. How much damage can that do?
* If you think you can have strict security by only tracking a user's IP address and/or passing a variable from one page to the next, you are sorely mistaken.
p.s. I know, I know.... ASP is m$ft. Get over it.
Last Measure (Score:3, Informative)
Someone please give me a valid reason why anyone should be blocking cookies (1st party, NOT 3rd party) and disabling Javascript, other than paranoia and/or a bad case of nerd grump.
The site http://paranoia.on.nimp.org demonstrates this, but do NOT visit this site unless you've turned OFF JavaScript and plug-ins for this domain.
Re:No problem (Score:3, Informative)
I mostly agree with you. I would very much like a browser with the privacy settings you described. There is already the "Accept third-party cookies" option (I think all modern browser have a similar option), but I am not sure exactly what that does.
On the other hand, cookies are not needed for logins. In fact, they are a rather insecure way to do logins as anyone who can see your cookies can take over your session. For example, if you are on an open Wi-Fi hotspot and view any website that uses cookie logins and allows viewing logged-in pages without encryption, then anyone on the same hotspot can see your cookies and hijack your session. There was an automated attack specifically for GMail [zdnet.com] a little while ago (which Google added a "require HTTPS" option to secure against), but the same principle works for any site that does not require HTTPS (so it [hopefully] won't affect your bank).
Instead, logins should be done using HTTP digest authentication [wikipedia.org]. As HTTP auth actually authenticates each request separately (as HTTP is stateless so it has to), it does not get tied to an IP, but still works without cookies. Additionally, it never sends the user's password in the clear, so even if the user is tricked into logging into a phisher's server, the phisher gets no useful information.
Unfortunately, although all modern desktop browsers support digest auth (some more obscure mobile browsers might not), the UI is horrible. I have yet to see a browser even indicate clearly that the HTTP auth was not basic (read: send password in the clear which should come with as many click-through steps as Firefox's current setup for self-signed certificates). Also, users have been trained for years to expect login boxes to appear as part of a web page, not as part of the web browser.
Using cookies for authentication is bad idea. They are currently the preferred solution for UI and historical, not technical, reasons. The browser vendors should be working on a sane authentication UI, so we can stop using them for that purpose.