Firefox 84 - PromiseError/SecurityError: The operation is insecure

brainfoolong · January 18, 2021, 5:43am

Hi. We do JS error logging in our system and recently there are some new error messages that come from the matomo.js tracker.

We get, very few but noticable, error logs:
PromiseError/SecurityError: The operation is insecure.

Stacktrace show following line: matomo.js:66:276 - We have 4.1.0 installed.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Unfortunetely i cannot reproduce this error.

Everything is running in https context, we have no insecure source on the pages where this errors happens. Also the domain where it is running is in trusted domains.

This error have been currently logged 3 times - Out of round about 1000 requests with this specific user agent in the last few weeks.

Lukas · January 18, 2021, 8:59am

Hi,

Could you maybe send me a private message with the URL to your site?

I have never seen this error before and the internet claims it happens when you try to set up a non-ssl websocket or a file:/// URL on a HTTPS site.
But Matomo doesn’t use websockets anywhere.

Is this something you can reproduce or just randomly get sent in an error log from users websites (using something like sentry.io)? In the latter case it could be a browser extension modifying the website and breaking something.

brainfoolong · January 19, 2021, 6:05am

Hi, thanks for your answer. Unfortunetely i cannot send you a URL to this site, as it’s an internal site with no public access.

Sure, it’s always possible that the user have installed an extension that do something weird. But in this case, i don’t think to. Firefox in general have some troubles in the last few versions, they introduce errors that are hard to debug.

I guess, it’s something related to this error here, as you also have noticed: https://github.com/facebook/create-react-app/issues/8047 - As the error happens exactly at the same spot in the matomo tracker.

Here after the opening { bracket : ...(g.serviceWorker.ready)){g.serviceWorker.ready.then...

We have a websocket connection on this sites, but it’s wss already.

As i’ve said, only 0,3% of this requests have logged this error. Maybe it’s some AntiVirus issue that intercept requests.

I would say, we can call this resolved, as i also don’t think that this is a matomo related issue.
It’s just weird that the stacktrace points to matomo.

Thanks for your time.

Lukas · January 19, 2021, 10:44am

Hi,

This is the corresponding code in matomo.js

github.com

matomo-org/matomo/blob/4.x-dev/js/piwik.js#L6969-L6977


// initialize the Matomo singleton
addEventListener(windowAlias, 'beforeunload', beforeUnloadHandler, false);
addEventListener(windowAlias, 'online', function () {
    if (isDefined(navigatorAlias.serviceWorker) && isDefined(navigatorAlias.serviceWorker.ready)) {
        navigatorAlias.serviceWorker.ready.then(function(swRegistration) {
            return swRegistration.sync.register('matomoSync');
        });
    }
}, false);

It tries to communicate with the service worker if one is set up (it is not by default).

Maybe there is some rare Browser setup where this fails (but thinking about this, this code should only work if any serviceworker is set up). Maybe they have a serviceworker set up due to some browser extension and then the code tries to communicate to it, but fails as it is not on the same domain as Matomo and maybe some security feature blocks this.

Maybe @thomas_matomo knows more.

thomas_matomo · January 20, 2021, 8:28pm

Looking at https://stackoverflow.com/questions/49539306/firefox-service-worker-securityerror-domexception-the-operation-is-insecure maybe it is related to cookies?

brainfoolong · January 22, 2021, 5:50am

Thanks for your checks.

Ok, i’ve debugged further. It’s indeed the code that you have stated.
When i just open F12 → Console in FF 84.0 and hit navigator.serviceWorker.ready than this error appears.

It doesnt matter on which site you do this, also in this forums the error happens. A running service worker is not required for this error.
I’ve enabled the cookie setting “Clean cookies and site data when exiting Firefox”, as stated here. https://stackoverflow.com/a/63831245/1887622

At the moment where you disable this flag, the error disappears.

This behaviour is Firefox only and also is not what the docs from firefox says. serviceWorker.ready should never reject, but does as we can see → https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/ready → It returns a Promise that will never reject

Lukas · January 22, 2021, 11:43am

Hi,

Indeed I confirm this in a fresh firefox profile with this setting enabled on the forum:

What is weird, is that the Matomo tracking code doesn’t try to register a serviceworker, but just communicate with one if the user had set one up. I guess even that is restricted
in this case.

I think the right solution would be to catch the promise and document it for the people who want to use the service worker for offline tracking.

Lukas · January 22, 2021, 11:49am

I created an issue for this:

https://github.com/matomo-org/matomo/issues/17136

Lukas · January 25, 2021, 9:03am

Hi @brainfoolong,

This PR will fix the issue:

https://github.com/matomo-org/matomo/pull/17139