skeggse

https://docs.aws.amazon.com/whitepapers/latest/security-desi... seems like the relevant docs?

DIY Edition. I restarted on my laptop instead of my phone and was able to get it through, though not before missing out on batch 2 :(

I think there was something squirrely with my selection of keyboard options - I wanted two sets of spacers and a numpad, and on my phone I'd selected one set of spacers as primary and added another set of spacers plus a numpad. On my laptop, I chose numpad as primary and added two pairs of spacers, and that seemed to work.

When I click "Add pre-order to bag" it tells me "Please make a selection for each option." I have quadruple-checked, and I have definitely made a selection for each option. What gives? Take my money!

You're right, support for cross-origin form POSTs isn't important for us. What is important, however, is same-origin requests, and Firefox doesn't send the Origin header with those. For us, the Referer serves its most important role by indicating where those requests originate from.

EDIT: when Firefox _does_ start sending the Origin header, we may drop the Referer - we'll see.

For our specific solution, we also rely on (partial) support for Referrer-Policy: https://caniuse.com/#feat=referrer-policy

Well, it's a bug. It absolutely should send the origin header, but it doesn't ¯\_(ツ)_/¯

I would like to note that not all frameworks are viable at-scale. We ran into that with Meteor, as it scaled extremely poorly. It didn't implement CSRF tokens, but also didn't use cookies to store auth data, so it didn't much matter.

We only target recent versions of modern browsers, as a consequence of our user base, so we're more able to move to an origin-based solution.

I'm curious about your comment. We (attempted) to address cases where we needed to infer the Origin from the Referer due to incomplete browser support. What about using both makes this necessarily worse, when the use of the Referer is really only a temporary bandage for said incomplete support?