From d74a047f7605304eba25941b7bd331058612a6ff Mon Sep 17 00:00:00 2001 From: Paul Adenot Date: Thu, 15 Jun 2023 16:45:59 +0200 Subject: [PATCH] Fix usage of RFC2119 words in privacy and security section This fixes #644. --- index.src.html | 54 ++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 28 deletions(-) diff --git a/index.src.html b/index.src.html index bc949bb8..72fd2c20 100644 --- a/index.src.html +++ b/index.src.html @@ -5577,9 +5577,9 @@ The primary security impact is that features of this API make it easier for an attacker to exploit vulnerabilities in the underlying platform codecs. -Additionally, new abilities to configure and control the codecs MAY allow for new exploits that rely on a specific -configuration and/or sequence of control operations. +Additionally, new abilities to configure and control the codecs can allow for +new exploits that rely on a specific configuration and/or sequence of control +operations. Platform codecs are historically an internal detail of APIs like {{HTMLMediaElement}}, [[WEBAUDIO]], and [[WebRTC]]. In this way, it has always @@ -5604,9 +5604,9 @@ An additional concern is exposing the underlying codecs to input mutation race conditions. Specifically, it SHOULD not be possible for -a site to mutate a codec input or output while the underlying codec MAY still be operating on that data. This concern is -mitigated by ensuring that input and output interfaces are immutable. +a site to mutate a codec input or output while the underlying codec is still +operating on that data. This concern is mitigated by ensuring that input and +output interfaces are immutable. Privacy Considerations{#privacy-considerations} =============================================== @@ -5614,25 +5614,23 @@ The primary privacy impact is an increased ability to fingerprint users by querying for different codec capabilities to establish a codec feature profile. Much of this profile is already exposed by existing APIs. Such profiles are very -unlikely to be uniquely identifying, but MAY be used -with other metrics to create a fingerprint. - -An attacker MAY accumulate a codec feature profile by -calling `IsConfigSupported()` methods with a number of different configuration -dictionaries. Similarly, an attacker MAY attempt to -`configure()` a codec with different configuration dictionaries and observe -which configurations are accepted. - -Attackers MAY also use existing APIs to establish much -of the codec feature profile. For example, the [[media-capabilities]] -{{decodingInfo()}} API describes what types of decoders are supported and its -{{powerEfficient}} attribute MAY signal when a decoder -uses hardware acceleration. Similarly, the [[WebRTC]] -{{RTCRtpSender/getCapabilities()}} API MAY be used to -determine what types of encoders are supported and the -{{RTCPeerConnection/getStats()}} API MAY be used to -determine when an encoder uses hardware acceleration. WebCodecs will expose some -additional information in the form of low level codec features. +unlikely to be uniquely identifying, but can be used with other metrics to +create a fingerprint. + +An attacker can accumulate a codec feature profile by calling +`IsConfigSupported()` methods with a number of different configuration +dictionaries. Similarly, an attacker can attempt to `configure()` a codec with +different configuration dictionaries and observe which configurations are +accepted. + +Attackers can also use existing APIs to establish much of the codec feature +profile. For example, the [[media-capabilities]] {{decodingInfo()}} API +describes what types of decoders are supported and its {{powerEfficient}} +attribute can signal when a decoder uses hardware acceleration. Similarly, the +[[WebRTC]] {{RTCRtpSender/getCapabilities()}} API can be used to determine what +types of encoders are supported and the {{RTCPeerConnection/getStats()}} API can +be used to determine when an encoder uses hardware acceleration. WebCodecs will +expose some additional information in the form of low level codec features. A codec feature profile alone is unlikely to be uniquely identifying. Underlying codecs are often implemented entirely in software (be it part of the User Agent @@ -5641,9 +5639,9 @@ are often implemented with hardware acceleration, but such hardware is mass produced and devices of a particular class and manufacture date (e.g. flagship phones manufactured in 2020) will often have common capabilities. There will be -outliers (some users MAY run outdated versions of -software codecs or use a rare mix of custom assembled hardware), but most of the -time a given codec feature profile is shared by a large group of users. +outliers (some users can be running outdated versions of software codecs or use +a rare mix of custom assembled hardware), but most of the time a given codec +feature profile is shared by a large group of users. Segmenting groups of users by codec feature profile still amounts to a bit of entropy that can be combined with other metrics to uniquely identify a user.