Re: CfC to remove Peripherals APIs from the Devices and Sensors WG Charter

As an interested user of these APIs, we'd prefer to retain them as
tentative deliverables, provided the paper's concerns are addressed in a
threat model review. Or is the implication that they will move to the
Peripheral APIs workstream, and undergo the review there?

The paper itself suggests the findings are fixable within the APIs, so the
specifications can be amended. Some of my own suggestions would be to
add more granularity, possibly by gating them behind some of the new
permissions proposals, time-limiting the grants, adopting mitigations
similar to COEP + COOP used for SharedWorker, or specifying an opt-in CSP
policy, might help?

What about dropping the deliverables, but if Peripherals is not established
within 6 months, re-adopting them as tentative and addressing the issues
here?

On Mon, 24 Aug 2026 at 21:30, Mike Jackson (EDGE) <mjackson@microsoft.com>
wrote:

> Microsoft believes these APIs address important use cases and fit within
> the scope of the Devices and Sensors Working Group. We would prefer that
> the group retain them as tentative deliverables and continue developing
> them, while taking the documented security concerns including firmware
> reprogramming, device abuse, persistent grants, and fingerprinting
> seriously.
>
> The Formal Objection's alternative conditions largely describe work that
> will be necessary regardless of venue: documenting known exploit classes,
> defining normative mitigations where feasible, obtaining appropriate
> security and privacy review, and clearly identifying risks that remain with
> user agents or device vendors. Adoption as a tentative deliverable would
> provide a venue for that work and would not endorse the current designs or
> guarantee advancement to Recommendation.
>
> Despite our concerns, we will not block consensus to remove these
> deliverables from the DAS charter. Given the proposed WHATWG Peripheral
> APIs workstream (https://github.com/whatwg/sg/pull/264), removal would
> primarily change the venue rather than end the work. We encourage continued
> iteration on these APIs and expect the concerns raised by the Formal
> Objection to be addressed before they advance in either venue.
>
> -Michael
> Sent from Outlook <http://aka.ms/weboutlook>
>


-- 
Will Morgan
Head of Innovation, Physical Access
iProov

-- 


This email (and any attachment) is confidential.  If you are not the 
intended recipient, kindly forward the email to security@iproov.com 
<mailto:security@iproov.com> and delete it from your systems; you must not 
use the email or any of its (or any attachments) content for any purpose, 
or reproduce, store, or disclose it or any such content to anyone.  Views 
expressed may not be those of the Company, but be the personal views of the 
email’s author.   No right or licence is to be deemed granted, or 
obligation deemed accepted, by the Company until a written agreement is 
negotiated and executed between the relevant parties.  Agreements may only 
be concluded by officers authorised to execute contracts on behalf of the 
Company.  

iProov Limited (Registration No.07866563), incorporated in 
England and Wales.  Registered Office: 14 Bank Chambers, 25 Jermyn Street, 
London, SW1Y 6HR.  

References to Company mean iProov Limited and (where 
relevant) its subsidiaries iProov, Inc. (a Delaware corporation) and iProov 
PTE Ltd (a Singapore company).