From b4af6ac6a80b4112c13e95147a0a86298a90e960 Mon Sep 17 00:00:00 2001 From: Jan-Ivar Bruaroey Date: Wed, 26 Jun 2024 17:45:44 -0400 Subject: [PATCH] Add two "JS playground" examples. (#548) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Marcos Cáceres --- index.bs | 48 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 665183e..4ac9707 100644 --- a/index.bs +++ b/index.bs @@ -23,6 +23,7 @@ spec:html; type:element; text:link spec:fetch; type:dfn; text:name spec:fetch; type:dfn; text:value spec:infra; type:dfn; text:list +spec:permissions; type:dfn; text:feature
 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.

+