From b4af6ac6a80b4112c13e95147a0a86298a90e960 Mon Sep 17 00:00:00 2001
From: Jan-Ivar Bruaroey
spec:payment-request; urlPrefix: https://w3c.github.io/payment-request/
@@ -123,7 +124,7 @@ spec: RFC8941; urlPrefix: https://datatracker.ietf.org/doc/html/rfc8941#
will actually be granted the ability to use that API.
SecureCorp Inc. restructured its domains and now needs to needs to delegate +
SecureCorp Inc. restructured its domains and now needs to delegate
use of the Geolocation API to its origin ("https://example.com
")
as well as three subdomains ("https://geo.example.com
",
"https://geo2.example.com
", and "https://new.geo2.example.com
").
@@ -163,6 +164,51 @@ spec: RFC8941; urlPrefix: https://datatracker.ietf.org/doc/html/rfc8941#
to use the Geolocation API, but any other ports on "https://example.com
"
could use it too.
JSPlaygroundCorp Inc. wants to host user-generated web applications, but wants the + browser to manage their permissions to use [=powerful features=] in isolation of each other. + This can be accomplished by creating discrete subdomains for each piece of web-content + or web-content creator, and navigating them as top-level documents (framework and + user-content can still be separated using same-origin iframes). + + This is necessary since users grant permissions to the domain they perceive they + are interacting with in the browser, which is the top-level domain. + + JSPlaygroundCorp should avoid iframing user-generated web applications using the + <{iframe/allow}> attribute from its own domain in this case, as this would grant + its domain permissions to all of them. +
PlatformCorp Inc. wants to offer a marketplace of embeddable third-party + components to build from or games to play under its top-level domain. It wants to + delegate the use of [=powerful features=] like the {{MediaDevices/getUserMedia()}} + API responsibly. It accepts responsibility for tracking which of its component + applications need a feature, using bespoke "install" UX to keep end-users in + charge.
+Camera and microphone are disabled by default in all cross-origin frames. + Each third-party component has a subdomain, and can be embedded in a + cross-origin iframe. PlatformCorp can use the <{iframe/allow}> attribute on + the <{iframe}> element to control whether to delegate camera or microphone + access or not to each subdomain. + + An iframe where the component "app1" should have camera access, "app2" should + have microphone access, and "app3" should have both might look like this: +
+ <iframe + allow="camera https://app1.site.com https://app3.site.com; + microphone https://app2.site.com https://app3.site.com" + src="https://doc1.site.com" + sandbox="allow-same-origin allow-scripts"> + </iframe> ++
Iframe attributes can selectively enable features in certain frames, and + not in others, even if those contain documents from the [=same origin=]. + The list of sandbox tokens might be longer in practice.
+Since browsers generally ask users to grant permissions to the top-level + domain, there might not be any additional permission prompt for the + components to request camera or microphone access if the user already + trusts PlatformCorp.
+