Every browser has developer tools that allow users to see cookies and even modify them. What that means is that the application cannot trust the cookie. It might have been tampered with. The application also can't assume there will *be*a cookie, even if it set one, because the user might have deleted it.

They build in resilience to tampering. Next time, we'll learn about Flask sessions, where the cookie is digitally signed, so that tampering is evident. If the session cookie has been tampered with, Flask automatically drops it, as if there were no cookie at all.

In our little example, there's only one form and it's used for login, and login is when we set a cookie.

In general, a form could be used for lots of things, not just login.

Sure. I'll demo accessing cookie info (if I haven't already). The "visit again" buttons just allow us to generate new requests to the app, so that we can see the continuity over a series of interactions.

Good question. That's always seemed weird to me. But the API for cookies is all about replacing the current cookie with an updated value. Typically, that means changing the expiration time, usually to the future. If you set it to the past, though, the cookie expires and the browser deletes it. So, it's an easy way to delete a cookie without making the API more complex.

Sure. They are similar in that it is data that the browser keeps.

They differ in that caching allows the browser to skip re-requesting supporting files (CSS, JS, images like logos, etc) that it already has, while

cookies are sent with the request to allow continuity (memory) across requests.

For sure!