Browser DPoP keys should be non-exportable

[matthieusieben]

I know having to rely on indexeddb to store keys has a few downsides but using non-exportable keys is best to properly protect users in case of XSS (including self-XSS, and protection against browser extensions).

[mary-ext]

Yeah, unfortunately I don't think I'd be changing my decisions any time soon so I'd be closing this as a wontfix for now.

The initial versions of the client went for IndexedDB before I eventually switched it out, I think I've laid out my reasons for not liking IndexedDB before, but maybe to reiterate it in full detail:

1. Safari lockdown mode disables IndexedDB, I could simply not support it if I want to but supporting friends using lockdown mode seems more of my thing.
2. To add onto this, Apple's subpar response with Safari 14 breaking IndexedDB in the past has left me sort of questioning if Apple even cares about IndexedDB at all, especially since the issue is non-reproduceable with the mainline WebKit builds (which Safari TP uses, release versions of Safari uses a private cherry-picked branch which is how the issue got introduced)
   • I hate Apple devices, but unfortunately supporting Safari is still something I have to do even if I don't own any devices I could test, and I'd like to stay on their good side if possible.
3. I wasn't interested in maintaining two separate paths for storage persistence, and at the same time, I personally don't see the need for making storage a public API that'd allow for swapping it out at the very least.

I think at this point IndexedDB should be very standardized which might make the gist document I've linked in the README to be irrelevant, but after mulling on the decision for a week or so based on the info I've gathered so far it just doesn't seem like it'd be worth sticking to IndexedDB just for the non-exportable keys.