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.