3 ms·

What about encrypting every users account info, and then when a GET comes in the server sends over everyones data that has ever logged on from that IP address?

• jlokier 6y ago
  If you're going to send data speculatively by keying on IP address, why not key on long-term user-id cookie instead? That is more accurate and potentially more secure, and for many people the cookie changes less often than their ephemeral IP address anyway. But if the client data is small enough, that wouldn't actually reduce the latency to speed up the page load, if these assumptions hold: - Getting the decryption key is subject to an authorisation round trip; current data fetch is subject to the same round trip; and the client data is small so sending it takes about the same time as sending the key. But the round trip can be brought to a minimum by not requiring a large page full of HTML/CSS/JS to be send on auth - just requiring the client data (or key as you suggested). All the parts which don't depend on client data can be preloaded asynchronously after the login page is shown, including a template for the page ready to be populated when client data is received. So: - Make the login page as fast as possible, using inlined data etc. like any static page. Make the page cacheable, probably validated with an Etag. The remembered "your name" field can be populated, that's fine even if it's cached because the browser cache ("Cache-Control:private") is unique to the user. - Have the login page preload all non-client-data dependent resources for the next page asynchronously, but ensure these don't start fetching until all resources for the login page itself have finished being fetched. - When password is entered, perform auth and get client data in a single round trip, combine with the templates just loaded to load the new page. - Use 0-RTT TLS for everything. Each interaction will be about as fast as possible while validating with the server, but you can go further if you're ok with relaxing that: - Make the first page load "instant" by changing the cache policy to validate after a timeout instead of just on Etag. - Asynchronously preload all the resources for the authenticated next page except the client data. - Make the authenticated next page "instant" by detecting when the user appears to have paused typing in the password field (or immediately without pause if it's refilled by a password manager or user paste into it), and before they hit enter or click submit, send speculative auth requests which return client data if they succeed, but don't treat the user as properly authorised until they do enter/submit. When they do, use the preloaded client data if it's already arrived (and the password field hasn't changed), and also send an auth-confirm request.