This is mentioned at several places, but AFAIK the only reference is on the IDL: https://heycam.github.io/webidl/#SecureContext which in turn links to https://html.spec.whatwg.org/multipage/webappapis.html#secure-context and in turn to https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy This seems to mean we should treat localhost, loopback and files:// addresses as secure when deciding whether a cookie can be modified. For consistency with `document.cookie`, it seems the chromium people want to allow cookie store writing API on localhost/loopback but not `files://` (see https://groups.google.com/a/chromium.org/g/blink-dev/c/ekdeaj09c0w/m/HVpvpMmHBQAJ ). So I think: 1. The spec could more explicitly reference the secure contexts spec in the various places "secure" or "insecure" is used. 2. The spec should explicitly exclude `file://` for consistency with `document.cookie`. Probably 2. can be done in a local definition based on https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url ; and 1. can link to that new definition.