Restricted sheets still serve their CSV export: confirm the old IDs are actually dead

[gaurav]

Both Google Sheets have been restricted (link sharing turned off), but their CSV export URLs still return data. Until that stops being true, the rotation is not finished: the old IDs are checked into main and are in this repository's public history, so anyone who has ever cloned it holds a working key.

This is the endpoint that matters — the one the code actually fetches, not the /edit URL:

https://docs.google.com/spreadsheets/d/<ID>/gviz/tq?tqx=out:csv&sheet=Tests

Built in google_sheet_test_cases.py and blocklist.py.

Things to rule out, cheapest first

1. Testing while signed in as the owner. The likeliest explanation by far, and it isn't caching: the browser sends your Google cookies, and the owner can always read the document whatever the sharing setting says. The real test sends no credentials at all:

   curl -sS -o /dev/null -w '%{http_code} %{size_download} bytes\n' \
     "https://docs.google.com/spreadsheets/d/<OLD_ID>/gviz/tq?tqx=out:csv&sheet=Tests"

   A restricted sheet answers 302 to a sign-in page (accounts.google.com), not 200 with CSV. Add -L and check where it lands. Run it in a container or with --no-cookie if there is any chance of ambient credentials.

2. "Publish to web" is a separate switch from link sharing. File → Share → Publish to web. If it was ever enabled, the document stays publicly readable through its own /pub?output=csv URL after link sharing is restricted, and the gviz endpoint may serve from that publication too. It has to be stopped explicitly ("Stop publishing"). This is the failure mode most likely to look like "caching that will sort itself out" while actually being permanent.

3. Edge caching, which is real but short. Google does serve exports through a CDN, and a previously-fetched CSV can survive a permission change for minutes. If (1) and (2) are clean, re-test after an hour before concluding anything.

4. Copies. A copy taken while the sheet was link-shared is a separate document with its own ID and its own sharing; restricting the original does nothing to it. (Drive has been checked for copies owned by the maintainer — worth remembering that a copy taken by someone else is not visible or revocable from here at all.)

Done when

curl with no credentials returns a sign-in redirect for both old IDs, on both the gviz CSV endpoint and /pub?output=csv.

Filed from the sheet-ID rotation in #117. Do not paste the old IDs into this issue or its comments — the point of the exercise is that they stop being readable, and this issue is public.

[gaurav]

Confirmed: it was owner-session access, not caching. A credential-free curl against the gviz CSV endpoint returns 401 for the old IDs, so the restriction did take effect immediately — the earlier "both URLs still work" was the browser sending the owner's Google cookies, which no sharing setting applies to.

One correction to the reproduction above for anyone re-running it: this endpoint answers 401 directly rather than the 302 to accounts.google.com I predicted. Either is a pass; 200 with CSV is the failure.

Still worth doing before this closes: the Publish to web check (item 2), since that is a separate switch from link sharing and would not have been affected by restricting the link.

curl -sS -o /dev/null -w '%{http_code}\n' \
  "https://docs.google.com/spreadsheets/d/<OLD_ID>/pub?output=csv"

[gaurav]

Both old IDs now return 401 on the Publish-to-web endpoint (/pub?output=csv) as well as the gviz CSV export, credential-free. Neither sheet was ever published to the web, or it was stopped along with the link sharing — either way both paths are closed.

Repository secrets rotated to the new IDs (2026-09-01), so the old IDs checked into main and sitting in this repository's history are now inert. Closing.

Not yet verified end to end: no dashboard run has used the new IDs. That is the first run after #120 merges, and if the new secrets were mistyped it fails at collection with "No Google Sheet ID" rather than anything subtle.