"Cookies were originally designed to track users across the web on browsers"
No, they weren't. They were designed to store small bits of data (such as a login or session token, or form data) between page requests within one site. It was only later that they were repurposed to track users around the web.
Came here to say exactly that. Cookies are only capable of tracking users across the web because giant companies have managed to dupe site owners into adding code to their site.
Yea, I added a mention of this history (including RFC 2109 and RFC 2965) in the final essay too, including that DoubleClick was one of the first ones to track via cookies. Here is a link if you are interested: http://yuhongbao.blogspot.ca/2018/04/google-doubleclick-mozi...
I like a Firefox extension called "Self-Destructing Cookies".[1]
It will accept cookies, but then delete them when you close the tab.
Unfortunately, it (like many other useful extensions) was permanently broken by recent changes to Firefox. I wonder if there are any good alternatives.
You can also open up a Private Browsing tab if you want to visit a site you don't trust, or simply maintain a separate environment from your main stuff. Private windows have their own cookie store separate from the main store, and also clear their history upon close.
> You can get close with a built in browser setting.
And you can still keep cookies from specific sites by defining an
exception. They should better document this feature. For me it would
be a good default behavior. There aren’t that many sites where I want
to stay logged in.
"Cookie AutoDelete is my current replacement for Self-Destructing Cookies (which I adopted in my primary Firefox due to switching to uMatrix). I enable autocleaning, turn off showing the number of cookies for the domain and notification, and turn on cleaning Localstorage."
I used to use it, I now use Cookie AutoDelete [1]. It's especially a nice on-boarding experience: at first the cookie Auto-clean deletion is disabled so you have time to whitelist the sites you want, and then you turn it on.
It also support Multi-Account containers[2], so you can whitelist a particular site only in a particular container. This is obviously a new feature compared to Self-Destructing Cookies since Mutli-Account containers didn't exist back in the time.
This extension's functionality is definitely possible with the new APIs. Cookie manipulation APIs are exposed, including APIs for the separate cookie stores enabled by Multi-Account Containers.
So if i have a product that uses 3rd party cookies to try and enhance the user experience (saving user progress in a 3rd party service for user convenience), whats the alternative to 3rd party cookies?
Bad actors are making it harder for people who want to use cookies for enhancing the experience rather than analytics and marketing.
The third party service can provide you with some JavaScript you inject into your website. It stores cookies on your domain instead of a third party one.
You don't need cross-origin scripts for this: you can host it yourself.
If you were to disallowed loading scripts cross-origin, everyone would just end up creating subdomains for everything you wanted to load, which would be worse security-wise I bet, as you'd lose some of the cross origin security features we have today.
I think the traditional approach is to make them 1st-party, by setting up a subdomain, like '3rdparty.yourdomain.com' and forward requests to it to '3rdparty.com.'
Microservices. You track state yourself, call their service and shuttle the data back and forth, all on your servers. The user touches one endpoint and sees one cert.
its for things that are ephemeral and nice-to-have for the user but not worth it for me to build myself when there are more important things to work on. dang, i had a nice thing going.
No, they weren't. They were designed to store small bits of data (such as a login or session token, or form data) between page requests within one site. It was only later that they were repurposed to track users around the web.