JS Tracking code may generate "The operation is insecure" warnings with specific Firefox settings

[brainfoolong]

This bug is just a follow up to a already known bug, but i decided to start a new issue here as the others are marked as resolved or have been merged.

References:

• https://forum.matomo.org/t/firefox-84-promiseerror-securityerror-the-operation-is-insecure/40299/8
• https://github.com/matomo-org/matomo/pull/17139
• https://github.com/matomo-org/matomo/issues/17136

Ok, i can now reproduce this bug with 4.2.1 in Firefox 87.0 on windows. It is still present and still causes errors in our JS error logs. It depends on some specific firefox strict security settings.

Following example:

• Open any site you want with Firefox
• Open F12 console
• Enter and execute this: console.log(navigator.serviceWorker && navigator.serviceWorker.ready)
• Error occurs

The console command is basically the same as used in matomo here https://github.com/matomo-org/matomo/blob/4.x-dev/js/piwik.js#L6989

Demo:

Settings:

[diosmosis]

Hi @brainfoolong, I have a couple questions:

• Does just console.log(navigator.serviceWorker) emit the error?
• Does navigator.serviceWorker.ready.catch(function () {}) also cause the error?

Also, I'm not completely up to speed on the discussion around this issue, so forgive me if this is obvious, but what's the impact of this bug? Does nothing track because of it or is it just an error in the console?

[brainfoolong]

Hi, just the try to use navigator.serviceWorker.ready will cause the exception. It causes error in the javascript console. And also causes errors to be logged when you have a system that log javascript exceptions. So does in our case. It clutters our logs.

This code from matomo does not run on firefox in this case because of this exception, but i don't know what it exactly does. https://github.com/matomo-org/matomo/blob/4.x-dev/js/piwik.js#L6988-L6996

IMHO, i don't see why matomo try to hook into existing service workers. I read it is for offline tracking but cannot find any relevant code for this, as "matomoSync" does only exist once in the matomo code.

[diosmosis]

Hi @brainfoolong, can you check if 'ready' in navigator.serviceWorker has the same problem?

[brainfoolong]

@diosmosis No it does not, but it does not help in this case, at it returns true anyway.

[diosmosis]

That's unfortunate. Thanks for checking.

[brainfoolong]

And another note: You can catch this error, but cannot make the error go away. I've tried 3 different methods:

window.addEventListener('unhandledrejection', function (e) {
  console.log(e)
}, false)

window.addEventListener('error', function (e) {
  console.log(e)
}, false)

try{
    navigator.serviceWorker.ready
}catch(e){
}

[diosmosis]

Looks like there's a bug in the firefox tracker for this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1413615 https://stackoverflow.com/questions/49539306/firefox-service-worker-securityerror-domexception-the-operation-is-insecure/

If it's possible to detect when that privacy feature is enabled we could avoid the error. Failing that it could be conditionally enabled/disabled in the tracker.

[brainfoolong]

Yes, maybe. But, this issues are years old and nobody cares about... Maybe it could be an option in matomo, to prevent offline tracking and so to prevent the use of service worker hooks?

But my question really is, what does this part of the code? I cant see any use of this, as the registered "matomoSync" does no seem to be used anywhere else.

Also, the use for sync is experimental and not ready for production - https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/sync - This page also list firefox as unsupported. Maybe this code is a bit too experimental for matomo?

I know, it is not really a matomo error, but matomo does generate those errors and i don't see that firefox will fix this anywhere soon.

[diosmosis]

That comment was just to provide information from my research.

Unfortunately, I don't know what this code is for as I wasn't involved in writing or reviewing it, but @tsteur might be able to answer why it's there.

[Findus23]

But my question really is, what does this part of the code?

The part it interacts with is the service worker in https://github.com/matomo-org/matomo/blob/4.x-dev/offline-service-worker.js

https://github.com/matomo-org/matomo/blob/086874bb001f22381916bee51de87ec41452782e/offline-service-worker.js#L117-L121

The documentation is just the description of https://github.com/matomo-org/matomo/pull/15970 and https://matomo.org/faq/how-to/how-do-i-set-up-matomo-offline-tracking/ for now.

[brainfoolong]

@Findus23 Thx for clearing this up. This is indeed good to know, as we firewalled our matomo instance and only pass matomo.js and matomo.php through, so this wouldn't even work for us.

Beside that, i think using a highly experimental feature, the sync in service worker, is not that good in a widely used production product, isn't it?

[felix-berlin]

We get similar errors. However, not only in Firefox but also in Safari (iOS and MacOS).

[tsteur]

I'll move this into the current 4.3 milestone so we can investigate further.

[justinvelluppillai]

Hi @brainfoolong and @felix-berlin, I have just started to look into resolving this issue and can't reproduce it in Firefox 89. Can you please let me know if you are still seeing the issue, and if so perhaps give me steps and environment to reproduce the issue?

Thanks - maybe some browser updates have fixed this.

[brainfoolong]

Hi @justinvelluppillai . The error still exist. Just run this on any website in F12 -> Console. That's basically the core problem of matomo and the most basic example to reproduce.

You need to enable the settings as stated in post https://github.com/matomo-org/matomo/issues/17454#issue-856875222

[justinvelluppillai]

This information has all been mentioned above, but just to clarify this issue:

The relevant setting is

When it is set, navigator.serviceWorker.ready returns a rejected promise, which we currently don't handle, so firefox shows "The operation is insecure" error.

I have submitted a PR to fix this by handling the rejected promise and silently ignoring it.

[brainfoolong]

@justinvelluppillai Thanks, i can confirm that this fix does work.

[justinvelluppillai]

Thanks @brainfoolong appreciate you drawing our attention to this and your patience in providing details to get it fixed.

[felix-berlin]

In my case navigator.serviceWorker.ready is undefined.

[felix-berlin]

Is there a other way to force the error?

[Findus23]

@felix-berlin Do you by chance use any browser extension that modifies theses browser settings?

For me, if I set dom.serviceWorkers.enabled in about:config to false, navigator.serviceWorker becomes undefined.

[felix-berlin]

@Findus23 Yes but only two :)

[RacketyWater7]

Hi guys! Any update on resolving this issue? I'm getting this same error when directing the user from a normal webpage into my extension's options page. The process is that, when the user is directed to the options page, there its sent with an image src as in the url of options page, the image src is then extracted from url and sent to an API after some processing; this processing includes drawing it on a canvas and this is where this error occurs. Let me show the relevant code:

// previous code
if (selectImage) {
      setSending(true);
      // Convert the selected image to ImageData
      const imageBitmap = await createImageBitmap(selectImage);
      const canvas = document.createElement('canvas');
      canvas.width = imageBitmap.width;
      canvas.height = imageBitmap.height;
      const context = canvas.getContext('2d');
      context.drawImage(imageBitmap, 0, 0);
      //  >>>>>>>>>>>>>> the execution stops here  <<<<<<<<<<<<
      const imageData = context.getImageData(0, 0, canvas.width, canvas.height);
      // Decode the QR code
      const qrCode = jsQR(imageData.data, imageData.width, imageData.height);

      if (qrCode) {
      // code continued to send the image to server

[sgiehl]

This issue has been resolved in Matomo years ago. Your code also doesn't look related to Matomo at all, so maybe this isn't the correct place for reporting it.