Integrate with Permissions Policy

[tomayac]

There is evidence that a Permissions Policy directive for the File System Access API is needed. This is how it could look like:

<!-- Embedding document -->
<iframe src="https://third-party.example.com/file-editor.html" allow="file-system"></iframe>

[tomayac]

There exists an embeddable version of Excalidraw (a project that uses the browser-fs-access library) and we need to rely on ugly checks to make this work, since feature detection doesn’t help with the cross-origin iframe case.

[tomayac]

The good folks from Photopea have again asked for an update on this.

[CetinSert]

We also want this to work in cross-origin <iframe>s

• mainly for our playground try.WebPDF.pro
• but for some customers also for our components.

See https://blog.pdf.ist/webpdf-pro-what-is-new-2021-11/#try.

Home	Playground	Blog
WebPDF.pro	try.WebPDF.pro	blog.PDF.ist

---

With ❤️ from South Korea

[mkruisselbrink]

#281 also brought up the desire to expose for example a handle as read-only to a subframe even if the main page has write access. Not sure how we'd achieve that with permissions policy integration.

[tomayac]

https://github.com/WICG/file-system-access/issues/281 also brought up the desire to expose for example a handle as read-only to a subframe even if the main page has write access. Not sure how we'd achieve that with permissions policy integration.

It looks like Capability Delegation could be a potential solution, however delegate right now is a DOMString, but maybe it could be extended to make something like the below example possible:

const [handle] = await showOpenFilePicker();
const iframe = document.querySelector('iframe');

window.onclick = () => {
    iframe.postMessage('message', {delegate: handle});
};

Alternatively, it could be modeled as follows, if FileSystemHandles can be transferred via postMessage() :

const [handle] = await showOpenFilePicker();
const iframe = document.querySelector('iframe');

window.onclick = () => {
    iframe.postMessage({ data: 'message', handle, }, {delegate: 'file-system'});
};

[jimmywarting]

Alternatively, it could be modeled as follows, if FileSystemHandles can be transferred via postMessage() :

I have wanted that: https://github.com/WICG/file-system-access/issues/281 (even suggested that the access mode could be changed)

[tomayac]

There's still active user demand from Photopea for this. What is the status of the security discussion regarding this feature request?

[photopea]

I am so glad that back in 90s they created truly unrestricted tags, such as <img> or <a>. If these tags were created today, they would probably also be limited to the same domain, controlled by the cross-origin-resource-sharing headers and who knows what.

@tomayac could you just make it work in Chrome the right way, instead of waiting years for the standard to change?

[appsforartists]

I bumped into this today:

Cross origin sub frames aren't allowed to show a file picker.

My use case is trying to save a file from Colab, which sandboxes web content to prevent malicious, surreptitious access to the user's account, but is very generous in the permissions it allows the <iframe>:

<iframe 
  allow = "accelerometer; autoplay; camera; gyroscope; magnetometer; microphone; serial; usb; 
    xr-spatial-tracking; clipboard-write" 
  sandbox = "allow-downloads allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts 
    allow-storage-access-by-user-activation allow-modals allow-popups-to-escape-sandbox" 
  …>

I expect that I'll be able to work around with our old friend <a download href = "…">, but I also expect the browser to provide the ability for authors (in this case, the @googlecolab team) to make informed choices about allowing/disallowing access to browser APIs in content they host.

[appsforartists]

Here's a request/discussion for the same use case by @mbostock and @hellonearthis:

https://talk.observablehq.com/t/accessing-the-native-file-system/3861/

[appsforartists]

Why doesn't this respect sandbox = "allow-downloads"? Are the security ramifications different enough that we need yet-another flag?

[tomayac]

On the Chromium side, this is tracked as https://issues.chromium.org/issues/40245709.

[jozefchutka]

+1 for <iframe allow="file-system"> will be also very valuable for https://github.com/HeyPuter/puter