3 ms·
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?
by die_fault_user 8y ago
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?
- zeta0134 8y agoThe 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.
- die_fault_user 8y agoThanks!
- bogomipz 8y ago>"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 8y agoOne 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 https://i.stack.imgur.com/QnUZW.png [1] https://tools.ietf.org/html/rfc7617#section-2.2 https://tools.ietf.org/html/rfc7617#section-2.2
- eli 8y agoWhy 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 8y agoI 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:bad_password@example.com" 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.
- airstrike 8y agoYou can visit chrome://settings/siteData?search=cookies if you're using Chrome