Download tracking

It is an application event, written when a download is attempted, not a field in the file. NIST SP 800-92 treats this class of record as a security log: it is useless later if it lacks time, identity, and outcome.

A web server access log is the raw material. It shows an IP, a URL, a status, a user agent, and a byte count. It does not, by itself, know that three Range requests were one person finishing a file. Tracking worth showing a sender stitches those requests into one transfer: started, completed, failed, bytes sent. A notification is a message fired from that event. The notification is not the record. If the mail fails, the log should still have the row.

A client link for a 2 GB master is opened at 16:12 from an office IP. The log shows a 200, then four 206 range responses, totaling 2,147,483,648 bytes by 16:40. The sender's screen marks "downloaded once, completed." A second open at 17:05 from a phone IP sends 40 MB and stops. That row is a partial, not a second complete delivery. A product that emails "your file was downloaded" on the first byte will page the sender at 16:12 and again at 17:05 for a fetch that never finished. The useful event is completion, with partials available on the same timeline.

Tracking is not access control. It observes. It does not stop the next fetch unless some other rule, such as a one-time counter, reads the same event and denies. It is also weaker than it looks. The IP is the network egress, not a person. A VPN, a NAT, and a CDN edge all put someone else's address on the row. A signed-in account is a better identity than a raw IP, and SP 800-92's point is that you decide which identity you need before the incident, not during it.