From dc8474f231c0e262ce9069864bbcd4cdd3b68af6 Mon Sep 17 00:00:00 2001 From: Guohui Deng Date: Fri, 9 Jan 2026 14:14:58 -0700 Subject: [PATCH 1/4] Emphasize the bounds can be dymanically adjusted by implements And remove the recommend bounds that are out of date. Bug:#50 --- README.md | 6 +----- index.bs | 7 +++---- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 3ef77dc..4ee216a 100644 --- a/README.md +++ b/README.md @@ -27,8 +27,7 @@ Proposed Client Hints Header for memory: `Sec-CH-Device-Memory`\ where `` is an approximation of the amount of RAM in GiB (floating point number).\ The `` 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, or across various geographic regions. The following table illustrates some examples: @@ -40,9 +39,6 @@ The following table illustrates some examples: | 1000 | 1024 | 1 | | 1793 | 2048 | 2 | -A full list of possible values is as follows: -0.25, 0.5, 1, 2, 4, 8 - #### 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. diff --git a/index.bs b/index.bs index f21384f..202ab8c 100644 --- 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 Sec-CH-Device-Memory<

Computing Device Memory Value

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, or across various geographic regions. If Sec-CH-Device-Memory header field occurs in a message more than once, the last value overrides all previous occurrences. @@ -90,8 +91,6 @@ If Sec-CH-Device-Memory header field occurs in a message more than Sec-CH-Device-Memory: 1 -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} ======================================= 

From e4983116cc2f7c967b5c0a354b33f69ccf37dcdb Mon Sep 17 00:00:00 2001
From: Guohui Deng 
Date: Fri, 16 Jan 2026 10:36:20 -0700
Subject: [PATCH 2/4] Remove "geographic regions".

---
 README.md | 2 +-
 index.bs  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 4ee216a..a443bab 100644
--- a/README.md
+++ b/README.md
@@ -27,7 +27,7 @@ Proposed Client Hints Header for memory: `Sec-CH-Device-Memory`\
 where `` is an approximation of the amount of RAM in GiB (floating point number).\
 The `` 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 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, or across various geographic regions.
+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:
 
diff --git a/index.bs b/index.bs
index 202ab8c..a3581dc 100644
--- a/index.bs
+++ b/index.bs
@@ -72,7 +72,7 @@ The value is calculated by using the actual device memory in MiB then rounding i
 
 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: The Implementations may set upper and lower bounds and adjust them dynamically over time. These bounds may even differ on different device types, or across various geographic regions.
+    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 Sec-CH-Device-Memory header field occurs in a message more than once, the last value overrides all previous occurrences.
 

From 9d789e548a54200412c2b31629cfbddd9a6d10ee Mon Sep 17 00:00:00 2001
From: Barry Pollard 
Date: Mon, 19 Jan 2026 16:55:00 +0000
Subject: [PATCH 3/4] Update examples using outdated limits

---
 README.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README.md b/README.md
index a443bab..4f1cd38 100644
--- 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.
@@ -33,11 +33,11 @@ The following table illustrates some 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               |
+| 3000          | 2048           | 2               |
+| 3072          | 2048           | 2               |
+| 24576         | 24576          | 16              |
+| 16384         | 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.
@@ -56,9 +56,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.

From fecdce7d174cc07538ec3c512dd692fc7b2317dc Mon Sep 17 00:00:00 2001
From: Barry Pollard 
Date: Mon, 19 Jan 2026 17:20:49 +0000
Subject: [PATCH 4/4] Update examples

---
 README.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 4f1cd38..7d2d717 100644
--- a/README.md
+++ b/README.md
@@ -29,15 +29,16 @@ The `` is calculated by using the actual device memory in MiB then roundi
 
 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 |
 |---------------|----------------|-----------------|
 | 1793          | 2048           | 2               |
 | 3000          | 2048           | 2               |
 | 3072          | 2048           | 2               |
-| 24576         | 24576          | 16              |
+| 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.