dogeorg / dogeboxd

Dogebox system manager service
MIT License
1 stars 0 forks source link

Remembering port allocations for uninstalled pups #67

Open tjstebbing opened 1 month ago

tjstebbing commented 1 month ago

If a pup is uninstalled and even purged there is merit in remembering it's public port allocations (specifically admin ports) and not reusing them for other pups, this is because browser caches for content that previously existed on that port can leak private information, ie: local storage content, to the new pup.

Solution 1:

remember a port allocation counter++ and never reallocate, ever. That means pup X might be 10001, and later reinstalled to 10034, but no other pup would ever occupy 10001.

Pros: easy to implement, fully reinstalled pups get a 'clean slate' no state pollution from old install

Cons: port exhaustion eventually (like.. a long time but there is a limit)

Solution 2:

remember port allocation per pup source forever and reallocate to that pup again.

Pros: pups get their old browser state back if it exists

Cons: need to keep things around that may never be used again

raffecat commented 1 month ago

Cons: need to keep things around that may never be used again

Is it just a mapping from (source,pup-name) to port number? That seems fairly insignificant. If it affects queries, we could filter them out with an indexed bool, or put port mappings in their own table, etc.

An alternative idea

Prefix the entire admin site with the pup-id. Authors must use relative urls.

I'm not sure if this potentially breaks some things.

Caching problems

In any case, html pages should never be cached for more than a minute or so. This is something the web server must set in the response header. Using 10s-60s is for the benefit of the CDN, so it can actually cache it and do request-coalescing.

The browser will do an If-Modified check after that time, and usually won't download anything.

Other resource types, like scripts, css, especially images are often versioned so they can be cached for 30 days. Without versioning, whatever cache time you pick will still lead to re-using old cached files when you update the pup to a new version.

We could just inject Cache-Control: private; max-age:10 into every response and let the CDN and 304 checks do their thing.

Worst of all: if a response lacks a Cache-Control header, the default browser policy is to cache it forever. Until you force reload the resource itself (not even the page that loads it.) This is to be avoided at all costs.

SomeoneWeird commented 1 month ago

The bigger issue is that pups may potentially save sensitive content in the users browser (local storage, cookies, whatever) that can then be read by any subsequent pup that gets hosted on that ephemeral port.