[Webkit-unassigned] [Bug 209907] New: Proposed Intelligent Tracking Prevention changes will break WebRTC certificate API
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Apr 2 08:41:29 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=209907
Bug ID: 209907
Summary: Proposed Intelligent Tracking Prevention changes will
break WebRTC certificate API
Product: WebKit
Version: Safari Technology Preview
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: WebRTC
Assignee: webkit-unassigned at lists.webkit.org
Reporter: tim at pi.pe
CC: youennf at gmail.com
The webRTC API offers mechanism to generate, preserve and reuse certificates, allowing users to verify
the identity of a peer without consulting on the webserver.
The API lets a page generate a certificate with a validity of up to one year, then store it in IndexDB.
Subsequent page loads can read the certificate from IndexDB and use it as part of an RTCPeerConnection.
https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-generatecertificate
Notice that the generated certificate is opaque - it cannot be exported/backed-up/restored from Javascript.
The proposed change in ITP will (If I understand it right) erase IndexDB after 7 days.
This would make the generateCertificate() almost useless.
Here is an example of how we (https://pi.pe) use this feature:
My heating controller trusts webRTC connections from my ipad because it checks that the certificate offered by my ipad during DTLS setup is in the heating controller's trust store. This allows the 2 to communicate securely with no MiTM and no need for a centralized authority.
With your proposed change for this to work, I'd need to be _sure_ that I'd visited the heating management site at least once a week.
My current visit pattern is rarely during the summer months and every few weeks during the winter.
I'd add that the W3c's Proposed IDP identity validation scheme for webrtc also depends on persistent certificates.
Other use cases include app-free access to security cameras, baby monitors et al.
(ref: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ )
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200402/a0d50efa/attachment-0001.htm>
More information about the webkit-unassigned
mailing list