Slashdot Mirror
"Breathtakingly Stupid" EU Cookie Law Passes
Reader whencanistop writes with some details on an upcoming EU law that slipped under the radar as it was part of the package containing the "three strikes" provision, which attracted all the attention and criticism. "A couple of weeks ago we discussed the EU cookie proposal, which has now been passed into law. While the original story broke on the Out-law blog from a law perspective ('so breathtakingly stupid that the normally law-abiding business may be tempted to bend the rules to breaking point'), there has now been followup from a couple of industry insiders. Aurelie Pols of the Web Analytics Association has blogged on how this will affect websites that want to monitor what people are looking at on their sites, while eConsultancy has blogged on how this will impact the affiliate industry. In all of this the general public is being ignored — the people who, if the law is actually implemented, will have to proceed through ridiculous screens of text every time they access a website. I know most of you guys hate cookies in general, but they are vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user."
I've seen examples where third parties require cookies to analyze the usage patterns of users on client sites but I don't require logs to understand usage trends on sites where I have easy access to log files. In fact, I think usability testing would reveal more than analysis of usage data.
It may make common folk like me think about the extent that our personal information is collected and used, information that is a valuable commodity in current society and it's bought and sold with very little compensation to the rightful owner - the individual.
"they is"??
My web domain.
Maybe it's a bit harsh. But so are the abuses of cookies.
Cookies are used to keep a shopping cart. That out-law.com article spells that out. Cookies are used to track logins on forum sites. There might be an implied consent, there. But to be sure, just ask for consent when users register. Previously registered users would be directed to the consent request page once the next time they try to login. Explain that the consent is for the cookie used keep their login state. Explain that without consent, the login process cannot be completed and the user would be limited to the access level of a non-logged-in user.
Now, what else are cookies used for, that consent should not need to be given for?
now we need to go OSS in diesel cars
I don't see the problem at all.
If you are running an Amazon affiliate program you should have no problem telling your users that by clicking on the link to the product you are recommending that you get a portion of the sale. If you can't admit to that, then you aren't being honest with your users.
Likewise with Google Analytics. What's wrong with telling your users that you want to track how they access your site so you can improve it? Oh, there's the little bit about letting Google build up a profile on you. Well maybe someone will come up with an Analytics system that doesn't have a big brother behind the scenes.
... is to an old slashdot story which even says the initial write up is wrong and it has a link to a yahoo story which no longer exists. Come on guys , I know this is slashdot but try a little feckin harder for gods sake.
If I tell a site to store some setting for me, it may set a cookie. If I click on some "automatically authenticate", it may set a cookie.
If I only change a setting of the current session or log in or things like that, that's no reason for a cookie.
Doing sessions via cookies is a blank check for the most trivial cross-site attacks, so do not do it.
If I'm happy to go with the default settings or if I have to authenticate anyway (so you know my name) there is no reason to make my browser send you stuff.
Thanks in advance.
It's also vital for TV advertisers to know people's sexual fantasies so they can work out how to improve the TV-watching experience for the viewer.
It's also vital for the RIAA/MPAA to know the contents of people's hard drives so they can deliver more-interesting music and movies for the consumer.
You have no right to stuff shit on my computer, period, and even less right to do so when the aim is to make you more money. There are these things called "server logs" that do an adequate job of letting a site owner know what parts of their site are found interesting and they do not require bugging my computer to do it.
In sum, you are every bit as much of an asshole as those RIAA lawyers who sue people for "contributory infringement".
Since we're talking statistics, the largest problem is understanding. Most people don't. Maybe that's why people prefer to use external tracking services instead of using the information already on their own website: The access logs. Otherwise I really don't see why you'd use them. No, it won't get everything, but it _will_ give you general trends. And with a large enough sample those trends will be obvious enough.
Plus, all this focus on ``user experience'' gave us dancing rodents and several big fat stacks of proprietary, closed, and platform-dependent stupidity of the likes of flash. The most prevalent user experience therefore has to be ``confused boredom''. And in a score or two years, bitrot has ensured all that crap stays lost forever. That's a definite boon, but not good for general archiving, and therefore a problem.
My core concern with websites is what content they have to offer, and if I can't find it, I'm gone. Flash? bye-bye. Confusing layout? Two more clicks and I'm gone again. A sitemap? Click on it and search for a couple keywords. Nothing? Ciao! And so on, and so forth.
``User experience'' is overrated. Focus on the message; write it for me and not at me, make it easy to find, easy to flip through, easy to search, easily available. And for that, you really don't need cookies, and you especially don't need and therefore shall not require javascript, java, or some other proprietary plugin.
If you want to track your users, all you need is a small shell script to connect requests, referrers, and timestamps together and you'll have more info than you could possibly need already.
"to know how people are accessing the sites so they can work out how to improve the experience for the user."
Oh please, pull the other one....we all know what cookies are ultimately used for.
Don't even try to feed us that line that this is needed for "proper feedback"
This isn't the 90's anymore....
End of Line.
Oh they is, is they?
There are other ways to gather info other than cookies. You can do a lot of stuff with javascript, forms, and php. All of which are connection oriented.
From one of the linked articles:
Here's what's coming. The now-finalised text says that a cookie can be stored on a user's computer, or accessed from that computer, only if the user "has given his or her consent, having been provided with clear and comprehensive information".
An exception exists where the cookie is "strictly necessary" for the provision of a service "explicitly requested" by the user – so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though.
~The Out Law Blog
So- some websites will have an EULA page. Big deal. Actually, that's not at all a bad idea now is it? So why all the hoopla?
(Note: The originally linked slashdot post linked a Yahoo News article that's no longer valid).
http://www.bistolas.net
Couldn't browsers be made "EU-compatible" and give users a settings checkbox that says (more or less) "I either don't care about cookies or I'm perfectly comfortable dealing with them on my own (either with plugins like CookieCuller or manually.) Bring 'em on!"? Or doesn't the new law allow that?
Prisencolinensinainciusol. Ol Rait!
There are in fact still people who refuse to allow cookies, and there are still browsers like lynx that require explicit confirmation from the user before they accept them(In fact, the directive does not ban cookies. It simply mandates the default behavior of lynx.). Ask yourself; what can be accomplished with a cookie that can't be accomplished using alternative mechanisms. Try thinking outside the box you've been in for the last 15 years.
Let us be frank. Cookies have been abused. Horrendously abused. Private companies have tagged, tracked, and stalked billions of people. We have allowed terabytes of data on the lives of everyday people to fall into the hands of completely unscrupulous entities. The information held by even smaller marketing outfits would 20 years ago have seemed like a treasure trove to organizations like the Stazi and the KGB. Does the fact that such information is akin to that desired by secret services mean that the collection and indexing of this information is inherently wrong? No; but it is a big hint that it probably is.
The EU may have blundered here, throwing the baby out with the bathwater. But I think their basic motivations were very admirable. As out lives move more and more onto the net, we cannot accept the current status quo of companies like Google, Yahoo, Microsoft and the rest being allowed to do as they please with data on other people. The Despite the unworkable nature of the law, the EU is moving in the right direction on this.
May the Maths Be with you!
Cookies are often used to store user variables when they go from one page to another - patching holes the stateless web protocol forces on the user experience. Session or server-side variables may also be used for this, but that's more work for the web designer, who usually is up to his neck trying to support different versions of IE misbehavior.
Sites I've worked on have never used cookies to send back personal information, but they have used them to improve the user experience.
Hey, Mr. Summary, enough with the fair and balanced. Make up my mind for me on this issue! Where does this law stand?
This doesn't sound "breathtakingly stupid" to me. It's debatable. Maybe it's "breathtakingly stupid" that it slipped through without notice, but if we are talking about what's right and what's wrong, it can be argued (and often is, I'm sure) that one should expect to have privacy in regards to their browsing habits*. The fact that it negatively impacts businesses should be irrelevant, if we are talking about protections for the individual.
* Yes, you can turn off cookies from the user end, but laws are sometimes there to protect people who don't know any better, and there are a *lot* of them in this case.
They are also used by most PHP based web sites using the session feature.
What's the point to ask:
sessionID=zaFgGG13sddf.34ciuoy
Do you agree [Yes] [No]
The problem is you need to show the user the text before they can view your website. Just imagine you are using google to search for something and once you click a link, you end up not on the content you expected but on a
"We use cookies to track users in the following ways, blah blah blah. Is this okay with you"
That would suck so much.
Yeah, total agreement, here. This stupidly transparent, self-serving quote says it all:
"...but they is vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user."
User experience? WTF? Sorry,but the only reason you need invisible-to-the-user cookies is so you can monetize them without them realizing just how much privacy/anonymity they're giving up. Because that might give users pause before they accept your cookies, if they had an informed choice.
And everybody here knows that. The quoted jackass in TFS is just trying to make his industry look like a victim, to drum up support from civil-liberties sympathizers on Slashdot. Too bad we're not that dumb...
As an employee of the advertising industry, I have zero problems with monetizing Internet traffic, or with using cookies to track user behavior, etc., etc. But I hate liars, and I hate people who try to manipulate me.
This is an irrelevant and distracting question, because cookies are always used with consent.
A web server replies, in response to a request initiated by the user, with a header that says, "Here's a little piece of information and I hope you pass this back to me on subsequent requests."
The user's agent -- software chosen by the user to do whatever it is that they're trying to do -- sees this completely advisory information and decides, perhaps even with a confirmation dialog with the user (or not, if the user has decided that they usually want the same behavior every time without getting bothered), to store this information. And then it decides to pass this information with the next request.
The entity the user is communication with, ultimately has no choice about whether or not the user really does this. It's all up to the person who is using the browser. Or, in very old browsers that don't have dialog preferences for cookies, it's all up to the browser's author, to whom the user decided to defer to when they install the software.
Cookies don't do things. Users do things with cookies. Servers reward users for deciding to send the cookie.
If you have chosen to transmit cookies, take responsibility for your decision, instead of crying to the government and demanding that cookies never be offered to you.
So to get around cookies people will just make their website a giant piece of flash
Well then, I guess I won't be going to europe for a while... Banning cookies... how can people enjoy chocolate chip or macadamia nut now?? ... Worst. Joke. Ever. Sorry Folks :)
This needs more cowbell!!!
Even if it seemed reasonable, give it a week or two and most would hastily click 'agree' without reading. It would be like UAC in Vista, not the worst idea at the core, but the poorest possible implementation.
Yes, grocery stores can match bank accounts and stuff. Reason why I pay cash and object vehemently to the "trend" where the combined stores are waging a vendetta against cash and are already trying to require use of electronic and therefore trackable means. All in the name of "safety" of course. Bunch of underhanded jackassholes.
Thing is, there exist alternatives for cookies, too. Only, you'll need access to the webserver to get the logs and that makes it much harder for third parties to gather the data. There was this trend, maybe it still exists, where sites required cookie acceptance. So I accept them all and safely store them in /dev/null. No ``user experience degradation'', heck, no discernible difference. Coincidence? I Think Not.
Indeed, this isn't the '90s anymore. We have technology that allows us to better target advertising and better track our business. Why legislate ourselves back to the days of broadcast advertising and a stateless web? And to those who say to use log files for analytics, you have to be kidding me. You obviously don't run a website.
There seems to be an assumption that cookies are almost entirely used for evil tracking of website visitors. People have brought up shopping carts and logins, but there are many, many other relatively minor uses for which cookies are useful. Are we to provide you with a disclaimer every time we want to make sure some little setting that you have clicked "sticks" as you jump between pages? Yes, there are other tools to do this job, but cookies are also a specific tool for a specific job.
I find it interesting to hear many people claim the evils of cookies are so bad that they need to be outlawed, when in the end, it is the user's choice if they want to accept them. Isn't this akin to saying that we need to ban content on television or the internet because sometimes it could be used for evil? If you can use the argument of "just turn the channel" or "just don't go to those websites" in those cases, then why isn't the same argument good for people to just turn off cookies? If enough people do that, then the web developers will use a different tool to get the job done, and cookies will fall by the wayside. You have an "off" button on your cookies. If you don't like them, then use it.
To quote Roger Waters: "Are there any paranoids in the audience tonight? Is there anybody who worries about things? Pathetic. "
Seriously. Not "most of us" hate cookies. A paranoid few do.
If it weren't for cookies, this site wouldn't remember my login. Google apps wouldn't work well. The browser would not retain my per-site preferences.
I rarely ever clear cookies.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Om nom nom nom nom nom nom nom!
Utilizing the synergization of benchmark e-solutions to pre-workaround action items!
Who wrote this piece? English must be their second language...
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Cookies are used to keep track of a user's session, especially when it crosses a load balancer and gets sprayed to any number of identical servers. Without the cookies, there is no way to keep your session on a consistent web server throughout a session. Remember things like "www3.netscape.com"? Cookie-based load balancers are what fixed that situation.
Yes, cookies are abused by advertisers, but quite frankly, I don't give a damn if a site wants to use them to follow me on their site. They DO use them to see which products are popular, what items are considered together - valid data that lets them make business decisions. I know from working with web design firms that they can be used to track flows through a site and tell what parts of navigation are difficult, and if users are missing the "intended" way of using a site.
There are lots of valid technical uses for cookies. I've never understood why they're vilified. It's a tiny chunk of usually random/hash data that's put on your computer by the remote site. Why should you care if they then retrieve it? The only objectionable use is cross-site cookies used by advertisers, and most decent browsers let you disable that class of usage, but not the rest.
I don't know what kind of crack I was on, but I suspect it was decaf.
...only outlaws will have cookies.
Cookie Monster, yeah I'm talkin' about you dawg.
Authority questions you. Return the favor.
If it weren't for cookies, this site wouldn't remember my login.
But then again, having a site "remember you" between sessions is a security risk. I mean ok, who cares if your brother starts trolling people with your slashdot account if he comes over for the weekend... but just the concept. You know, you CAN provide unique service to someone using a login, session ID's and designing your website with the appropriate GET/POST commands. Admittedly it is a LOT more work for the web designer, but far more secure than cookies. However you guarantee that the session "expires" the minute you close the web browser.
Seven puppies were harmed during the making of this post.
Ok, no cookies. Poor me. You're just making it more difficult, but there are ways around it.
1. The malware and other scrupulous sites you hate so much... They wont obey your rules.
2. I hope you enjoy long query strings, because everything is going to be passed from page to page.
3. If you don't, expect every link to become a javascript POST.
4. You'll be required to create an account a lot more often so we can store everything server side and restore to SESSION variables when you return.
5. And expect a lot of free content sites to go belly up. No cookie, no revenue.
6. What percentage of sites these EU customers visit are hosted outside the jurisdiction?
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
You are only here because I allow you to exist.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
Why do government people think that passing laws like this can fix a problem that is fundamentally a technology problem? The problem is that when lawmakers focus on tech, they often focus on regulating the tool instead of regulating behavior. So you get situation like this:
Trigger: People are killed with a hammer.
Response: Ban Hammers.
Unintended consequence: Entire construction industry out of business, everything falls to disrepair, screw industry explodes, scarcity of hammers lead murders to switch to using rolling pins.
In this case, the issue is user privacy. Regulating cookies does little other than break the web which is in many ways cookie dependent for many different dynamic interactions between applications on servers and browsers. So, you break the internet, reduce security, and move advertisers to using something that's not a cookie to tag visitors with (lots of ways to accomplish this).
It's that old guns don't kill people, people kill people thing.
-- $G
The reason this has come to the extreme is simple. If a website / web app uses cookies, it should clearly state so in it's disclaimer / privacy policy in such a way that people who visit the site should be able to know exactly what information is being taken from their visit by the website. If this was done upfront and in an honest fashion, this issue simply wouldn't be. As it is, many websites either keep this info in a generic way or just plain omit it. Now I'm not talking about fishing/scam websites, of course. These make the issue even worse. So now, cookies are being managed through legislation.
Our Congress and President are trying as hard as they can to turn us into a bloated, inefficient and ineffective nanny state just like you!
Signed,
The U.S. of A.
I'm with you on this one. For instance, I run a site that allows users to adjust the text size with handy javascript buttons. Cookies are what lets the site remember what text size a user prefers when they come back. Sure, I could use buttons that trigger a php script and store the preference in a session variable. But, then their preference is only saved for the duration of the session, and they have to reload the page just to change text size one notch... why bother? If we need cookie legislation, it should be crafted to target the problematic areas of the technology -- not the entire concept.
You can use php sessions without cookies. Search for "php sessions without cookies". It's all there. And turn in your programmers' card because you didn't know something as basic as that.
I think here's a lot of misunderstanding about what this "\"Breathtakingly Stupid\" EU Cookie Law" is all about.
It does not BAN anything. It requires Website operators to prompt the user on first visit to agree to their cookies. So basically _it is_ damn stupid: nothing is done about cookies, another nuisance is created. Set your Firefox to prompt you every time a site wants to set a cookie and see if you will enjoy it.
The EU completely ignores that most browsers already have prompting/blocking mechanisms for cookies and it's just up to the user to turn it on, and instead they reinvent the wheel and force the Website-owner to bug everyone in the world visiting EU located sites.
The really bad about cookies is all that lazy sites that with their lazy developers that think sessions can only be done with cookies, and all the sites that store cookies where not needed.
This means that users almost have no chance to accept cookies. They either have to accept them blindly or have to pay by clicking a dialog box every time they visit one of the broken sites (and many of this newfangled stuff is severly broken).
Try setting network.cookie.cookieBehavior to 1 in firefox/iceweasel and surf the net. You will see how many sites thinks setting cookies is necessary.
The problem is: Those sites bear no penalty for it: As long as lusers accept them silently, noone sees how bad their code is written. And as too many sites are broken, noone can change the default in web-browsers properly to let users choose, because too many sites are broken. That means that sites have no disadvantage from flooding users with cookies, as only tech savy idealistic people are annoyed (and those do not buy crap anyway, so no income from them). And so the circle closes.
Please note that this is nothing new. Almost every policy out there has something like this in. (Remember Obama putting an special allowance for youtube cookies for his websites? because the state already had to be good and not do what now people are surpised to have always been judged too evil to be good).
Its is not stupid,just a choice made by the EU, who the fuck get elected the companies strategic dpt or the politics ? The EU assembly.
Everybody knows that there is a tradoff between privacy (eventually security) and usability
Does this apply also to session cookies? I don't cry for doubleclick not able to track me, really, but session cookies are needed for core functionality of most websites (99% of those that require some sort of login).
" I know most of you guys hate cookies in general, but they are vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user."
If you need cookies to work out that, you need to think what the FECK you're writing there.
Your website should be simple to get around (so ACCESS logs are sufficient) and present the information needed (so you'll want people's feedback or test subjects). But nowhere do you need a cookie to find out how to "improve the experience".
PS How would cookies help in improving the eXPerience here?
"It's been 56 minutes since you last successfully posted a comment"
?
Which is exactly what every site will do if this legislation is enacted by member states.
This is the problem out-law identified. If you legislate against a technology, rather than a harm, people will use a different technology to legally commit the same harm. Criminalise the use of cookies and people will use a session identifier in the GET string.
Ignoring the pro/cons of this issue....
If I manage a web site that uses Google AdSense, for example, is it not Google that serve up those cookies?
So, is it not my problem?
Thanks Mr. Knowitall. All results for that are just linkfarms.
How is it supposed to work without pulling your pants down?
No, sending your session to any link you click on as part of your referrer info is not a smart way to do it.
We're putting a consent screen on our sites just to be safe with the exception that if we can positively determine that the web user is in Europe, we put a slightly different consent form up, and if they consent to receiving the cookie, we send them a cookie and then deny them anyways. We then keep a look out for this cookie appearing from different ips as most likely the European user will try to evade the ban with proxies but might forget to delete the cookie. If we detect this, we then are able to permanently ban the proxy.
This way we get the best of both worlds, we still track users, and have better odds of avoiding problems by denying as many European browsers as possible.
Well then, I propose web masters everywhere boycott cookies and instead track their users using crackers and croutons!
Our load balancers use cookies to keep sessions sticky
Our catalogs use cookies to track INTERNAL efforts to advertise our products
for example, link from google products, set cookie for 90 days, book referrer with every SALE for those 90 days, rinse repeat.
Our sites use cookies to keep users from seeing gawdawful long GET strings in their browsers, oh wait...
The EU should regulate the GET string too, it's insidious and can be used to do stuff that does things
If you're site is using cookies, no problem - this directive isn't going to affect you. If you're site loads third party cookies then this is what this law is addressing. There are legitimate uses for third party cookies, and your users will have no problem recognising and understanding those uses and probably consenting to the cookie. I'm guessing you're only going to be concerned if you're loading some advertising, affiliate stuff that you'd rather the user didn't know about. And check your logs - all those none IE visitors can already disable third party cookies easily in the browser preferences. If you're site, or revenue relies on using technology from the 90's then the EU is the least of your problems...
We want to implement seat belts for every citizen. Should we:
a. mandate every business and residence to keep a stash of belts on their walks; or
b. mandate every car to have seat belts built in?
The browser should ask the user if they want to keep the cookie or not. Much easier to regulate and implement.
That's a session cookie, it is not stored. There is a huge difference between session cookies and stored cookies.
Submitter apparently is counting on /. readers to not follow links but merely form opniions from TFS. This is presented as though it were a list of blogs bashing the new law from all angles... but in reality:
- The first link is to an old /. entry. TFS from that entry has an update acknowledging that the summary write-up is wrong and encouraging readers to RTFA, but its article link is broken.
- The 2nd link is to a blog hostile to the law. Its writing style clearly shows bias. It is light on facts or citations to authoritative references, and heavy on assumptions about how to interpret the law.
- The 3rd link is to another blog disagreeing with the interpretation from the blog in the 2nd link, and saying that the law doesn't really look that bad. ...and at that point I gave up. This information just isn't important enough to me personally to justify continuing to navigate a dishonest compilation.
Here's an idea for future attempts: how about a link to the damned law?
"As an employee of the advertising industry, I have zero problems with monetizing Internet traffic, or with using cookies to track user behavior, etc., etc. But I hate liars, and I hate people who try to manipulate me"
Your in the AD industry and don't see the irony in that last sentence...
The article goes on to quote the law, "Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user's consent to processing may be expressed by using the appropriate settings of a browser or other application."
I take that to mean that if a user has chosen to accept cookies in their browser, the owner of the site can assume consent has been given and doesn't need to ask permission. No additional text required?
You can, could, and still will be able to block cookies in your browser, so whatever web site operators are doing with them, it isn't going to affect your privacy or "trackability".
Unfortunately, that isn't really what happens.
For example, many sites now use local shared objects ("Flash cookies") to store data, rather than regular cookies. No mainstream browser controls these by default, so even if you have disabled all cookies in your browser's privacy settings or asked to clear all your private data, LSOs will still work. Moreover, use of LSOs is often not even mentioned in a site's privacy policy; even big-name sites like YouTube have been offenders in this respect. Moremoreover, the way to disable these little buggers in Flash is hidden in a settings dialog that most users wouldn't even know to exist.
Maybe I'm crazy, but I don't see how failing to disable something that is being used to do something you never asked for, which you don't know is happening, via an obscure dialog you don't know exists, can constitute implied consent, particularly if you've explicitly disabled all similar functionality that is presented in your browser's UI.
I can't decide whether this is Brazil-style bureaucracy galore, or Eastern Standard Tribe-style anti-productivity warfare.
Neither, it's basic privacy protection, and as far as I can see it's long overdue and a good thing. Why should we support out-opt monitoring rather than opt-in, just to make life easier for those who want to produce targeted advertising and affiliate blogspam?
If you have a legitimate need to use cookies, for example to help a user with a shopping cart or remember they've logged into your forum, then there will be no problem stating clearly at the point that they start to use these facilities that a cookie will be set for that purpose. If you manage to wade through all the FUD blog posts and find the actual wording we're talking about here (you'll want article 2, clause 5, on page 76), you'll notice that this does not require UAC-style dialogs or 'screen after screen of "permissions" to continue'. In fact, there is even wording saying that the new rule doesn't apply in cases where the user has explicitly requested a service that needs to store cookie-like information to function properly.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Passing a session ID around in the querystring has more severe security implications than storing the session ID in a cookie. You can't link your friend to your cookie.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
"...improve the user experience..."
This canned and automatic expression is used as the justification for every type of intrusive behavior that is practiced by commercial web operators. I say: "Bull!"
Improving the user experience is very simple to accomplish without intrusion. You need only to pretend that you are the average user and proceed to navigate the web site in question. Any astute designer will immediatley discern where improvement is needed and where it is not needed. People are basically the same. If some aspect aspect of the design will irritate or please one, it will irritate or please all.
In fact, in the web sites that I create, this is the exact process I employ to analyze the user experience. I do not badger innocent bystanders for their opinions. I simply ask myself if the web site feels good to me. If I can honestly answer in the affirmative then I can be reasonably confident that it will feel good to most others.
Intrusive practices need not replace tried-and-true, good-old-fashioned common sense.
The approach is completely backwards. They're hampering all uses of a given technology, when what they want to control is bad behavior. It's like banning/limiting hammers because a fair amount of people tend to buy hammers and then hit people over the head with them.
The legitimate hammer users get hampered. The head bashers buy mallets.
The correct solution to the absurd hammer example here is to make hitting people over the head illegal.
The correct approach to information collection abuse would be to make collecting information subject to regulation. As numerous people have already pointed out, you don't need cookies to track people and collect information-- the well-financed information industry can get around this dumb rule trivially.
Who is RTFM and when will he help me with Unix?
And when am I supposed to ask you? Every time you visit my website? Since if you don't have a tracking cookie on your browser I can't tell you've been there before and prevent myself from asking again.
Ironic, isn't it, that the very tool that would keep me from asking you every time you visit is the one being blocked?
We'll have a whole bunch of irritating click-through pages on websites saying "you arrived here without cookies, without them ... blah blah ... click here to see the page you were looking for." Oh yay.
- Michael T. Babcock (Yes, I blog)
As an employee of an advertising company, your usage knowledge is biased in that direction. As a long-time web designer who does not try to monetize most of my offerings, I use tracking cookies to simplify site design and to understand how users navigate and help them save preferences on those sites without asking them stupid questions like Windows Vista.
- Michael T. Babcock (Yes, I blog)
I agree with your critique of the comment.
Cookies allow the website to trivially track user state. That's the real defense of cookies.
Granted, there are somewhat more onerous workarounds, but they are more nefarious. Would you rather have tracking done with cookies, which you can control-- or buried in GETs, hidden form fields, and obscured URL strings, which you can't?
Only one of those options is trivially controllable by the user-- and that's the only one this rules is messing with.
It's a stupid rule, clearly written with good intentions by people who don't understand WTF they're regulating.
Who is RTFM and when will he help me with Unix?
My job is to secure access to my PC.
If you don't have access to my login on my PC, that cookie isn't a security risk to me at all.
Even sites like Yahoo and Hotmail have a nice anti-cookie button that says "I'm on a public computer" to avoid this.
- Michael T. Babcock (Yes, I blog)
but they are vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user.
First a disclaimer, or a proclaimer if you prefer: I am in the affiliate marketing business, and a big chunk of my earnings come from writing behavioral analysis code (linear algebra, massive matrix calculations).
Here's what's coming. The now-finalised text says that a cookie can be stored on a user's computer, or accessed from that computer, only if the user "has given his or her consent, having been provided with clear and comprehensive information".
An exception exists where the cookie is "strictly necessary" for the provision of a service "explicitly requested" by the user - so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though.
I've got to say, that sounds right to me. This seems to be saying that things which are an explicit part of the user's intent are fair game (shopping, site configuration, etc). While the surreptitious stuff that a user is unlikely to be aware of is not -- the user must be informed.
One of the fundamental principles of free market economics is that the parties to a transaction must be informed. If I am going to take a person's behavioral information I need to inform them that I am doing so. Frankly, if I'm going to use the information I have taken from them to make a profit, I would hope that the user would want a piece of the action. The information was created by them, it has value, it only seems right that they should have the option of asking me for a cut or denying me the information.
I'm not questioning the fact that this will sharply hinder the behavioral analytics business. It will. It will cost a lot of companies a lot of money. But here's the question for a true lover of the free market: Is that information yours by virtue of a just transaction, or is it that the creator of the information does not know it is being taken and you can get away with it? If the latter, is that really in accord with the noblest principles of Western economics?
Moreover, note that this is talking specifically about cookies, which are data stored on the user's computer. So even if you are still uncomfortable with the idea, answer this: What gives you the right to write to the user's hard drive without their express or implied consent? If it were the case that most web users understood what cookies were or what they are used for, you might be able to say that not turning cookies off is implied consent. But is that the case? Ask the average idiot about their cookies. Then show them what they are really doing, and watch the look on their face. I've done it, it is enlightening.
Stop-Prism.org: Opt Out of Surveillance
How do I put google analytics on every page without cookie use? If I don't set a cookie that has their opt-out, do I prompt on every page request?
Michael J. Ryan - tracker1.info
Thanks for the personal attack. Really appreciated it.
You do not make websites better by guessing what the user wants. Your own slashdot website probably has someone who looks at what people do, looks at how many people comment and generally advises on which are the most popular links. This helps them work out which stories are interesting to you and not a load of garbage. It also helps them work out what tags submissions should be grouped together based on the likelihood of users to read certain types of submissions.
Using cookise for advertising is completely different. You're using your cookies to make sure that either the money you spend gives you the biggest return (ROI). You're thinking about this the wrong way around though. You're thinking from your perspective as an advertiser (or someone who works for one). I, as a user, want to be able to click on ads of things I want to buy. Your job, as an advertiser of things I want to buy is to give me those ads at the right time and in the right place. You can't make someone buy something they don't want to. You can make it a lot easier for them so they don't get psised off and go to your competitor.
we got any cookies back there Earl?
Would be better if they made a law that forced browsers to confirm each request for a site to add a named cookie with a (Always Allow|Allow|Deny|Always Deny) option.
Michael J. Ryan - tracker1.info
You're absolutely ignorant and obviously have no desire to correct that, but let's do so anyway.
Why is considering Google Analytics "vital for websites to know how people are accessing the site so they can work out how to improve the experience for the user" an obvious lie which is designed to show that they're a victim? I maintain the systems and web site for a nonprofit newspaper and we use Analytics (which requires cookies to use half its useful features) because it's simply too time-expensive to process server logs and extract any meaningful information from it. We've got one tech employee who runs all computer services for the paper. The Apache logs are useless - so filled with garbage data from spiders, cell phones with misconfigured browsers, worms trying to find nonexistent backdoors into the site and paranoid idiots who disable their referer field that there is simply no way to tell anymore the bounce rate, site visit depth, etc.
We'd like to make the site more sticky and get people to be more involved with the content, visit more, read more, etc. but without good data showing us what people are even interested in, this is a lost cause. Google Analytics gives us some actually fairly crappy data, but it's better than verifiably 100% garbage which is what is in the server logs. Writing your own usage tracking software to do without the cookies you hate so much is a huge pain in the ass, and more to the point, time-consuming; it'll get in the way of doing the other crap the paper needs to keep itself going.
Clearly you were modded Informative by people who hate and fear cookies without understanding what they're actually used for.
How would you store the session ID without a cookie? I hope you aren't suggesting every url be rewritten to include the session ID, because that would be a security nightmare!
People send links to other people all the time. If it contains the session ID then everyone who uses that URL will be logged into your account.
Since when is October 31 2001 considered a couple of weeks ago?
firstly, its not all cookies, just those that are not directly related to the operation of the site the user went to.
That means this regulation is mostly attacking tracking cookies.
When I went to my favorite site, I never gave anyone called "fastclick" (or whoever)permission to store their stuff on my PC. Nor would I ever give them or anyone else permission to track my surfing habits, yet they are doing it without ever having asked or even informed me. This is a privacy issue.
I totally agree with the EU legislation.
I think the only breathtakingly stupid things here are Kdawson and Timothy, who both seem to have never read Slashdot before, despite being editors.
How would you store the session ID without a cookie?
Easy. Your browser accesses my page. My index or main page creates some random ID for your session as soon as you hit the page. I store this random token in a database on the server. Every time you request a new page, the page you were on calls the new page with a POST command that includes this ID. When the new page loads, it looks up this ID in the database along with any other associated data stored for your session. Etc. ad nauseam. All of this happens on the SERVER side, and is invisible to the user. Unlike a GET, which appears in the URL, you can't hack a POST unless of course you have physical access to the server.
No cookie required.
Seven puppies were harmed during the making of this post.
login and adjusting text size come under:
exception exists where the cookie is "strictly necessary" for the provision of a service "explicitly requested" by the user – so cookies can take a user from a product page to a checkout without the need for consent.
But don't let fact's get in the way of a good rant.
IranAir Flight 655 never forget!
Obama scares the crap out of me, and I think we're going to feel the pain of his administration in many ways over the coming years.
That being said: every time someone brings up "Hussein" when criticizing a behavior or policy of Obama's, my eyes glaze over and I ignore pretty much stop reading whatever you're saying. If you have to resort to implicit fear-mongering to make your point, I really have no interest in what you're saying -- because clearly you're trying to play on emotions in lieu of making a rational case. Perhaps even worse -- assuming that nobody recognizes that tactic for what it is shows a disrespect for whomever you're trying to convince.
Remember when all URLs were stupidly long and contained userids, sessionids, etc. etc.
This resulted in casual non-technical internet users (probably the majority now) posting and e-mailed links that inadvertantly logged others into their accounts.
It also results in more data travelling in the unencrypted URL. A simple solution to aviod cookies that will be used will probably be to add a GET variable to every request which is then inserted into every link in the HTML prior to it being served. Like the old days.
The old rubbish days of stupidly long hackable URLs
I noticed the article paints a picture as though this law will effectively break the functionality of the web and/or make it so annoying that nobody will want to put up with it. I think that's completely wrong. The conclusion that this is "Breathtakingly Stupid" is correct, but not for the reasons stated in the article.
From the article:
Here's what's coming. The now-finalised text says that a cookie can be stored on a user's computer, or accessed from that computer, only if the user "has given his or her consent, having been provided with clear and comprehensive information".
An exception exists where the cookie is "strictly necessary" for the provision of a service "explicitly requested" by the user – so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though.
Ok.... so you wont be barraged with consent requests every time you visit any web site that needs to maintain session state between two or more pages or track the fact that you've logged in.
So it would seem that the good news in all of this is that this really only pertains to those cookies used for annoying things like advertising and market analytics & profiling; those things that invade your privacy. ...or does it?
What's in a cookie? That all depends on the cookie. Some cookies store all the data being tracked by the cookie. But other cookies are essentially an index -- they store no real data, but merely help the server identify you to the server where the real data is kept. This is where things go gray and the law becomes "breathtakingly stupid."
The law assumes that websites intent on "violating your privacy" (whatever that means) actually need to use cookies in order to do it. This is like wanting to outlaw murder and in order to so, just pass a law that bans handguns (as if handguns are the only way someone might commit the crime.)
Rather than create a separate cookie which exists for the exclusive purpose of marketing analytics (or whatever other violation of a user's privacy the website or it's partners want to perform), now the website just needs to create a 'meta cookie', if you will. They have carte blanche to create a session cookie for maintaing your login or user session (essential the operation of the website) without your consent. They can create what you could think of as 'server side meta-cookies' -- where instead of storing a cookie in your web browser, they store the cookie and it's value as an attribute of your session profile information which is stored only on the server. The only cookie you actually have is your login / session cookie.
Under this scenario, the law only drives the activities of user tracking deeper into the shadows. Before you knew they were tracking you... you had a cookie. But you could delete those and know that they were gone. NOW they'll track you based on session attributes you cannot delete because it's on someone else's server.
There's a huge gray-area around the "strictly necessary" clause. If your website is entirely ad-revenue-funded, and without tracking you wouldn't be able to provide a service to your users at all, is this "strictly necessary"? Google is ad-revenue funded. Then there are sites like Amazon which performs tracking for cross-sell / up-sell purposes (e.g. "Do you want this USB printer cable that goes with that printer you just put in your cart that 98% of the other people that bought that same product discovered they needed because no printer actually comes with a cable?") After all the data needed to track those buying habits isn't essential in order to track your user session or maintain your shopping cart, but it sure is useful to the end-consumer and they're not necessarily collecting it to invade your privacy.
How is not telling them being dishonest? They pay the same price for the product whether the affiliate gets a cut or not. It's none of the buyer's business how Amazon divvies up the revenue.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
The URL to this story is http://yro.slashdot.org/article.pl?sid=09/11/13/1348222. Now, if I send that to a friend, he'll get his own version of it (with his settings).
Without cookies to keep track of who I am, everything either needs to be POST or GET, resulting in a URL that gives him/her access to my settings and my info.
Cookies aren't only about nefariously tracking your users. Granted, you work in the ad-industry, so I think you're suffering from that influence.
So, most advertising networks and third-party analytics services will state: ``Cookies are Copyright (C) 5000 bC - ever COMPANY. These cookies may NOT be used by anyone in the EU. Such an use is strictly prohibited and users residing in the EU found to have stored them will be prosecuted to the extent permitted by applicable law due to copyright infringement. It is the users' duty to take the corresponding procedures that may be needed in order to configure their user agents to comply with this clause. The users shall waive, in a non-exhaustive manner, any right to initiate legal and/or administrative procedures that may arise from, out of, or in connection with the use of cookies they receive that is in any way in violation of this policy, or any applicable law. Additionaly, Users shall indemify COMPANY for the misuse that cookies this Site asks to store should receive, including but not limited to storing the cookies in a not-authorised location. IN PARTICULAR, YOU AGREE TO (A) REJECT EVERY COOKIE THIS SERVER HAPPENED TO SEND, IF IN THE EU; (B) HOLD COMPANY, ITS EMPLOYEES, SUBSIDIARES, ..., OR OTHERIWISE ITS ASSETS HARMLESS FOR HAVING VIOLATED THIS CLAUSE. IN ADDITION, YOU HEREBY STATE, IN AN IRREVOKABLE MANNER, THAT (A) YOU HAVE READ CAREFULLY AND UNDERSTOOD THIS CLAUSE, AND THAT (B) YOU ARE AWARE OF HOW COOKIES MAY BE USED WHEN UNIEQUIVOCALLY REFERRING TO A SINGLE USER.''
Awesome. You just broke the back button.
No, GET/POST is not more secure than cookies - they are the same. But it is a lot more fragile. It is FAR easier to clone a GET than a cookie. You cannot have POST all over the place except having giant forms and browser warnings if someone wants to use their back and forward browser buttons. And it only works with Javascript for links anyway.
Finally, cookies do have the option to expire not the minute you close the browser, but the instant you close the browser.
Only because some sites "remember you", doesn't mean that all security sensitive sites use their cookies in such a stupid way anyways.
But then again, having a site "remember you" between sessions is a security risk.
So lock your damned workstation, if you're concerned about this.
I mean ok, who cares if your brother starts trolling people with your slashdot account if he comes over for the weekend... but just the concept.
Next time, don't give your brother your password, set up a guest account for him. This isn't hard, people!
You know, you CAN provide unique service to someone using a login, session ID's and designing your website with the appropriate GET/POST commands. Admittedly it is a LOT more work for the web designer, but far more secure than cookies. However you guarantee that the session "expires" the minute you close the web browser.
ASP.net can actually do this with a simple config option (in fact, I think it's on by default, too.) It tracks your state using a hidden form that gets posted every time you click a link. It's still a stupid work-around, though.
Comment of the year
And turn in your programmers' card because you didn't know something as basic as that.
Naw, I say he can keep his card; real programmers don't use php, therefore that is not something he should be expected to know (assuming he is a real programmer).
This author takes full ownership and responsibility for the unpopular opinions outlined above.
I agree
its a cop out.
users are forced to accept the cookies and the warnings or not use major parts of the internet.
Perhaps broad casting alternative services which provide the same services but don't give unaccountable third parties a detailed picture of your mail contacts and interests - will eventually be a market differentiator. With yahoo flickr facebook google msn etc trying to outdo each other in how well they profile you perhaps there is an un taped market here?
It appears that some information is missing in this page. When you hit the back button you are automatically logged out. This is a security feature to protect your account with us from unwanted access. In the future, you can navigate to any page on this website by using our menu. I'm afraid you're going to have to log in again to continue.
Login:
PS: If you're willing to go a few layers into my pages, accidentally hit the back button, and are prepared to log in again, you're interested in what I have to offer. If you're not interested in what I have to offer, I'm not interested in paying for bandwidth for you.
Seven puppies were harmed during the making of this post.
They should have said this only applies to cookies that are stored between browser sessions. That way, sites that are just using cookies to hold a session ID between pages could set those cookies to be just kept for that browser session.
I know most of you guys hate cookies in general, but they are vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user.
You can improve my experience by giving me whatever it is I want at this moment, doing it instantly, and doing it at no cost to me!
Hey! Where you going?
I'm not done improving my experience yet!
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
And woludn't such a behavior be more or less what cookies actually do?
I mean, you demostrated that it is possible to live without cookies, as you could well demostrate that we do not need wheels to survive.
But, I see it pointless to subsitute a well-established technology as cookies are, unless there is a real good reason to avoid them. And seriously, what is the difference between what you described and session cookies. Even deeper, wouldn't this have in a way the same drawbaks (and pros) that (session) cookies do currently have, including the potential privacy concerns?
You say that the process above "happens on the SERVER side, and is invisible to the user." Now, I think: don't session ids get generated, in general, on the server site? don't you need prior action of the user, even if the ua handled it transparently, in both cases?
"Unlike a GET, which appears in the URL, you can't hack a POST unless of course you have physical access to the server."
What do mean by "hacking" it? Apart from the link passing thing among people, bookmarking, and other things your implementation will (almost) break if using GET, I see nothing that would make it 'safer' that, say, POST. Both are equally vulnerable to MITM attacks, eavesdropping, etc. More importantly, cookies are vulnerable too, AND they are sent the way POST variables are sent. Neither are cookies-over-POST safer that cookies-over-GET.
"No cookie required."
Sure. But the concept is still the same. If it happened to be unlawful/unethical/terrorist/criminal/what-you-want to use a cookie, whay would your system overcome the problem. I see it as a nice idea to implement when cookies are not available for any reason. But certainly, it solves none of the matters around cookies.
"I know most of you guys hate cookies in general, but they are vital for websites to know how people are accessing the sites so they can work out how to improve the experience for the user."
You are a liar, but I'll give you the benefit of the the doubt and assume it's through ignorance.
Cookies are completely and totally unnecessary. In fact, they are a very poor way of implementing tracking by IP, which should be done entirely on the server. Nothing needs to be stored on the client to handle shopping carts, authentication, or working out how to "improve the experience for the the user". If you want to improve user's experiences, you can start out by not making your web site implementation dependent on receiving cookies back from browsers that don't return them to you.
So how is a website supposed to track whether you gave it permission to use cookies, anyway? I mean, normally you'd store that kind of preference in a cookie, or in a session record identified by a cookie.
So what if the user says "No, I don't want you to send me cookies"? You can't store their no-cookie preference anywhere for use on subsequent requests.
And woludn't such a behavior be more or less what cookies actually do?
Yes, except it's all done on the server side. After all what is a cookie anyway? It's just a token. But in this case _YOU_ don't get to see it, play with it, attempt to hack it, be paranoid about it, third parties can't use it to track you, etc.
unless there is a real good reason to avoid them.
How about people are just paranoid about cookies? Is that a good reason enough? Look at what happened between the White House and YouTube. Actions based on a completely groundless paranoia and utter failure to comprehend what a cookie actually IS.
You say that the process above "happens on the SERVER side, and is invisible to the user." Now, I think: don't session ids get generated, in general, on the server site? don't you need prior action of the user, even if the ua handled it transparently, in both cases?
Yes. However if I put a file (the cookie) on your computer, everyone in the world potentially has access to it. I'm vulnerable to tampering by the owner of the computer and/or security vulnerabilities in their computer or browser. Supposedly cookies can only be read by the site that created them, unless specifically made otherwise. But if I keep my own private database on the server side, only I have access to it. Period. No one can hack it. No one can try to figure out how I create the unique hash to identify you. No one can exploit it or use it to track my visitors.
Both are equally vulnerable to MITM attacks
If you can't trust the connection between you and me, ANYTHING is vulnerable to a MITM attack. Including encryption - because who is to say that the keys we are sharing are genuine? However in the above case I'm not leaving a text file on your computer that can potentially be read/copied by anyone.
whay would your system overcome the problem.
Again - a cookie is just a file that uniquely identifies you. That file can be set to be read ONLY by me as the web site server, or by ANYONE. However who enforces that setting is your browser. Plus, you can always read the file manually, it's on your hard drive. So a cookie implies trust - I have to trust your browser software. I have to trust you. And I have to trust the whole world that someone doesn't develop a way to covertly scan your coookies and then visit me pretending to be you.
For a session ID, all I have to trust is that a) you haven't given your password to anyone and only you can log into the site and b) no one is intercepting our communication and doing a "man in the middle", feeding both of us false information - situations that would compromise security ANYWAY. However I don't have to worry about cookie exploits or hacks, or security holes in your browser.
I can't really go into more detail, I don't have time. However I'm a doctor not a computer programmer. I've come up with this on my own. The information is out there and freely available. If you want to know more, research!
Seven puppies were harmed during the making of this post.
"Government does something STOOPID" is hardly news, don't you think?
Part of the Second American Revolution!
Actually if you turn all your links in to POST requests, what'll happen when someone hits the back button is their browser will pop up a dialogue box warning them that in order to redisplay the page, they'll need to resubmit some information. If they hit ok, it'll resubmit it and your app will be none the wiser. If they hit cancel, it'll kill the request and you'll never know.
That nice message is never going to be displayed to anyone.
It's official. Most of you are morons.
User experience? WTF? Sorry,but the only reason you need invisible-to-the-user cookies is so you can monetize them without them realizing just how much privacy/anonymity they're giving up. Because that might give users pause before they accept your cookies, if they had an informed choice.
Um, or we want to remember how a user sorted a list when he was on a page last? Or how he navigated through the site so we can present the correct links to wind his way up the tree? Or his language?
All of which should be available to non-logged-in users.
You are looking at this through marketing-tinted glasses. In your world you only use cookies for tracking.
In actual web design world, we use cookies for passing information between pages. There's plenty of reasons to pass information between pages that have nothing to do with 'tracking'.
And no one knows what would considered to be 'required' cookies, and hence you don't have to prompt for.
Probably they're trying to mean 'shopping carts' and 'logins' are allowed to use cookies without asking, because users should know that makes a cookie, but do they include language selection? Theme selection? Sorting things? Saving search terms? What exactly 'requires' cookies?
Strictly speaking, every single thing done on the internet could be done without cookies using hidden form fields and altered URLs and AJAX.
Even 'Have you visited before, and when, and as who?' can be hacked via the various 'Is a specific file in the browser cache?' detection methods. You could even put the session ID in that file, and read it via Javascript which alters URLs, and it's a damn persistent cookie. (No one's ever bothered to do this, though, because it's stupidly roundabout.)
If corporations are people, aren't stockholders guilty of slavery?
I wince every time I hear something's supposed to "improve the experience for the user".
"Improved user experience" seems to be the phrase of choice for people wanting to screw you over these days.
SWITCH YOUR COOKIES OFF ! The web will not break. Most sites work PERFECTLY without cookies, those that don't I refuse to use unless it's important (bank, email etc..)
Sure, I could use buttons that trigger a php script and store the preference in a session variable.
Except that session variables use cookies.
Seriously, I see the weirdest comments here about people that are just inexplicably silly. It's like people are missing how this works.
'Sessions' has nothing to do with this. A session just means the server remember the variables, and just wants the ID of the session for each page load...but someone still has to remember the session between page loads, so it's exactly the same thing.
The web is stateless. There is one good way to remember anything between page loads: Cookies.
There are half a dozen of bad ways, from guessing based on IP and User Agent (Fails horribly on NAT), to embedding information in the URLs (Extremely dangerous as URLs get passed around), to other ways that I can't even think of because it's stupid to use them instead of the actual thing designed for this purpose.
If corporations are people, aren't stockholders guilty of slavery?
Wow the ignorance you have displayed in this post and your other responses is amazing.
What you have described does exactly what a cookie does except you don't have to turn every part of your page navigation into a form submission.
The first problem with this is you can't make a standard 'a' link a form submission without using javascript and if you are irrationally against cookies you will most certainly be irrationally against javascript.
Unlike a GET, which appears in the URL, you can't hack a POST unless of course you have physical access to the server
WTF? I don't think I can respond to this because I don't think you actually know what the difference between a GET and POST request is. Please tell me what you think the difference is so I know how to correct this massive misstatement.
I'm going to continue by telling you exactly what a cookie is. A cookie is a key/value pair created by a web server as part of a HTTP header and stored on the client computer. For every subsequent request back to that server it will send the Exact same key/value pair back to the server unchanged. That is it. The only information in it what the web server stored in it. It cannot put anything in it the server didn't already know about. It will ONLY be sent back to the originating server and as a result CANNOT be used by third party servers.
One more piece of free advice. No data from a client browser can be trusted. If the information came from a client browser it could be tampered with. No matter how it was sent, GET, POST or COOKIE. The only technical difference is how the HTTP header was constructed.
I don't think the interpretation of this poster or the article it links is correct.
The law says:
"Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user's consent to processing may be expressed by using the appropriate settings of a browser or other application."
I think this means that if the user has cookies turned on in Firefox (or other browser)... the website can assume that the user has consented to the use of cookies. The user can auto decline by turning off cookie accepting.
This is normal and expected.
What I think the law is trying to do. Is to make sure that all browsers contain the ability to turn off/on cookies or perhaps allow the user to be prompted before accepting a new one.
I am saying that this law is about: MAKING SURE THE BROWSERS GIVE THE USER THE ABILITY TO ACCEPT/DECLINE COOKIES. Not the websites.
This is normal as configuration options in standard browsers. But not neccessarily for the non-standard ones... like poker clients and such.
I suspect that it is these companies who are concerned about this and trying to raise feathers.
My Opinion: Having the ability to turn on/off cookies in your software is a good thing. This is really looking out for the citizen. Good on you EU.
GET and POST is not more secure than cookies. They all achieve exactly the same thing. They are used to send information to the web server.
If your website is sensitive enough to worry about users staying logged in between browser sessions then use a single session cookie. Don't make your life harder by trying to hack GET and POST to do it for you. All you will do is make things far more complicated and you will probably leave yourself open in some other ways.
Without using cookies you cannot distinguish between business users, because most large businesses use proxies and NAT and thus all employees record the same requesting IP in your server logs.
The target audience for our sites are business employees when they are at work. Without cookies there is no way we could do any path analysis to see how individual people are using our site.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
Do either of you have any problem telling your users what you're doing? Because that's the only issue here.
"As an employee of the advertising industry... But I hate liars, and I hate people who try to manipulate me."
The irony in these two statements is delicious. At least from my somewhat stereotyped view of your industry.
I'm more or less opposed to marketing and advertising, unless it's opt-in and directed. I'm 100% pro-privacy. I'm mostly anti-corporate and anti-government. Given all that, I'm pretty much behind the law. I'd like to see far wider and more impacting laws like this all over the world.
Please note that I've spoken about session cookies. These do not store (at least are not supposed to) any file in the hard drive, and if they did, it is deleted when closing the browser.
I understand your point about the paranoia around cookies. It is something like the word 'nuclear' which brings collective fear. That is why in my web site privacy policy I've written
trying to illustrate the matter to my users. However, I don't think that the problem which (sometimes without much sense) arises the problem in discussion (identification of the user.) Session cookies, as I said, do almost what you describe. If you are familiar with the built-in session cookie manager of PHP or ASP.NET, for instance, you will understand what I'm speaking about.
The solution you describe, as I said before, may be extremely useful under certain circumstances when cookies are not available (or even as an alternate process). PHP, which I'm used to, supports what you say, and the SESSIONID can be sent as a GET or POST argument, if my memory doesn't fail.
If you don't want to have your information collected about a visit, then don't visit. You are essentially asking the government to pass a law that requires owners to lie and say you were not at their store, when you were. Frankly, I'm about 90% tempted to organize a strike on purchasing US Gov't bonds and bankrupt the Feds, just because its way more abused than any fucking cookie is.
This is my sig.
As I pointed out, you can also pass it around in a POST variable. Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
this again is a demonstration of the extremely bureaucratic, brain dead mass of overpaid parasites we europeans have to pay for - very dearly- to implement banana bending laws... please do boycott any of these "geniuses" and let the eu know how much we are pissed off
You don't set a cookie with their opt-out. Opt-out has to be the default (because if they've opted out, you can't set a cookie saying they've opted out). You set a cookie saying they've opted in.
If you read the requirements of section 6 of the rfc (I've linked to it and cut-n-pasted it a few times in this discussion), sites that don't get informed consent before setting a cookie are already non-compliant with the existing standard. If they've consented, from a programming perspective, it's like logging them in. You don't need a user name and password to log someone in - just generate a unique id, store it on the server, and set the cookie. You now have a fully-featured session, not just a cookie. You can set it to expire in so many minutes/hours/days/whatever, expire on browser close, or not expire unless the user logs out. Just inform the user.
Of course, unless you're offering the user some other benefit, they won't accept this. It's up to you to figure out how to make this attractive.
As for google analytics, you need more than cookies - you need javascript enabled, and google analytics slows down page loads enough so that people will sometimes just go elsewhere. In tests using a proxy to rewrite a page and remove the analytics code, I found pages loaded quicker, even taking into account the delay induced by running through a proxy, parsing out the page, and removing google's code. But don't take my word for it - interesting discussion of some issues here..
Here, let me fix that for you: Real programmers don't ONLY use php. They can use c, assembler, java, an abacus, or whatever tool is right for the job - even perl ... :-)
...The EU wants to outright ban cookies altogether? So for example websites will have no way of tracking logins, meaning you will have to login on every single page? Becuase if so, to me thats just nothing short of retarded.....having said that... ...This is the EU, so i cant say im really surprised... ....Just disgusted as ever with them
-L
are browsers without cookie managers now illegal?
No probably not
but the text says that "consent" is implicitly given by the user if he uses a cookie manager.
"the user's consent to processing may be expressed by using the appropriate settings of a browser or other application"
Atari rules... ermm... ruled.
How many of you have ever been a victim of a cookie privacy issue? How many cases in the whole world do you know? How many of them are related to non porn websites?
I see 2 issues here. The biggest one is that there are a lot of website owners that don't even now their websites are placing cookies as adding the Google Analytics tracking code to his website will do just that. And by the way, that is not Google collecting data about you but the website owner. The cookie is a first party cookie and legally Google has no write to use that data.
The next issue is that without cookies people will not be able to optimize their websites anymore. Simple tasks like a/b testing which is the most affordable way of improving a website won't happen anymore... cause yes, they are based on cookies. Not all websites have money to invest in user testing which anyway proove to be much less efficient than a/b testing or multivariate testing for that matter.
And all of you smart ass devs or admins, tell me, can your server log files point me out how often I've visited your website last month, which referrer I used for each visit and how much revenue I brought you? Than after you get me this data please apply the revenue to the first referrer and build me a report on which referrer works best for my website so I know where to put my marketing money for the next month. Yes, a cookie can do all that.
As for privacy, done right, a cookie can't tell nothing about a certain visitor that will affect his privacy concerns. But yes, I guess it is too expensive for EU to fight the criminals who exploit cookies so, hell, lock'em all down.
As I pointed out, you can also pass it around in a POST variable.
Using forms for navigation causes additional problems with bookmarking, linking, refreshes, redirecting, etc. Especially redirecting.
Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
Only with the options set a certain way, many PHP applications simply require cookies.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
Maybe you can understand this: you can't copy and paste the URL and send it to your friend and have them be logged into your session if you're using a cookie to persist the session ID, but your session is vulnerable if you send your friend a link that includes the session ID in the querystring.
Put simply, if the options are passing the session ID through get, post, or cookies, the best solution is cookies.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
You don't need forms to use post variables.
Not true - this is strictly a designer choice. There is no technical reason for any application to absolutely require cookies.
Only if I never logged out between those two times, and the site was not designed with this in mind - which is simple enough. On every get, you update the session variable. Some sites already do this. This also prevents people from using the back button, or opening it in a second window, or hijacking a session, which is a good idea in web apps. With a scheme like this, cookies would just represent more disk i/o overhead.
You don't need forms to use post variables.
It's like trying to talk to a stone, but would you mind elaborating? How are you going to send a post request to the server from the client without submitting a form? Any solution I can think of involves a plugin like Flash. Obviously you can send whatever requests you want using XHR, but that's not going to load a new page. You still need a URL to redirect to, which is going to be a get request.
There is no technical reason for any application to absolutely require cookies.
Correct, "enhanced security" is not a technical reason, it's a policy reason. Like I said, many applications and developers subscribe to this policy.
On every get, you update the session variable. Some sites already do this.
Do you have an example?
This also prevents people from using the back button, or opening it in a second window, or hijacking a session, which is a good idea in web apps.
Not necessarily, in many applications usage of the back button and session support across multiple windows is desirable. As is refreshing the page, which your scheme also breaks. So you've broken back, refresh, and multi-window functionality in order to provide functionality that already exists with cookies.
With a scheme like this, cookies would just represent more disk i/o overhead.
With cookies, a scheme like that is not necessary.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
You're right - it IS like talking to a stone. first hit - xmlhttprequest supports post variables, complete with code. No flash involved, no plugins. And why would you want to load a new page when you can just update everything in the current page, including either updating the form, removing it entirely, or replacing the entire body with new content, including more dynamically-loaded javascript? You can in effect load a completely new page, from the user persepective - and that's what counts. You'll also do it quicker than a page load. You can even have it open up multiple new windows, if that floats your boat. All while keeping your current context, so you've saved all your state.
You can also choose to preserve the use of the back button, multiple windows, etc. You don't need cookies for any of that. Or you can mimic the back and refresh buttons in the app, this way catching any user mistakes before they do something stupid - like backing completely out of the app.
Ask me again in a couple of years when the NDA expires.
Look, cookies simply aren't necessary. They are a convenience to the programmer, and to a smaller extent, the end user. There is no technical reason why a site absolutely needs them, they have their own security problems, and current practice of dropping them on users' hard drives without first getting informed consent is contrary to the RFC, and has been since 2000. The EU is right - fix your sites to comply with both the RFC and end-users' expectations of privacy. What's so hard about that? Or are most web-monkeys just lazy fucks with no respect for end-user rights? From all the complaining from people who can't be arsed to even read the RFC. I suspect it's laziness. Too lazy to read the RFC. Too lazy to figure out how to comply with it. Too lazy to learn new ways to do things. Too lazy to rub a few brain cells together and figure out that complying with end user expectations of privacy might give them an advantage in the long run by earning people's trust.
Do what you want. It's certainly no skin off my nose, and in the grand scheme of things, I'm certainly better off if you continue to do what you're doing now. And when the EU enforces the policy, and other countries follow suit (because no politician wants to look like they don't care about privacy), you'll be behind the curve, and I won't be. That works for moi. Enjoy :-)
You're right - it IS like talking to a stone. first hit - xmlhttprequest supports post variables, complete with code [openjs.com]. No flash involved, no plugins.
So we've gone full circle, from simply passing the session ID around in the querystring to now implementing everything in ajax (incidentally, if you're using ajax, it doesn't really matter if you pass the session ID in get or post). I'm all for ajax, everything I've done for the past few years makes a lot of use of ajax, but the vast majority of sites do not use ajax and it's a little silly to assume that every site will start using ajax as a means of passing session IDs so that they don't need to use cookies.
So, let's review. These are the options for tracking state:
1. Cookies
2. Querystring
3. Post body: Use Javascript to tranform each link to a form post, or change the site design and use ajax for all content loading, requiring you to also manually add in "back" support and making sure your users can still email links to specific pages, in addition to making sure your content can still be found by search engines.
Ask me again in a couple of years when the NDA expires.
That's convenient. So the "some sites" you mentioned before are actually just one project that you've worked on. In other words, you aren't aware of any public sites using your method.
fix your sites to comply with both the RFC and end-users' expectations of privacy
1. My sites are not broken, if the browser saves a cookie without asking consent it's not because I told the browser to save a cookie without asking consent, I just told it to save a cookie. If the browser the user happens to be using does not comply with the RFC that's not the fault of my application.
2. I would even argue that end user's expectation of privacy online includes the knowledge that sites save some sort of information about them either on the server or on their own computer. In other words, users expectation of privacy includes cookies.
From all the complaining from people who can't be arsed to even read the RFC.
I didn't realize I was complaining about anything, I just thought I was trying to get you to come up with a way to persist session state that was as convenient (for both developers and users), reliable, and secure as cookies. So far you've got passing the information along in the querystring and using ajax. If someone is hacking your cookies do you think they won't be able to figure out what information you're submitting via ajax? Do you think that using ajax is any more secure than using cookies or any other method of requesting? Sure, you can send everything over SSL, but you can also require that cookies only go over SSL. I still think that passing that information in the form of an HTTP header, in other words a cookie, is clearly more secure than the querystring and has all of the same benefits and faults of using the post body.
Too lazy to learn new ways to do things.
I'm trying to educate myself here, but you haven't told me anything I didn't already know.
I'll also point out that so far I haven't even bothered to bring up the fact that not all users run Javascript and relying on Javascript to control state isn't really the best idea.
Moreover, for someone so concerned about what the RFCs say, I'm a little surprised that you're so willing to ignore RFCs 2109 and 2965. Turns out we've already got a state management mechanism for HTTP.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
I don't have access to the internal code for competitors' sites, obviously :-)
There's actually a patent - # 6539494 - for using a second session id wrt failover and backup.
If the user isn't running javascript, you can't use an xmlhttprequest, same as if they aren't using cookies, you can't use a cookie to store state.
According to RFC2965, which YOU pointed out, your site is broken. It says "Both the user agent and the origin server must assist informed consent. I've reproduced the section below.
What I (and the EU) don't like about cookies is that sites tend to drop a LOT of them, they do it without my permission, and they use these for tracking purposes between sites both by aggregating the data and by the "same-server" or "same-domain" permissions policies, which end users aren't aware of, and wouldn't understand if they were. This is totally against end-user expectations of privacy, and what the EU proposes is that no site use a cookie without informing people that they do so, and what they do with the data. To me, this is reasonable behaviour, and it's the expected behaviour in RFC2965. The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
It's true that using a post is more secure than a get, but that wasn't the original question. The original issue was whether it was even possible to do away with cookies, and it is, in all cases.
RFC 2109 has been superceded. Here's the exact wording from FRC 2965. I'm not ignoring it - it says exactly what I've been arguing for - that as a site developer you MUST get informed consent from the user before you drop cookies on them.
(emphasis added)
Look - it's just proper etiquette. Advertisers shouldn't be able to track you from site to site with cookies, which is what they do now. It's an invasion of privacy, and it's just wrong. The EU is on the right on this one, same as Canada was right to threaten to take Facebook to court if Facebook didn't fix it's problems with unauthorized sharing of user data with 3rd party developers (which enabled a lot of phishing schemes, btw).
The default should be to preserve privacy. And, in the event that the user doesn't accept cookies, we can do a different session management technique that doesn't require cookies, and that would require us, as site developers, to directly communicate with advertisers wrt the customers - and only after getting customer permission for sharing that information. Informed consent. Since we wouldn't be following customers when they go to other sites, and since there is no session id stored on the client computer, customer privacy is preserved wrt 3rd parties. This is a "Good Thing", no? Sure, advertisers will hate it. It's not up to the end user to come up with a business plan for them, and it's not up to us to, either, unless that's what they're paying us for. If the want to do that, let them pay to "pick our
The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
I can agree with that.
"This site doesn't use cookies" or "Cookie-free Zone" would offer some guarantee that when they leave a site, they've truly left it behind
I agree, I'd actually like to see exemptions in the law specifically to allow same-domain session-tracking cookies without requiring explicit consent. The difficulty would be in writing that in such a way that it truly only allows session state cookies for the application you're using and nothing else, specifically marketing- and advertising-related activities. I just think that the state-preserving that cookies allow is too useful to throw the baby out with the bathwater, as it were.
The unfortunate thing about all of this is that it requires the developers to comply, I tend to think that the developers interested in complying with anything aren't really the source of the problem they're trying to fix.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
I think the problem isn't with developers, but their bosses, who aren't interested in doing the right thing if it's going to take time and cost money (time == money). Making it a requirement will give developers a bit of leverage when the boss wants them to write stuff that's really intrusive, like reporting back timestamped keystroke mouse movement data. And no, this is not a hypothetical situation. I can talk about this because we never actually deployed this as a bot detector except in a limited internal test - the powers that be finally *got* my point that it was excessively invasive. We could actually follow testers from site to site by rewriting urls so everything after the initial contact was proxied. At that point, "all your cookies are belong to us."
This is probably how link affiliate hijacking is done. It's not that complicated, and both cookie and non-cookie forms of passing info around are vulnerable. What's worse is that all web sites are vulnerable to this form of attack, and even out-of-band validation (like asking them to confirm by tending a text message with a pre-defined code from their cell - they think they're directly connected to site x, not through a proxy) doesn't help.
Getting rid of dns and using an numeric address would kill it dead - no proxying 4 U! :-) A dotted-quad number is fairly easy to remember, but who is going to want to remember ff:04:2d:88:e9:00:21:45:80:c9:22:22:01:55:12:b8 when we go IPv6? Still, I can see it happening for some apps - get there via dns the first time, do a redirect to the absolute ip address, and bookmark the ip address but show the site name. Always handy to have a few ip addresses around to quickly figure out if the net is down, or just the dns server :-)
Yeah, I can agree with that as well. I guess my premise for the pro-cookie argument has hinged on the fact that cookies are used for persisting a local session ID, and nothing else. In an ideal world, people who exist solely to market other people's products wouldn't have a job and wouldn't interfere with my development activities.
In reality though, I'm still content to use cookies because they provide the best state management I think I can get using HTTP.
So, I'll concede that you've got several good ("reality") arguments against cookies, but I've got several good ("idealist") arguments for cookies. Between reality and idealism I think we can both agree that reality turns out to be the only thing that matters.
That being said, do you have any applications that do successfully use an alternative session-management scheme? The primary reason I've stuck with cookies for session management are that they're drop-dead easy and I've yet to receive a problem report from a user who's blocking first-party cookies. I've ever only used cookies for my local session management (I have a severe allergic reaction to advertisers, online or otherwise), so if you've got any tried-and-true methods of persisting session state without a cookie I would be interested to hear.
I haven't felt comfortable with ever using PHP's own cookie-less session handling, just because I cringe at any URL I see that contains "?PHPSESSID=". I suppose it wouldn't be too much of an issue if you had your global include file get all of the session data (start the session) and then change the session ID for the output filter, but most of what I'm doing these days is using ajax so I would have to pass the session ID back and forth with each request. Have you seen any ajax application that pass the session ID back and forth like that, or have you heard of any issues? I suppose you could use a global Javascript variable to store the current session ID to send back and use to store the new one that comes back, I just have a feeling that changing the session ID on any request would have some implications that I'm not considering.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Tell me about it. It just looks fugly.
Well, you'll always have to pass the session id to the server on every xhr, but you don't have to receive it - you already have it :-) What you do is include a second variable, which you also pass to the server, and it passes you a new value back. This way, it makes it easy to be sure that you don't get into a weird state (such as when someone repeatedly hits the submit button, or back/forward/back/forward). Or you could concatenate/explode the two values in one variable. Of course, you still have to do sanity checks ... I guess there's no free lunch :-)
I have code that I wrote independent of work that isn't covered by an nda that I'll probably clean up and share that does session management w/o cookies or gets - it can work with either ajax or a conventional POST (using POST makes it easy to work on a single section). It's one of those "one of these days" things. When I put it out there, I'll mention it in my journal so you can grab a copy.
It also includes code for a javascript widget framework that supports multiple languages, etc., and the layout is via css.
What I want to do first, though, is a bit of experimenting with xml. Normally, I *hate* xml, but I find that some browsers can do neat tricks with it ...
In other news, researchers finally announced that H1N1 isn't the boogeyman of flus - it's either the same, or less, severe compared to the regular flu season. Now people won't be so worried if they don't get a flu shot. Tomorrow!
But (given the speed technology moves at, and the slowness of laws "catching up"), it makes more sense to legislate what people can and cannot do, rather than the technology they use.
So if the problem is tracking users without warning them, ban that - and make the ban apply whether they use cookies, flash cookies, or magic spy-rays from their monitors. Just like the law forbids murder, without a special law for murder with guns, murder with hammers, murder with rolling pins.
Paul "Say no to feeping creaturism"
None whatsoever, but as I understood the article, I also have to allow them to opt out, which would disrupt normal page handling.
- Michael T. Babcock (Yes, I blog)