Emphasize the bounds can be dymanically adjusted by implements (#53)

guohuideng2024 · Guohui Deng · tunetheweb · web-flow · commit 8eebca05398b · 2026-01-19T21:17:17.000Z
* Emphasize the bounds can be dymanically adjusted by implements And remove the recommend bounds that are out of date. Bug:#50 * Remove "geographic regions". * Update examples using outdated limits * Update examples --------- Co-authored-by: Guohui Deng <guohuideng@microsoft.com> Co-authored-by: Barry Pollard <barrypollard@google.com>
diff --git a/README.md b/README.md
@@ -12,7 +12,7 @@ Developers are interested in the “device class” for the following known use-
 2. Normalize Metrics: analytics need to be able to normalize their metrics against the device-class. 
 For instance, a 100ms long task is a more severe issue on a Pixel vs. on a low end device.
 
-Device memory is an interesting signal in this context. Low memory devices devices (under 512MB, 512MB-1GB) are widely used in emerging markets. Chrome telemetry indicates a large number of OOM (out-of-memory) crashes on foreground tabs on these devices. In this case, serving a lite version not only improves the user experience, it is necessary for the site to be usable at all (as opposed to crashing due to memory constraints).
+Device memory is an interesting signal in this context. Low memory devices devices are widely used in emerging markets. Chrome telemetry indicates a large number of OOM (out-of-memory) crashes on foreground tabs on these devices. In this case, serving a lite version not only improves the user experience, it is necessary for the site to be usable at all (as opposed to crashing due to memory constraints).
 
 ## Proposal
 We propose a new HTTP Client Hints header and a web exposed API to surface device capabilities for memory (RAM). The mechanism should be extensible to other device capabilities such as CPU i.e. number of cores, clock speed etc.
@@ -27,21 +27,18 @@ Proposed Client Hints Header for memory: `Sec-CH-Device-Memory`\
 where `<value>` is an approximation of the amount of RAM in GiB (floating point number).\
 The `<value>` is calculated by using the actual device memory in MiB then rounding it to the nearest number where only the most significant bit can be set and the rest are zeros (nearest power of two). Then dividing that number by 1024.0 to get the value in GiB.
 
-An upper bound and a lower bound should be set on the list of values. While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
-The upper and lower bounds are not explicit, as they are subject to change over time.
+An upper bound and a lower bound should be set on the list of values so the fingerprinting is mitigated. The Implementations may set upper and lower bounds and adjust them dynamically over time. These bounds may even differ on different device types.
 
-The following table illustrates some examples:
+The following table illustrates some examples (note no bounds are set in these examples):
 
 | Actual in MiB | Rounded in MiB | Reported in GiB |
 |---------------|----------------|-----------------|
-| 500           | 512            | 0.5             |
-| 512           | 512            | 0.5             |
-| 768           | 512            | 0.5             |
-| 1000          | 1024           | 1               |
 | 1793          | 2048           | 2               |
-
-A full list of possible values is as follows:
-0.25, 0.5, 1, 2, 4, 8
+| 3000          | 2048           | 2               |
+| 3072          | 2048           | 2               |
+| 3073          | 4096           | 4               |
+| 16384         | 16384          | 16              |
+| 24576         | 16384          | 16              |
 
 #### Why separate header and rounding?
 HTTP caching doesn't deal well with mixed value headers, therefore separate headers are recommended. Also, rounding down to power of two enables caching and mitigates fingerprinting.
@@ -60,9 +57,9 @@ Servers can advertise support for Client Hints using the Accept-CH header field
 ```
 
 The Memory request header field is a number for the client’s device memory i.e. approximate amount of ram in GiB.
-eg. 512 MiB will be reported as:
+eg. 2024 MiB will be reported as:
 ```
-  Sec-CH-Device-Memory: 0.5
+  Sec-CH-Device-Memory: 2
 ```
 
 Servers can use this header to customize content for low memory device eg. serve light version of the app or a component such as a video player.
diff --git a/index.bs b/index.bs
@@ -7,6 +7,7 @@ Status: ED
 ED: https://www.w3.org/TR/device-memory/
 TR: https://www.w3.org/TR/device-memory/
 Editor: Barry Pollard, Google https://google.com, barrypollard@google.com, w3cid 138839
+Editor: Guohui Deng, Microsoft https://microsoft.com, guohuideng@microsoft.com, w3cid 158258
 Former Editor: Shubhie Panicker, Google https://google.com
 Repository: w3c/device-memory
 Abstract: This document defines a HTTP Client Hint header and a JavaScript API to surface device capability for memory i.e. device RAM, in order to enable web apps to customize content depending on device memory constraints.
@@ -69,9 +70,9 @@ The ABNF (Augmented Backus-Naur Form) syntax for the <code>Sec-CH-Device-Memory<
 <h3 dfn>Computing Device Memory Value</h3>
 The value is calculated by using the actual device memory in MiB then rounding it to the nearest number where only the most significant bit can be set and the rest are zeros (nearest power of two). Then dividing that number by 1024.0 to get the value in GiB.
 
-An upper bound and a lower bound should be set on the list of values.
+An upper bound and a lower bound should be set on the list of values. The range between the upper and the lower bounds should include the majority of device memory values but exclude rare device memory values to mitigate device fingerprinting.
 
-    NOTE: While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
+    NOTE: The Implementations may set upper and lower bounds and adjust them dynamically over time. These bounds may even differ on different device types.
 
 If <code>Sec-CH-Device-Memory</code> header field occurs in a message more than once, the last value overrides all previous occurrences.
 
@@ -90,8 +91,6 @@ If <code>Sec-CH-Device-Memory</code> header field occurs in a message more than
     Sec-CH-Device-Memory: 1
 </pre>
 
-A full list of possible values should be as follows: 0.25, 0.5, 1, 2, 4, 8
-
 Device Memory JS API {#sec-device-memory-js-api}
 =======================================
 <pre class="idl">
