I was surprised no one used the meme earlier than I did.
It was movie #1 by the way, 21 years ago. Has it been so long? Memory retention is shorter. Seems in the 1980s anyone could quote a good 1940’s -50’s or '60s movie, or even a B-movie. (Probably no one remembers what a B-movie was either.)
For a good prediction of Social Media and mass influence. Watch the latter half of the 1930’s movie of H.G. Well’s “Things to Come”. A riot and a flash mob, caused by someone on a communications device making a video podcast against a space launch! (Oh yeah, It’s almost the size of a cell phone in a clear plastic case.)
Depends whether the quote was memorable or not. I don’t consider this particular one very memorable. It’s not on the same level as “You’re gonna have to answer to the coca-cola company”, to name one.
Yes but I would venture to guess viewership of Dr. Strangelove is lower than Matrix so it would even out. (My reasoning, you can’t get Dr. S on Netflix but you can of any of the Matrix franchise.)
I think it’s important to make the distinction between different kinds of cookies and how they are used. Anyone can shout “Cookies Bad!” without having an understanding of what a “cookie” is or does. But there are legitimate use cases for which cookies are very well suited, and more or less our only option. Those were the use cases for which they were introduced in the first place, before Marketing came along and started pissing all over the flower bed, as they’re wont to do.
The important distinction is between first-party and third-party cookies.
Cookies originating from the website you’re visiting are OK. These are the ones that allow such useful things as remembering that you’re logged in, that you prefer the dark theme, what was in your shopping cart before your browser crashed, etc… Most of this can be implemented purely server-side, but for performance reasons it’s stored in cookies: e.g. you keep your shopping cart contents so the shop doesn’t need to store such transient data in the database. Others are stored in cookies so that you can have different settings depending on which browser you use, e.g. dark theme on the HTPC hooked up to the telly, but light theme on the work machine to match the rest of your stuff there.
The problem is with third-party cookies. These are the ones being abused by Big Marketing. E.g. the ones from tracker.totally-not-shady.com that are inserted in your Google searches, your Amazon shopping sprees, the random website where you read up on those embarrassing symptoms, the dating site you frequent, and the website of the health insurance company you’re considering. These are the cookies that allow that health insurance company to determine that you belong to the “promiscuous” category and are likely to suffer from one of the 7 ailments commonly associated with the aforementioned symptoms. More commonly they’re simply used to ensure ads follow you around on the web, so that they’re tailored to you rather than to the content of the sites you’re on. Because there’s nothing awkward whatsoever about trying to settle a discussion with friends by googling it, and having the answer surrounded by ads for paraphernalia for that kinky thing you do during the weekend.
There may be legitimate use cases for third party cookies, but I can’t immediately think of one that couldn’t be solved via other means.
And it’s not just cookies originating from other domains which are a problem. Frontend developers have been “standardizing” on some very unsafe practices. It used to be that when you visited a website, all the CSS, JS, fonts, images, … were custom written for and served from the same domain. Nowadays, not only are we pulling in lots of unnecessary code because you use just one function of a library with hundreds of functions, that depends on twenty other libraries, that each on average depend on another 12 and so on, 17 levels deep… Nope, nowadays all that unnecessary code is more likely than not served straight up from external sites that the developer has zero control over. Take a look at the Network tab in your browser’s developer tools next time you load a web page. Odds are it loads stuff from dozens of domains.
One advantage of a server-side shopping cart is that you can, for example, start raising the order on one device at one point in time but finish the order, including adding to it, on a different device later on.
Another consideration is whether the client device is more likely or less likely to reset / shutdown / crash than the server device. (That certainly happened to me recently. Lost a 12 line order with quantities because something went wrong in the browser at my end.)
But we digress.
That’s the key point.
However there is often no transparency as to how they are used - so a user cannot be said to be giving informed consent. As I noted above, cookies are often deliberately obscure (e.g. encrypted) so that they cannot be forged (which is therefore a good thing and a bad thing).
Cookies have very limited semantics as per the HTTP spec. There is very limited means of communicating via HTTP what the cookie is doing.
Regarding Cookies.
It seems obvious to me that there is ABSOLUTELY NO NEED to store cookies on the client.
The Servers keep SO MUCH information about us the keeping the cookies on the server is trivial.
The ONLY reason to keep cookies on the client is so that the client security can be compromised.
How could you implement a stateful session after logging in without cookies or localstorage? Do you want to type in your username and password everytime you refresh the browser window, click on a hyperlink etc.? Goodbye usability. Cookies are no problem per se. They can be much more secure than using localstorage when used as httpOnly (no access via client-side JavaScript) and secure (only https).
The problem is mainly with third party cookies (cookies placed by domains other than that you are visiting) and with first party cookies not only used for authentication but statistics and tracking.
I give the fight up, let there be an end. A privacy, an obscure nook for me. I want to be forgotten even by God. -Robert Browning, Paracelsus, 1835
Every time I go to Google and many web sites addicted to Google, I see my location at the bottom of my (their) browser!
I know where I live - I don’t need reminding all the time - - even my address is available, but for the life of me, I can’t find where Pichai Sundararajan home is! Why can’t I follow Pichai around record what sites he visits, what he buys online, what he “Googles” or searches for, what he subscribes to… etcetera?
How does the server know which client is which without the client having some form of identification?
I mean you could store this in memory during the session, but that is still stored on the client and means manually reauthenticating each time you open a new browser window/tab. This is very unfriendly from a user perspective and is not significantly different than storing the local information on disk (as a cookie) and deleting when you close out the browser (a setting on nearly every modern browser) in that the browser has access to the information the browser put in memory. Doing this in memory has no way to persist across reboots, as an option for convenience if desired whereas cookies provide that option.
Another option would be to have the user authenticate with every pageload as mentioned earlier. This is so inconvenient and impractical that it would decrease security not increase it.
Beyond that I have no idea how you intend for the server to know who you are to access the cookies that are stored on your behalf on the server that identify you to the server… Server side cookies seems like a way to needlessly increase complexity without removing the underlying problem.
One thing I haven’t seen discussed here is should we have internet hygiene education instead of focussing on getting rid of an optional convenience?
Session states have to be stored server-side. Cookies don’t represent a session. They authenticate you against a session table. Cookies can’t be stored on a server. It’s intrinsic to cookies that they store information and get send to a server on every request.
For the first case, you are basically correct. Since you have to authenticate yourself to the web site, they can store everything that you do and everything that they know about you against the “username” that you login to, and store it on the server side. They can likewise store your site preferences on the server side.
Only the login itself requires a cookie - and more often than not the cookie can be a session-only cookie i.e. not stored on the client’s disk and expires when the browser is closed, at the latest.
(It is not technically true that a cookie is required. The web site could use various alternatives. However the cookie that is used purely to maintain the authentication state is not a privacy risk itself - and the alternatives don’t add anything in terms of privacy.)
For the second case, there is more reason to store state on the client side - since otherwise the server has to “guess” that it is you “returning” to the web site, typically using fingerprinting if cookies are not available.
Note that because HTTP is intrinsically stateless, you may be “returning” to the web site every few seconds or even more frequently - as there is nothing that directly ties a request for one page with a request for a linked page or a request for resources (e.g. CSS, images, JS) used by the first page.
LOL. I’ve seen that often enough with aggressive anti-cookie settings in my browser.
One alternative is to use HTTP authentication. Then no cookie is needed in order to “implement a stateful session after logging in”, although you could technically argue that it is not stateful. As far as the user of the browser is concerned, the result is the same.
For the first case, you are basically correct. Since you have to authenticate yourself to the web >site, they can store everything that you do and everything that they know about you against the >“username” that you login to, and store it on the server side. They can likewise store your site >preferences on the server side
More and more websites REQUIRE users to logon.
I have no problem with identifying myself by logging into the server.
I would gladly forgo “anonymous” public use, if it meant I would not need to accept a cookie.
One could still have anonymous access to be able to browse a site but if you really mean to access/use a website you would login.
By LOGGING IN you have more security as others need to know your password to be able to hack you.
The BROWSE then LOGIN process is more and more prevalent.
So again cookies on the client are completely unnecessary.
Why? What is your objection to a cookie? Particularly a session-only cookie that is thrown away when you close the browser? How do the privacy implications of that cookie compare with the privacy implications of logging in?
I would not be too quick to embrace being required to login. It depends on how much verifiable information you are required to hand over in order to sign up.
Additionally, part of “privacy” is the ability to be forgotten. If the information is stored on the server, you have zero control over that information. As has been stated multiple times, you can at least delete cookies stored on your computer.
in the case of Banks > EVERYTHING and a LEG
if ONLY ONE server has everything it’s safe to assume that whoever is after your neck has EVERYTHING … the second, third, fourth sign-ups are of little consequence compared to the first …
it’s like they say … your head only needs to be cut off ONCE … if you’d rather keep at it after it’s been loped off then be my guest
Regarding verifiable information. I have refused to use websites that ask for more than what I consider reasonable to verify me, and by reasonable I mean only a response to a confirmation email. If to register I am asked stuff like gender age etc, I either lie or refuse to register as I dont consider these reasonable requests.
Regarding cookies. I dont trust stuff others decide to download to my PC. You just never know what is in the cookie, viruses spyware loggers trackers etc etc.
Please just look up how cookies work. Cookies can just contain text. There is no possibility to let them contain malware. And of course you can look in the cookie. It is stored in your browser and you can look into every of them.
I would broadly agree with this approach. Since new burner email addresses can be created on demand, I don’t mind confirming an email (even though I know the email address will then be spammed forever). For the rest, just lie, yep.
Exploring the security and privacy implications of that is valid.
Depends what you mean by “download”. A session-only cookie should not ever be saved to disk, hence should not ever be made permanent - and if you use an open source browser then that behavior is verifiable.
If the cookie were seeking to exploit some weird Day 0 then the potential exists for the exploit to work even if cookies are disabled i.e. a server can always send a cookie and get the browser to start parsing of that HTTP header even if cookies are disabled. An implementation might even fully parse a cookie before throwing it away.
Somewhere in between those two cases, yes, I suppose, theoretically.
You pretty much know for sure that some cookies will be used for tracking - which is why cookies should be session-only. So I would really only be looking for the malware (virus, spyware, logger) scenario.
Bear in mind that visiting any web site downloads lots of stuff to your computer’s memory and, if you enable caching, to your disk. There are probably easier Day 0s than using cookies.
Only after the fact though.
Anyway, for most web sites, login (authentication) is going to use a cookie. So login is not a valid way of completely avoiding cookies.
Worse still, for valid security reasons, an authentication cookie will generally be opaque. Yes, you can look at it but you won’t learn much.
For example, this forum has given me two session-only cookies viz. _forum_session and _t. The latter is a 128-bit number in hex. The former is quite long (about 600 bytes), comprising what looks like a long base64-encoded value and a 160-bit number in hex. Both cookies are opaque to me. I didn’t learn much by looking at them. I can’t really verify how they are being used.
