[zeta0134]

The information is stored within your web browser, so the instructions to view it will depend on what OS and browser combination you use. In Google Chrome for example, you can view cookies in the Developer Tools (F12, or Menu -> More Tools -> Developer Tools), under the Applications tab. This will show you the cookies visible to the website in your current browser tab. Firefox's developer tools have similar capabilities; I don't know the instructions for other browsers offhand though.

Cookies are sent to the website by your browser automatically when you visit pages. This is usually limited to the cookies belonging to the domain that set them, but the rules allow some flexibility for cross origin sharing. When you hear about tracking cookies, these are most commonly set by an embedded iframe; these can use a different domain from the page that embeds them, and in the case of ad networks this domain is often shared among many sites. These cookies present the largest potential danger to privacy, as they allow a third-party domain to track some browsing behaviors on the host sites in a way that isn't obvious to the user, and this can be used to build up a profile about the sites that user visits most frequently.

If you clear your history in your browser, the website will see no cookies from your browser on the next request. Most sites will simply set a new set of cookies immediately, treating you as a new visitor. You can instruct most browsers to automatically clear your cookies when you exit. Browsers which use a "private browsing" mode also typically use a separate cookie store, so they won't send any cookies from your regular session. From a tracker's point of view, this creates sort of a second user, and in theory should separate that activity from your main accounts. (In practice this can be easily circumvented with browser fingerprinting if a tracker is particularly determined.)

Not all cookies are bad, mind. They're one of the earliest widely adopted implementations of "local storage" for websites, and for a time they were the only reliable way a site could remember a visitor between requests. The most visible effect of clearing your cookies is usually logging you out of everything, since most sites still store your session this way.

[bogomipz]

>"Not all cookies are bad, mind. They're one of the earliest widely adopted implementations of "local storage" for websites, and for a time they were the only reliable way a site could remember a visitor between requests."

Could you elaborate on what you mean by "for a time they were the only reliable way a site could remember a visitor between requests"?

Isn't this still the dominant/primary way websites add state to a stateless protocol? What other way is there for managing se? Is there something that has supplanted cookies for "remembering" or managing sessions?

[antsar]

One approach that doesn't rely on cookies is HTTP Basic Authentication.

The first request to a protected page will produce an authentication prompt[0]. Subsequent requests to the same site will automatically send the same set of credentials (in every browser I'm familiar with. This part of the spec seems to be optional [1]).

Using HTTP Basic Authentication, the server can track the user across different pages. All other state can be maintained on the server side, keyed to the user.

[0] https://i.stack.imgur.com/QnUZW.png

[1] https://tools.ietf.org/html/rfc7617#section-2.2

[bogomipz]

Sure the base64 encoded authorization credentials in the header are the unique identifier in this case. I guess I don't view this so much as an alternative to cookies for general internet browsing much as I do adding a thin layer of security for resources on things like corporate LANs.

[eli]

Why is this better than a session cookie? Basic auth is a pretty wonky user experience. Hard to customize the prompt and "logout" is awkward.

[antsar]

I didn't say it's better :) Just an alternative.

One way to handle logout (without closing the browser) is to have a logout link with a destination of "https://bad_username:[e-mail]". I believe this causes the browser to forget the original (valid) credentials and attempt authentication with the invalid credentials. This will fail, and produce a new login prompt. Then you have to close the prompt, and close the subsequent "401" page.

So yeah, it is awkward.

[eli]

Fair enough. I think modern browsers warn on links with username/password. The UX for basic auth is so bad it is not really a usable feature

[throwawayjava]

> What other way is there for managing se?

In the 90's and early 00's I used to see the session token in the URL of every request.

For example, instead of:

        <a href="https://news.ycombinator.com/threads?id=throwawayjava">Comments</a>

you write:

        <a href="https://news.ycombinator.com/<token>/threads?id=throwawayjava">Comments</a>

or more commonly:

        <a href="https://news.ycombinator.com/threads?id=throwawayjava&token=<token>">Comments</a>

And when making a JSON request, instead of:

        post_with_session_cookie("/auth/api/<et cetera>", ...)

you write:

        $.post("/auth/<token>/api/<et cetera>", ...)

This has other major problems; the most obvious is that it's extremely easy to accidentally session hijack ("oh here's the link to the completed order form: www.yoursite.com/orderForm?token=<my token>"). Also, the attack surface for session-hijacking XSS is a lot larger. There are other security problems.

You can mitigate some of these problems by changing the token on every request, but now your security problem is only a (massive) usability problem.

None of this is the default for any major web framework, which is probably why this style of authentication completely disappeared in the mid 2000's when people stopped rolling their own backends from stratch.

[bogomipz]

Sure. I guess I didn't do a very good job articulating my question. What I really meant to ask is what other alternative exist on the "modern web" to manage session state without cookies. Cheers.

[edjroot]

Adding to the other replies, there's also IndexedDB, which can store considerably larger amounts of information cross-session.

[bogomipz]

Is there a difference between using the LocalStorage API and IndexDB? Are these similar? The same?

[eli]

The LocalStorage API is a more efficient way to store data client side with a a cleaner API

[bogomipz]

But this is where cookies in modern browsers are stored - in the LocalStorage API no?

Aren't they complimentary instead of mutual exclusive?

[die_fault_user]

Thanks!