Where is this information stored on my computer? Is there a central location for the information that I can look at or software to read the cookies?
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.
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?
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.
One way to handle logout (without closing the browser) is to have a logout link with a destination of "https://bad_username:bad_password@example.com". 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.
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>
<a href="https://news.ycombinator.com/<token>/threads?id=throwawayjava">Comments</a>
<a href="https://news.ycombinator.com/threads?id=throwawayjava&token=<token>">Comments</a>
post_with_session_cookie("/auth/api/<et cetera>", ...)
$.post("/auth/<token>/api/<et cetera>", ...)
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.
Aren't they complimentary instead of mutual exclusive?