Add MediaDevices info to web platform integration. (#123)

* Add MediaDevices info to web platform integration.

Based on https://crbug.com/1307642 and corresponding discussion, we need to specify how deviceID from the MediaDevices interface is partitioned within fenced frames.

* Add more specific wording for identifier uniqueness.

explainer/integration_with_web_platform.md

@@ -85,9 +85,16 @@ For more details, the implementation design doc can be found [here](https://docs
 
 For privacy implications of this API and others, see [the privacy considerations](https://github.com/WICG/fenced-frame/blob/master/explainer/README.md#privacy-considerations) section.
 
-## Screen Interface
+## Screen interface
 The [Screen interface](https://drafts.csswg.org/cssom-view/#the-screen-interface) provides information about the screen of the browser's output device, and as a result that information is visible to both fenced frames and the embedder. Currently there are no plans to fence the Screen interface, meaning that its attributes will retain the same values in both the fenced frames and their embedders. Justification for this decision can be found [here](https://docs.google.com/document/d/1sZOgnAUsIzNHOs_VVWF92er1jXmNCcv6k3vvOvixeFc/edit?usp=sharing). 
 
+## MediaDevices interface
+The [MediaDevices interface](https://w3c.github.io/mediacapture-main/#mediadevices) is able to list connected media devices via the [`enumerateDevices()`](https://w3c.github.io/mediacapture-main/#dom-mediadevices-enumeratedevices) method. The `deviceID` field in this method's output can potentially create consistent identifiers between same-origin frames embedded in different first-party sites. The [specification for `deviceID`](https://w3c.github.io/mediacapture-main/#dom-mediadeviceinfo-deviceid) states:
+
+"To ensure stored identifiers are recognized, the identifier MUST be the same in Documents of the same origin in top-level traversables. In child navigables, the decision of whether or not the identifier is the same across documents, MUST follow the User Agent's partitioning rules for storage (such as localStorage), if any, to not interfere with mitigations for cross-site correlation."
+
+Fenced frames partition storage using a unique nonce, so that no other frame can access the same partitioned storage as a given fenced frame. As a result, deviceID values will always be different within two fenced frames and similarly the value in a fenced frame will always differ with that in other iframes/top-level frames, even if their origin is the same.
+
 ## Chromium implementation: Top-level browsing context using MPArch
 Chromium is implementing [Multiple Page Architecture](https://docs.google.com/document/d/1NginQ8k0w3znuwTiJ5qjYmBKgZDekvEPC22q0I4swxQ/edit?usp=sharing) for various use-cases including [back/forward-cache](https://web.dev/bfcache/), [portals](https://wicg.github.io/portals/), prerendering etc. This architecture aligns with fenced frames requirement to be a top-level browsing context as MPArch enables one WebContents to host multiple pages. Additionally, those pages could be nested, as is the requirement for fenced frames.