Well, those are some big differences. I'm not sure there's anything else I can name.
Sure. Suppose that you want the database to contain users's actual submissions. Maybe they are submitting HTML for some reason, or they are submitting math that might use the less-than sign (<
).
So you don't want to replace the less-than sign with <
, because that messes up the data you want to process.
But, to display it on the web page, you need to do those replacements, or the browser will be confused and you'll open your users to XSS attacks.
If you trust the users and/or the data. If you know that they are
only submitting benign HTML, you can mark it as | safe
and allow it to be rendered into the template without encoding.
Yeah, it's not obvious. When the web first came out (1992, Tim Berners-Lee at CERN), there was no encryption. Just HTTP, running on port 80.
When encryption came along, they still had to maintain the un-encrypted option.
So, servers listen on two ports: 80 for HTTP, and 443 for HTTPS.
Many servers, including Tempest, now automatically redirect traffic coming to port 80 to port 443.
Great question! Cookies by and large don't store sensitive data. At least, I haven't seen many examples. They mostly just have unique identifiers.
The main concern is privacy: those unique identifiers can allow you to be tracked for a variety of reasons: what pages do you visit? how long do you spend? do you start to fill out any forms? Where are you when you do these things? They really like location information.
If the unique identifier is used from a common website,
e.g. advertisements from doubleclick.net
and many
others, those common websites can track you across multiple
websites, which allows much greater tracking / invasion of privacy.