From 0d4b45fbb49f0321fbcec5c9ec338423be085100 Mon Sep 17 00:00:00 2001 From: Mark Watson Date: Mon, 12 Feb 2024 11:20:44 -0800 Subject: [PATCH] Issue #176: Add comments to privacy section to address issue. --- index.bs | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index fc2e010..ea9497b 100644 --- a/index.bs +++ b/index.bs @@ -1212,7 +1212,15 @@ spec: encrypted-media-draft; for: EME; urlPrefix: https://w3c.github.io/encrypte categories, within which capabilities are similar thus minimizing effective entropy.

- +

+ An alternative design approach in which sites expose the available media + formats and browsers evaluate these against capabilities, returning only + the chosen format was considered. However, this would not in fact offer + a privacy benefit since sites could use the API repeatedly to obtain the + complete capability set. Stringent rate limiting of the API could interfere + with normal site behaviors such as speculative preparation across multiple + playback items. +

If an implementation wishes to implement a fingerprint-proof version of this specification, it would be recommended to fake a given set of @@ -1221,8 +1229,11 @@ spec: encrypted-media-draft; for: EME; urlPrefix: https://w3c.github.io/encrypte degrade the user's experience. Another mitigation could be to limit these Web APIs to top-level browsing contexts. Yet another is to use a privacy budget that throttles and/or blocks calls to the API above a - threshold. + threshold. Additionally, browsers may consider whether a site goes on + to make use of the capabilities it detects and apply more stringent + controls to sites that are observed not to do so.

+