sandstorm
                                
                                 sandstorm copied to clipboard
                                
                                    sandstorm copied to clipboard
                            
                            
                            
                        perf: static assets and rate of changing hostname
I'm packaging an app, and was looking at browser caching and static assets. It looks like the hostname of a grain is changed when you upgrade its app, so the cache will be invalidated. Perfect for cache busting when static assets potentially change.
However, I realized that it does a lot more than that: it changes the hostname every time you reload the page. This is great for cache busting, but not so great for caching.
I was chatting with @zenhack about this on IRC. He was speculating about whether it would be safe to (if I understand him correctly) make a per-app-version domain just for static assets:
static-<packageid>.sandstorm.io
But he also mentioned we may want to prevent attackers from discovering what is installed on the server. My thought: maybe we could replace packageid with a hash of packageid + sandstorm-installation-wide-secret, maybe throw in current-date? Or just a randomly generated string that we maybe change daily.
Throwing in current-date would unduly defeat caching. Ideally we could even do Cache-Control: immutable for these resources.
The hashing idea is not bad, though I think you want a MAC, not a hash. I don't immediately see problems with doing mac(packageId, secret), though important to think this through obviously. I'm interested in @kentonv's thoughts.
Apps would probably have to opt-in to this in order for Sandstorm to know what files to serve as static assets.
We'd actually probably want to do authenticated encryption, so we could also get a plaintext back that tells us what package to serve based on the hostname.
One minor gap in these schemes is that they may make it possible to tell if other users on the same box have installed a package by uninstalling it yourself and then trying to access the files, to see if they've been deleted. If we care about that I suppose we could incorporate the user somehow, but that seems a bit sad.
Though, we could skip the crypto entirely by just storing a random value in the package table in the database, and looking it up.