potential information disclosure vulnerability about forget

[codl]

ok now that it's fixed i can expand on it

1. on the front page there are buttons for logging on to mastodon instances, five of them. these buttons remember which instances you tend to log into. this is (was) stored in a cookie. unless you are logged in, this is the only part of the page that changes

2. if your browser supports brotli compression, then once the page is generated it will be hashed and checked against a cache of compressed versions of pages. this is because brotli compression can be slow, so if a compressed version is not found in the cache, it will compress in the background and a gzip version will be returned instead

   this is relevant because it opens up the possibility of an oracle attack. if you get the server to recreate a response that it already served to someone else, you will know because it will already be compressed. and also because there is a header that tells you if the brotli version comes from cache or not

this isn't a problem for the rest of the site, since any page or api endpoint that shows user info also has the actual user ID somewhere, so no other user can get the exact same page

however the front page shows personally identifiable information in which instances are shown but it is not unique per user. someone could craft a cookie (or many cookies) and find out which combinations of instances have been seen before. this is particularly damning if single-user instances are involved, or small instances where it would be easy to identify individual people based on the combination of instances they use.

info that could be gathered this way includes:

1. an identifiable person has logged into forget recently, and the instances they have logged in with in the past (don't know if they have forget enabled)
2. more? i don't know

this has been mitigated by the changes in #176, which move all instance usage information to the client. the server returns the same page for all, showing buttons for the most popular instances. those buttons are then replaced in client-side javascript.

there is still an endpoint, /api/known_instances, which uses the old cookie and returns it verbatim, in order to make the transition from http-only cookie to client-side-only localStorage. oracle attacks on that endpoint are possible but mitigated by random padding causing every response to be virtually unique. that endpoint will only be hit once per browser per user after which the cookie is deleted, and sending hundreds of requests to try and get identical padding (good fuckin luck) will only cause legitimate requests to fall out of the cache faster

anyway thats my login button story thanks for reading