Privacy

What it means for a web client

Security asks whether an attacker can get in. Privacy asks a quieter question: what does the page leak while working exactly as designed? A query string lands in server logs. A cookie rides along on every request. An analytics script reports what the reader did. None of that is a breach. All of it is a disclosure you chose, whether or not you noticed choosing.

The course's list of stakeholders puts privacy among the things users want, next to speed and getting the task done, and notes that users are rarely consulted directly. Regulations such as GDPR force the issue; the better reason is the privacy-conscious user from The Browser for Programmers, whose concern is not only whether the connection is encrypted but who else is watching from inside the page.

The browser does a great deal for that user. Origins isolate one site's data from another's. Storage is now partitioned by the top-level site, so an embedded widget cannot use it to recognize someone everywhere they go, and browsers increasingly restrict third-party cookies, the classic cross-site tracking mechanism. What the browser cannot do is protect a reader from the page itself. Anything you load into your origin runs with your origin's authority, and anything you put in a URL or a request goes wherever that URL or request goes.

So privacy for a web client comes down to three habits: collect less, send less, and embed less. Each layer of the course gives you a place to practice them.

Where it lives in each layer

Structure

A URL is the leakiest container on the web. Whatever you put in it shows up in the address bar, history, bookmarks, server and proxy logs, and the Referer header. Search terms and filters belong there; passwords, tokens, session IDs and personal details never do. A form's method makes the same choice in markup: GET puts fields in the URL, POST puts them in the body. And every <script>, <img> or <iframe> pointing at another server is a request that tells that server your page was opened.

Presentation

Presentation leaks less, but it is not neutral. A web font or background image served from a third party is a request to that party on every page view. The platform also guards presentation on the reader's behalf: browsers limit what :visited can style and report unvisited styles to script, so a page cannot read someone's browsing history out of link colors.

Interaction

A script on your page sees what the reader types, passwords included, and nothing in HTML gives it less power than the page has. The same-origin policy does not help, because the script runs inside the origin it is watching. Good APIs are designed the other way around: the EyeDropper hands the page exactly one color the user picked, not a view of the screen. Client-side storage holds whatever you put there, so store only what the feature needs.

Delivery

Cookies carry flags that are privacy and security controls at once: HttpOnly hides a session token from script, Secure keeps it off plain HTTP, and SameSite decides whether it rides along on requests other sites trigger. A cross-origin fetch sends no cookies unless you ask for credentials: 'include', and the server must opt in. A proxy keeps an API key off the client, but its shared cache can hand one user's private response to another. Exit beacons are requests the reader cannot see or cancel; know what is in the payload.

Where the course teaches it

• VII. The security model: origins, cookie flags, third-party cookies as tracking, and the keylogging page the same-origin policy cannot stop.
• VIII. State, storage, and caching: storage as a tracking surface, and why browsers now partition it by top-level site.
• Everything You Embed: first and third parties, the script that watches, and Content Security Policy as a limit on where data may go.
• URLs: URL security: every place a URL is exposed, and what never belongs in one.
• URLs: URLs and state management: the shareability test for what belongs in a URL and what does not.
• 01. The form already talks: GET versus POST as a privacy decision, and what the Referer header carries.
• 08. Other people's data: credentialed requests, reflected origins, and what a proxy and its shared cache take on.
• 09. Beyond request and response: exit beacons and saying what you send.
• Who is visiting?: visitors with content blockers, strict tracking protection or a VPN, and the needs those settings create.
• The Life of a Page Load: the ladder of user needs; privacy expectations sit on the acceptance rung, and a blocked tracker must not break availability.

Check your own page

1. Open the Network panel, reload, and filter out your own origin. Name every remaining host and why the page needs it. Remove the ones you cannot justify.
2. Submit each form and read the resulting URL. If a password, email address, token or anything typed in confidence appears in it, move it to a POST body or a header.
3. In the Application panel, list every cookie and storage key your page sets. Check that session cookies carry HttpOnly, Secure and a deliberate SameSite value.
4. Turn on a content blocker or strict tracking protection, reject all cookies, and complete the main task. If the page breaks, something essential is waiting on a tracker.
5. For every beacon or analytics call, write down the fields in its payload. Drop the ones nobody has asked a question about.