If we'd never had cookies or we ban them now we'd be left with basic auth over https. That's equivalent to a first party cookie. It would be enough to create an ecommerce site with a cart and a recommendation engine. Every single site would have the same login form, managed by the browser. I guess we'd end up with an <auth> or <input type="auth"> tag to embed it inside the page and style it.
Another consequence, there would be more server to server communications because the first party server could send all sort of information to the servers that are setting third party cookies in pages now. The focus of privacy policies would be there.
Or with session ID in URL. It's a valid mechanism - works reliably, is fast, and doesn't require special support in browsers. Remember the '?PHPSESSID=...' littered all over the early internet? Yeah that one.
Of course there are some caveats, which made cookies win in the end:
* it must be applied to every internal link in the website
* it's equivalent of a "session cookie" (no persistence after browser is closed)
* it's a privacy risk when sharing the URL via copy/paste
* it's subject to 'session fixation' attack (related to the previous caveat)
Presumably the last two could be fixed by an extra HTTP header or special in-browser handling of a designated parameter, similarly to how CORS got handled.
One problem. There have been at least three patent cases where this mechanism has been claimed to be subject to a patent. The litigants won in one, lost in two others (there may be more of these, I am only aware of 3).
How am I aware of them? I was a fact witness in these cases, and the reason I was a fact witness it that my employment agreement with Cadabra Inc., later to become Amazon.com, contains an addendum describing this technique and specifying that the company cannot attempt to patent it, since I had already implemented it while working at UWashington CS&E.
Apparently this was still not sufficient for the jury in one of the cases. Edit: none of the cases were solely about a session identifier, so to be a little fair to the final jury, it's not quite that simple.
You can also mitigate it by including in the session token something from the server side that is sent by the client as part of the HTTP request but not as part of the query, such as a hash of their user-agent.
I did something similar to this in the early 2000s, when setting a cookie lasting longer than 24h required approval from SECDEF: [0]
This was a cookie-less FTP-over-HTTP browser, where you had to agree to the terms of service, and copying the link to someone else wouldn't mean they agreed to the terms of service. It was just a prototype.
Intranet web apps didn't even require a manual login, now we've regressed and have more web apps, frequently less AD authentication (cloud apps) and more random passwords written on post it notes.
AD (and Kerberos) require the client to have a ticket from a central authority, and also require the server to be trusted by that same authority. It won't really work for the "wild" internet.
That's basically Kerberos, which ad is "built" on and extends. I believe both Kerberos and ad require the server to be known to the ad or Kerberos master.
> we'd be left with basic auth over https. That's equivalent to a first party cookie. It would be enough to create an ecommerce site with a cart
not exactly. a site can't set basic auth for you, which means you would have to log in before adding something to your cart. whereas with cookies, you can add to your cart before having to authenticate in any way. Now, as long as javascript is enabled, there are other ways to handle that, such as local storage. But that is relatively recent.
The way it was done before without cookies was including the user's session ID as a query parameter in the URL. Adding things to your cart was also done through query parameters.
It was later realized that session IDs in the URL led to lots of security problems, but it's possible we would've come up with ways to mitigate those if cookies hadn't become widespread.
Preferring only POST form submissions vs GET links might have helped some, with proxies perhaps, while previous implementations of “disabled cookies” functionality in early forum software would tie the session ID to other information known about your session, such as your IP address and browser identifier, and often there was a time-out for your session identifier that would reset every time you visited another page on the site. Thus somewhat limiting how easily you could share your session accidentally with someone else in multiple ways. Today this would be less practical as folks switch from wifi to cellular frequently. And it was still a “workaround” even then, the preference for developers was still to use a session cookie where available for simplicity. (Annoyingly, the session cookie historically often came with the same IP address and browser user agent matching restrictions though this wouldn’t be as necessary given the different technology employed.)
I do recall that in early implementations of cookies in web browsers, they were disabled by default. But when a website wanted to set a cookie, a prompt would appear. Actually, this might have just been the configuration of some of the shared computers I was using at the time at school and in other places.
I might be thinking of the cookies prompts in Links and Lynx text mode browsers, as I tended to use those more often back then over dialup. The cookie prompts in general were terrible because you never knew what part of the site would be enabled or disabled before interacting with the site. To that end, Safari’s approach is quite reasonable for a default.
Someone would have ended up inventing some X-Session-Id HTTP header that the server would send to the user agent, and the user-agents supporting the "HTTP Sessions extension" would send back a X-Session-Id with the same content to the same origin. A special empty value would have been used to terminate the session, from the client or from the server.
Another HTTP header, X-Session-Expiration, would have been added to expire sessions.
... and then we'd have essentially a single cookie per domain with wholly different higher-level semantics (user control through a password manager.) That ... actually sounds preferable?
Banning cookies wouldn't do too much against tracking: modern browsers leak enough information that you can fingerprint individual users by eg screen resolution, available fonts etc.
Which actually would allow doing away with cookies: redirect users to $hash_of_fingerprint.mysite.com. On routing, discard the hash subdomain. This would keep their session alive, if they share a URL that's fine, the hash is irreversible so their info is not leaked and if someone else visits that URL they'll be redirected to their respective hash subdomain anyways so the usual security concerns do not apply. If the hashing library includes mysite.com in input variables then the fingerprint will differ between domains so you can't use it to track people either. Likely IP address needs to be included as well. User and password could be used to tie several hash subdomains together.
How exactly are you going to hash my fingerprint if it's my first visit to the site and I'm using someone else's link? You wouldn't know til my second visit if I wasn't running something to change the value anyway, and if I am running interference on the request, you're kinda boned. For that matter, what keeps me from just hijacking someone else's token in it's entirety?
Also, how does a fingerprint, (something already capable of being deanonymized), being put through a trapdoor function (some think specifically used universally for purposes of authentication), generally arrive at making a mechanism that isn't being hijacked for tracking purposes? That's where you end up running into the fundamental problem of web traffic analysis.
As soon as you have enough information to reasonably assure you you're talking to the same person, someone else will come up out of nowhere to beg you to share it with them. You can make tons of money sharing this info, but by and large people object to you being loose-lipped about their business with strangers.
This is what makes me shake my head in wonder at the direction the Web went...
We already knew there was going to be an issue. We knew, because advertising/marketing/big data like info sharing did not exist; and where it did, it was generally in the customer's face, and they had something to gain, and not much to lose, and big, ponderous and unwieldy to do.
By letting advertising drive the direction the Web developed, we've turned the entire apparatus into the most effective surveillance device known to man.
You didn't have police looking up people's catalog or financial records before. You did have landlines being tapped on a case to case basis, but that's a big difference compared to Google's capacity to provide LE with suspect lists via geofenced warrants.
It saddens me sometimes we never got to see a Web without "user" abstractions. In the beginning it may have been close, but since the late nineties it's been far too close to a liability in terms of abusability by well positioned players for me to feel super happy about it.
And yet I've been developing stuff for it for 10+ years without pulling Stallman levels of sticking to my ideals... Hooray for being part of the problem.
Removing an entire front in the War on Privacy wouldn't help? There are many things to fix if we want to reclaim privacy. There is certainly no single magic bullet and it certainly isn't all going to happen at once.
It wouldn't help, it would just push it underground and make it harder to deal with.
The opposite would work better. Create a standard for tracking people then legally enforce that all tracking conforms to that standard. Then users can opt out.
Yeah, I do think nothing would change. The vast majority of people I know have complete apathy over 3rd party tracking. It's just not something on their minds (for both devs and non-devs)
It would be of more help if GDPR was enforced in a really painful way (to offenders). GDPR is not about cookies. It's about tracking without explicit consent. If offenders were fined into oblivion it would (hopefully) go away. Fingerprinting relies heavily on client-side Javascript, so attribution shouldn't be a problem.
If the server redirects the browser to the identity provider, and then goes back to the browser with the token, and the browser gives that to the server, that doesn't seem to require third-party cookies.
It would have needed some extension for a session id, so the browser isn't just sending the password with reach request. Even with HTTPS I feel this is an unnecessary risk, since if you compromise the server you don't need to wait for login requests, but just any kind of request. Other than that I'd actually consider using this for side projects (should they ever be web based and require authentication).
The session (or any auth) cookie is essentially the same as sending your password. Security wise there's no big difference between sending a password or a session cookie over https (other than the session cookie is short lived, which may have its merits).
I remember the original ASP before .NET would simply emulate cookies via Server State or whatever it was called. It would encrypt some server data and send it to the client.
Any website could implement cookies in a single window session this way, as long as you didn’t open more windows lol.
yeah this would actually be the ideal world. shame. I don't even know how to programmatically sign into a google account anymore. it used to be easy enough with a few curl calls and I could retrieve my adsense reports but now it's just impossible. their login process is too convoluted now and involves so much javascript, I doubt it's possible with anything but headless chrome.
Recently I tried to write a web scrapper. The website had several methods of authentication (facebook, google, some propritetary), and I couldn't make it work in one afternoon using any of these methods.
I remember writing scrappers in late 90s/early 00s and it was trivial.
It's not allowed to keep state of the user without asking (under GDPR).
No technical hack changes that, no not even an SPA or running a webpage in an iframe.
If you have state for one purpose, you are not allowed to share state for another purpose.
I know that's bad. I don't know how many things we are used to should work in such en environment, where users are trained to NOT consent to anything, cause consent is only needed for bad things they do NOT want.
You are event not allowed to tell a user: this will not work without consent.
> It's not allowed to keep state of the user without asking (under GDPR).
Why would that be? The GDPR only covers personally identifiable data, a todo list that stores everything in local storage can keep state without any problems. You can store things like language settings, dark mode theme, etc. perfectly fine.
You can also use state for multiple purposes as long as you clearly list and identify those beforehand. You can't gather personal data and then suddenly sell or analyze it if you didn't tell your customers you'd be doing that with data. However, saying "we use this email address for (a) sending you news letters (b) letting you recover your password" is perfectly fine.
From my reading of the GDPR, you can even gather personal data without explicit informed consent if the data is absolutely necessary for your system to work. You do need to provide ways to update, delete or obtain all information in human-readable form, but explicit consent for something that anyone can understand is absolutely required for the thing to work can be collected. You can keep track of the contents of a shopping cart on a web shop, for example, but you can't submit the contents of that cart to your analytics backend without consent. You can, however, track the cart contents in your backend and link it to the users' account; only when you start processing the data in a way not strictly necessary will you need the user to provide informed consent.
The problem with GDPR is that most people encounter it in the form of tracking cookies and advertising, both of which are not absolutely necessary for any application to work, which is why they need informed consent. People think all cookies are now banned until further notice and that the mere existence of a database is now punishable by law, which is not the case. GDPR sucks, but only if you're in the business of collecting a lot of extraneous information about your customers and/or selling it (through analytics or ads, for example). Which, in my opinion, is a good thing.
> The GDPR only covers personally identifiable data
some data protection officers think any two linked clicks are personally identifiable.
If have read the full cookie ruling, in some passages it's about "saving" (in all senses) any data without consent - yes it sometimes talks about personally identifiable but the "saving" part doesn't care.
To be clear, I don't think that, but it's hard to make our service comply if the customers (think webshop) data protection officers follows that semi official guideline
GDPR is about personal data. A user name (not an email) and a password are not personal data so their not in the domain of GDPR. A cart full of products is not personal data. It becomes personal data when we add a street address for delivery, an email or phone number for sending alerts, a credit card number for payment. However if delivery is to a PO Box (or an Amazon locker) and the credit card and customer name never touch the ecommerce site (a third party authorizes the transaction), then a fully anonymous ecommerce becomes possible. No GDPR and yet it keeps state and tracks orders.
> It's not allowed to keep state of the user without asking
I don't think this claim is correct. GDPR requires complete transparency with how personal data is used and stored. Asking for permission just happens to be the safest/laziest way to be compliant.
There's no way to get consent without asking (informed, freely given, opt-in affirmative action) but consent is just one of the paragraphs that give a legal basis for processing private data - it's legitimate to use data that's needed to fulfil the contract (e.g. the adress to deliver goods), comply with legal obligations (e.g. KYC in banking), for legitimate interests that don't conflict with freedoms of the user, for public interest (e.g. news reporting), etc (see Article 6 https://gdpr-info.eu/art-6-gdpr/), and all these use cases can be carried out without the user's consent. However, in some cases where the data processor could assert some other basis for processing, it may be simpler to just ask for consent.
But for the particular case of sharing data with thousands of third parties so that they can use it to target ads, consent seems to be the only one that applies. Direct marketing is one of the very few use cases explicitly listed in the GDPR, e.g. in the 21.2 'the right to object' - "Where personal data are processed for direct marketing purposes, the data subject shall have the right to object at any time to processing of personal data concerning him or her for such marketing, which includes profiling to the extent that it is related to such direct marketing."
You realize that's an un-question, right? It doesn't even parse out.
You can't have consent without the assumption that there is a choice to be made, and that the choice is not yours to make, and that the one giving consent is aware of the choice. Anything with the characteristic of producing an implied voluntary choice without the chooser being aware the choice is being made is very specifically not consent.
Sure, possibly with a contract signed before using the web service. Example: I sign a contract with a utility, maybe on paper in a shop in a mall, then I use their website to check my bills. If that's included in the contract I don't have to give consent again in the website.
> It's not allowed to keep state of the user without asking (under GDPR).
False. You're not allowed to store data about the user for any amount of time longer than is required to provide the session/service.
Session cookies are explicitly allowed without consent. Even though many cookie consent popups imply that they are not ("cookies are required for this site to function"), that is a lie by the adtech industry (and ignorant webdevelopers).
Remember: They are NOT asking for permission to store session cookies--they don't need it. Every cookie consent popup is literally asking for permission to share tracking data with third parties. Even if they word it obscurely.
Another consequence, there would be more server to server communications because the first party server could send all sort of information to the servers that are setting third party cookies in pages now. The focus of privacy policies would be there.
Probably no way to implement OAuth.