1565672 - A local opened web-worker seems not to work anymore with Firefox 68.0

Status: RESOLVED INVALID

(Core :: DOM: Security, defect, P3)

Description

[Peter Rosenberg]

Attachment: simple-web-worker-gh-pages.zip

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

Steps to reproduce:

I LOCALLY tried to run the web-worker example from https://github.com/mdn/simple-web-worker. It does work with Firefox 60.8.0esr. But it does not work anymore with Firefox 68.0. If I run the example ONLINE (http://mdn.github.io/simple-web-worker/) it does work with Firefox 68.0.

Actual results:

It seems that JavaScript can open the web-worker and sends messages to it. But the web-worker does not answer and I can not see any errors.

Expected results:

In the example, the web-worker should multiply two numbers and should send back the result.

Comment 1

[Florencia Di Ciocco, NI to vbalducci]

Hi Bozle,

Could you be a little more specific on how to run the web-worker example locally, please? Because I've downloaded the files from https://github.com/mdn/simple-web-worker, saved them in a folder, opened index.html on firefox release v67, I enter two numbers to be multiplied and it does not work. Taking into account what you said, that version should've worked. Maybe I'm missing a step. If you have a video, that's always welcomed.

Thanks in advance, Flor.

Comment 2

[Peter Rosenberg]

Hi Florencia. I will give you more information soon. But please give me some days :-). Kind regards, Peter (real name :-) )

Comment 3

[Florencia Di Ciocco, NI to vbalducci]

ok, no hurry :)

Comment 4

[Daniel Veditz [:dveditz]]

Although this is a "regression" in Firefox, this aligns our behavior with other browsers. Most developers of sites complex enough to need workers can easily set up a simple python or node localhost web server to run their tests.

Comment 5

[Daniel Veditz [:dveditz]]

On the other hand see bug 1570629 comment 4 -- we may fix both of these

Comment 6

[Peter Rosenberg]

Attachment: Visualisation of the problem

Here a video to visualize the problem. I hope it helps.

Comment 7

[Peter Rosenberg]

(In reply to Daniel Veditz [:dveditz] from comment #4)

Although this is a "regression" in Firefox, this aligns our behavior with other browsers. Most developers of sites complex enough to need workers can easily set up a simple python or node localhost web server to run their tests.

Hi Daniel V. Did I understood it right? Because in the past it was possible for malicious code to read out local stored files (1), firefox has tightened up the same-origin policy (2). And other browsers already behave the same way or will behave the same way in the future (3).
Ist my interpretation correct?
(1) https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730
(2) https://www.fxsitecompat.dev/en-CA/docs/2019/local-files-are-now-each-given-a-different-origin/
(3) But it still works in the Microsoft Edge 44.17763.1.0
Best regards, Peter

Comment 8

[Mark Straver]

(In reply to bozle from comment #7)

Did I understood it right?

Yup, you understood it correctly.

Comment 9

[Peter Rosenberg]

(In reply to Mark Straver from comment #8)
Hi Mark. Thank you for your answer. Then I will close this incident as 'invalid' because it is not a bug.

Comment 10

[Peter Rosenberg]

Hello together

Please excuse me for coming back to this point. But when I read the following article, I again came to the conclusion that it should work.

https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

Or am I wrong. I guess I do :-) but I do not understand it anymore.

Kind regards Peter

Comment 11

[Peter Rosenberg]

By the way, it works if I deactivate the setting mentioned in the article (https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs > about:config > security.fileuri.strict_origin_policy). That would be a Plan B but I still have got the hope, that it should be possible.

Comment 12

[Boris Zbarsky [:bzbarsky]]

https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

That document is very out of date and is not maintained; hence the red border and "Archive" in the URL. The current designed behavior is that workers loaded from file:// should not work, basically, unless you load the worker from the exact same file as the HTML involved.

Setting security.fileuri.strict_origin_policy to false is a really bad idea. It leads to a behavior that is extremely insecure.

If you want to go back to the (slightly, not extremely) insecure behavior in Firefox 67, you probably want to look at the privacy.file_unique_origin pref.

Comment 13

[Peter Rosenberg]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)
Thank you for your answer. I was so focused finding a solution for my problem that i didn't see that the document is out of date :-). Security - of course - is important to me and therefore I follow your advice and won't change this setting it to false (security.fileuri.strict_origin_policy). I have found a solution on the internet (https://coderwall.com/p/5te2lg/web-workers-for-beginners-and-without-external-files). I will close this incident again.

Comment 14

[Peter Rosenberg]

Just for the case that someone is struggling with the same situation. Here, a short example how to create a worker without loading a file:

'use strict';
var mod = function(){
	const
		workerData = new Blob(
			['var i = 0; setInterval(function(){i++; postMessage(i);},500);'], {type: "text/javascript"}
		)
	;

	var
		init = function(){
			var
				myWorker = new Worker(
					window.URL.createObjectURL(workerData)
				);
			;

			myWorker.onmessage = function(e){
				console.log(e.data);
			}
		}
	;

	return{
		init : init
	};
}();