# Real World Forms — narration script

Runtime 8:27. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · Works on my machine

- `0:01` Here's a checkout form. It has a product, a quantity from one to five, a price, a total, a shipping choice, a name, and a box to tick. On its developer's machine, it works perfectly.
- `0:16` Then it goes live. Now it meets people who can edit the page, programs that never load the page at all, customers in other countries with other names, addresses and money, and laws about what a form may collect. Let's meet them, one at a time.

## 0:36 · A web form is not a fence

- `0:37` Every check in this form runs in the browser, and the browser belongs to the person using it. Open the developer tools, and every constraint is just an attribute you can delete.
- `0:51` Remove the limit on quantity. Enable the members-only shipping. And the price, in a hidden field, is just as easy to edit. One cent. Send it, and the server receives exactly that: a price of one cent.
- `1:07` It doesn't even take a browser. One line of curl sends the same order, and never sees the form, so it never learns the constraints existed. All the server ever gets is text.
- `1:20` Think of the form's checks less as a fence that keeps bad things out, and more as a receptionist: helpful, quick, there to start honest people on their way. Then they're passed on to a security guard, on your server, who checks everything again. The receptionist can be talked past. The security guard must never be skipped.

## 1:46 · Trust no data sent from a client

- `1:46` So the server checks everything again, with the same rules: quantity one to five, shipping that this customer is allowed, a name of sensible length.
- `1:58` It never reads a price from a form. It looks the price up from the product, in its own catalog. The price field shouldn't be in the form at all.
- `2:09` It treats every field as untrusted text: encoded before it's shown on a page, so a name can't become a script, and passed to the database as data, never pasted into a query. And it checks that the request came from its own form, not from another site that tricked a logged-in browser into sending it. CSE 135 teaches the server side in full. For now, focus on making the collection smooth.

## 2:41 · On the wire and in the address bar

- `2:41` Between the browser and the server, the form's data crosses networks you don't control. H T T P S encrypts it on the way, for every form, not just the password page. Browsers warn people about password fields on plain H T T P pages, and they're right to.
- `3:03` H T T P S doesn't protect what the URL shows. A form sent with GET puts its fields in the address: in the history, in bookmarks, in server logs, and in the referrer sent to the site's own pages. Anything personal goes in a POST.
- `3:21` For passwords, the current guidance is refreshingly simple. Let password managers fill them in, let people paste, require a long password rather than a complicated one, and don't force changes on a schedule.

## 3:37 · Bots and agents

- `3:38` Not every visitor is a person. Bots fill in forms by the thousand: sign-ups, comments, password guesses. A form can catch a lot of them without bothering anyone.
- `3:52` A honeypot field, hidden from people, that only a bot fills in. A check on timing, because no human completes a checkout in a tenth of a second. Rate limits on the server. And only as a last resort, a challenge, usually a CAPTCHA.
- `4:11` Because a puzzle meant to stop bots also stops people: those using screen readers, or switch controls, or just a small screen on a bad day. The web's design principles say it plainly: when there's a trade-off, put user needs first.
- `4:30` And now some visitors are agents: AI assistants filling in forms on a person's behalf. A well-labeled form is easier for them too. What doesn't change is who decides. The server still must check every value, whoever, or whatever, sent it.

## 4:49 · It's the World Wide Web: people

- `4:50` Real customers aren't all in one country. This form requires a state and a five-digit ZIP code. That fits an address in the United States.
- `5:02` A British postcode mixes letters and digits. A Japanese address is written from the largest area to the smallest. Hong Kong has no postal code at all. For each of them, this form is simply broken.
- `5:17` Ask for the country first and adapt the rest to it. Use one field for a full name, because not everyone has a first name and a last name in that order, or at all. And let people write in their own language and direction.

## 5:34 · It's the World Wide Web: money

- `5:35` Money changes shape too. Americans write one thousand two hundred thirty-four dollars and fifty-six cents with a comma and a point. Germans write the same amount with a point and a comma.
- `5:50` In our test, one browser's number field read a German customer's amount as more than a hundred thousand, without a word of warning. A text field with a decimal keyboard, and a server that knows the customer's locale, does better.
- `6:07` Always say which currency, and never guess it from where someone seems to be. And remember the first lesson: the page shows a price, but the server decides what to charge.

## 6:20 · The rules vary, so aim to collect less

- `6:21` Every field you add is data you have to protect, and a reason for someone to give up. So the best rule is the oldest: collect only what you need, for a purpose you've said, and keep it only as long as you need it.
- `6:38` In much of the world, that's also the law. Europe's privacy regulation requires exactly that minimization, and consent that's really given. A pre-ticked box isn't consent. California has its own privacy law, which reaches many of the sites you'll build.
- `6:59` Children under thirteen bring stricter rules. Card numbers belong in your payment processor's own fields, never yours. And accessible forms are a legal duty in more and more places. None of this is legal advice. It's a reason to ask before you build.
- `7:19` One more thing to know. In a 2022 study, thousands of popular sites sent people's email addresses to tracking companies as they typed, sometimes before they ever pressed send. Every script you put on a page can read every field, so think carefully about whether your third-party dependencies are breaking your rules.

## 7:43 · As always, it starts in the HTML

- `7:43` Real forms meet real people, real attackers, and real rules. The browser helps the person. The server protects the data. And the form in between asks only for what it needs.
- `7:57` JavaScript can take forms further: sending them without a page reload, formatting what people type, saving a draft. The rest of the course gets there.
- `8:08` But HTML is the start. Get it wrong here, and nothing later fixes it. Try the tamper demo on the Form Security page, and see for yourself what a server receives.