1871765 - SharedArrayBuffer unavailable in "data:" and "file:///" origin.

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, enhancement)

Description

[Mozira]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

I try to write AudioWorkletProcessor working in "file://" origin. I tried to write application in local file and I cannot enable the SharedArrayBuffer which is needed for high performance AudioWorkletProcessor.

$micStream=await navigator.mediaDevices.getUserMedia({audio:true}); 
$micAudioCtx=new AudioContext();
$audioCtx=new AudioContext();
$micMS=$micAudioCtx.createMediaStreamSource($micStream);
$gainNode=$audioCtx.createGain();
$gainNode.connect($audioCtx.destination);
$micSampleRate=$micMS.context.sampleRate;
var $data=`
class RecorderProcessor extends AudioWorkletProcessor
{
   mem=null;
   constructor()
   {
      super();
      this.mem=new WebAssembly.Memory({initial: 4, maximum: 4, shared: true});
      this.port.postMessage(this.mem); // this line emits error!!!
   }

   process($i)
   {
       //...
   }
}
registerProcessor('VAProcessor', RecorderProcessor);`;
$data='data:text/javascript;base64,'+btoa($data);
await $micAudioCtx.audioWorklet.addModule($data);
$micRec=new AudioWorkletNode($micAudioCtx, 'VAProcessor');
$micRec.port.onmessage=handleSAB;

Actual results:

Firefox emits error that there is no COEP and COOP headers, but there is no possibility to set these headers.

Expected results:

Firefox should permit "file:///" and "data:" origin (if created from the same JS code) and main «website» is loaded from file. The file:/// origin can be treated as trusted started by user manually.

In file:/// origin there is no way to set COOP and COEP. There must be other mechanism to make SharedArrayBuffer available for "file:///" applications.

The SharedArrayBuffer is must-have for AudioWorkletProcessors. There is no other stable solutions (postMessage causes reallocations and then errors during handling samples from microphone).

Problems related to spectree should probably not prevent a user from running programs s/he has written.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Web Audio' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Karl Tomlinson (:karlt)]

https://localhost/ may be an option for developers here.

Comment 4

[Mozira]

(In reply to Karl Tomlinson (:karlt) from comment #3)

https://localhost/ may be an option for developers here.

No. Requesting the user to install additional software is not an option here. That's why I'm writing an application that a user can download and use in a browser, so that it works without https://localhost/ (without permissions to run and install).

If this cannot work in Firefox, I must disable Firefox support. If it does not work in another browser (e.g. Chrome), I should rewrite the entire application and give up the browser and rewrite the application for Linux (e.g. using WebView or another library instead of faulty and not well thought through browser).

The Browser should not require additional server to unblock internal browser functions! Do I need to request you for your spoon if I need to eat my soup? Why I cannot use my spoon? Why I have not privilege to get a spoon and must ask you/server?

Comment 5

[Sean Feng [:sefeng211]]

I think there's a security issue here like multiple different file:/// window can be in the same process, so we don't want to enable SharedArrayBuffer there. Maybe we can if there's way to make certain file:/// have dedicated processes?

Olli, do you think we can do something here?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

nika might have some opinions on this.

Comment 7

[Nika Layzell [:nika] (ni? for response)]

We do not consider file:// URIs to be cross-origin isolated, and I believe Chrome does the same.

Some web features are not very feasible to securely support with file URIs. We cannot impose the "cross-origin isolated" restrictions which the COOP and COEP headers require on file URIs without backwards compatibility risks, and we do not want to allow SharedArrayBuffer access without those restrictions for security reasons. Because of this, it's not possible to use the SharedArrayBuffer APIs from File URIs.

It is not abnormal for documents loaded from file URIs to be limited due to security concerns. For example, we consider every file to have a distinct origin, because treating different file URIs like they have the same origin has been the source of security issues in the past (e.g. https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730).

Comment 8

[Mozira]

@Nika, I think there is no issue due to CVE-2019-11730 between file:/// URI and blob/data AudioWorkletProcessor created from it (like in example). If the SAB cannot be reenabled here, there is needed new interface RingBufferAudioProcessor which will replace deprecated ScriptProcessor to work without message sending/posting (AudioWorkletProcessor must work without memory reallocations). There is no stable methods to receive microphone samples in file:/// context without glitches.

ScriptProcessor is unstable due to internal memory reallocations.

This is how it should work?

Comment 9

[Nika Layzell [:nika] (ni? for response)]

(In reply to Mozira from comment #8)

@Nika, I think there is no issue due to CVE-2019-11730 between file:/// URI and blob/data AudioWorkletProcessor created from it (like in example).

I was not impliying that that CVE was specifically related to this issue - as I explained in comment 7, we can't enable SAB because we can't impose cross-origin isolated on file URIs. I was using it as an example of another time we've had to limit file URI access to web features due to security concerns.

Comment 10

[Mozira]

Is there any security issue to allow sharing SAB between file:/// URI and AudioWorkletProcessor with this construction (without setting crossorigin isolated)?

var $SAB=new WebAssembly.Memory({initial: 4, maximum: 4, shared: true});
new AudioWorkletNode($micAudioCtx, 'VAProcessor', {processorOptions:{buffer: $SAB}});

If yes, which security issue occured?

For the moment this option is vulgarly deleted... (but the object is created). I think it also doesn't work correctly.

Comment 11

[Nika Layzell [:nika] (ni? for response)]

I explained the issue in comment 7, quoting here:

Some web features are not very feasible to securely support with file URIs. We cannot impose the "cross-origin isolated" restrictions which the COOP and COEP headers require on file URIs without backwards compatibility risks, and we do not want to allow SharedArrayBuffer access without those restrictions for security reasons. Because of this, it's not possible to use the SharedArrayBuffer APIs from File URIs.

TL;DR: Sending SharedArrayBuffer requires "cross-origin isolated", restrictions. These are opted into using COOP and COEP headers. file:/// URIs cannot specify these headers, so cannot opt into "cross-origin isolated" restrictions. Therefore, they cannot send SharedArrayBuffer.