Alternative storage for RTCCertificates needed
Opened this issue · 6 comments
This option allows applications to establish key continuity. An RTCCertificate can be persisted in [INDEXEDDB] and reused. Persistence and reuse also avoids the cost of key generation.
Due to fingerprinting concerns the lifespan of IndexedDb may be significantly shorter than the certificate expiry. (Safari: 1 week vs 1 year). It would be useful to have an alternative way to persist RTCCertificates that at least matched the expiry.
This issue was discussed in WebRTC March 26 2024 meeting – 26 March 2024 (Alternative storage for RTCCertificates neededWebRTC API)
https://storage.spec.whatwg.org/#dom-storagemanager-persist was mentioned but this (if I understand it) doesn't differentiate between RTCCertificates and anything else in IndexedDB.
I notice the slides have a typo (which I unfortunately wasn't there to correct)
It should have read :
Proposal 1
Save to NON indexedDB store (borrowed from MediaKeySession) :
RTCCertificate.load(fingerprint)
RTCCertificate.store(certificate)
This assumes the app knows the fingerprint - but that can be stored in
a URL param.
This clearly differentiates RTCCertificates from other IndexedDB contents - and puts them in the same category as DRM media keys, which may be appropriate.
For additional motivation, read https://storage.courtlistener.com/recap/gov.uscourts.cand.369872/gov.uscourts.cand.369872.735.0.pdf
I do not see certificates as largely different from other stored data.
There is a tradeoff between privacy and storage lifetime.
Maybe there is a way to reconcile both by allowing the web page to get access to persisting storage (see https://storage.spec.whatwg.org) once the user gets logged in/identified (say via pass keys).
It might be good to discuss this area in a forum focusing on privacy, like the privacy CG for instance.
The difference is that a page cannot extract an RTCCertificate and back it up server side (or locally) - unlike anything else in indexedDB.
The difference is that a page cannot extract an RTCCertificate and back it up server side
Sure and this was made by design.
Save to NON indexedDB store (borrowed from MediaKeySession) :
If there is a need to get some data from the server, it seems half of the signaling channel is already set up.
It would be interesting to understand what we would gain from this additional API.
Also, it still allows a web site to query this non IDB store, thus weakening the privacy.
Privacy aware UAs would probably put a max lifetime on this kind of data.
Which makes also sense from a hard-drive usage point of view.