@Tchanders wrote out a situation in which the browser's local cache expiry could go out of sync from the server's expiry, triggering an IP reveal when the user didn't intend to and logging the action as well as the page they were on at the time. From

1. The user then clicks on a reveal button (they will need to click because local storage was cleared, even though the response is still cached)
2. The key will be set in local storage for 24 hours from that point, even though the cache will time out before 24 hours
3. If the user visits a page after the cache timeout but before the local storage timeout, they'll make another (logged) request just by visiting the page and without clicking a button

With the decision from {T325658#8805061}, this can be considered an edge case and not a hard blocker for T333367: Persist revealed IPs of temporary accounts for 24 hours.

Possible solutions (from Dreamy Jazz):

If the expiry is up on the server side but not on the client side, then don't return the IPs and force the user to press the button
Tell the server to return the expiry for this reveal for at least requests that are triggered by pressing the button (as opposed to the local storage key being set). In cases where the local storage is cleared, the server would therefore return a shorter expiry which would prevent it going out of sync in this way.

Given that the localstorage has been cleared and therefore the browser has no way of knowing that the server will be logging the next automatic IP reveal, it's probably easiest and most-cross-browser compliant to return the expiry with the server and then check for it before any automatic IP reveals happen.

AC:

• automatic IP reveal can't trigger any logged instances of reveals without direct user interaction (ie. the 24 hour expiry server side should be respected by the localstorage instead of the hardcoded 24 hour local expiry)