starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Handling issues when enabled Firefox's fingerprinting resistance #2457

New issue

Closed

opened 2026-02-28 02:55:32 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 02:55:32 -05:00

Owner

Originally created by @obfusk on GitHub (Aug 9, 2023).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

The favicon is broken in Firefox when not allowing access to canvas image data.

👟 Reproduction steps

Enable fingerprinting resistance (privacy.resistFingerprinting) in Firefox.

👀 Expected behavior

A favicon to be shown.

😓 Actual Behavior

No favicon, not even one without a badge.

🐻 Uptime-Kuma Version

1.22.1

💻 Operating System and Arch

Debian GNU/Linux 11

🌐 Browser

Firefox

🐋 Docker Version

No response

🟩 NodeJS Version

No response

📝 Relevant log output

No response

Originally created by @obfusk on GitHub (Aug 9, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description The favicon is broken in Firefox when not allowing access to canvas image data. ### 👟 Reproduction steps Enable fingerprinting resistance (`privacy.resistFingerprinting`) in Firefox. ### 👀 Expected behavior A favicon to be shown. ### 😓 Actual Behavior No favicon, not even one without a badge. ### 🐻 Uptime-Kuma Version 1.22.1 ### 💻 Operating System and Arch Debian GNU/Linux 11 ### 🌐 Browser Firefox ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output _No response_

deekerman

2026-02-28 02:55:32 -05:00

closed this issue
added the
feature-request

A:dashboard

A:status-page

A:core
labels

deekerman commented

2026-02-28 02:55:37 -05:00

Author

Owner

@Computroniks commented on GitHub (Aug 9, 2023):

The issue appears to be caused by an external package we use to generate the badges for the favicons called Favico. It appears to be this line that causes the issue:

github.com/ejci/favico.js@6a3f430be5/favico.js (L537)

 var url = canvas.toDataURL('image/png');

It looks like this reads the data in the canvas (which is prevented by firefox) and writes it back to the favicon (it writes blank because firefox blocked the read). This behaviour looks similar to a bug I saw for firefox when looking into this which said a similar thing except with the QR code for web.whatsapp.com (https://bugzilla.mozilla.org/show_bug.cgi?id=1446472)

@Computroniks commented on GitHub (Aug 9, 2023): The issue appears to be caused by an external package we use to generate the badges for the favicons called Favico. It appears to be this line that causes the issue: https://github.com/ejci/favico.js/blob/6a3f430be559f93d96573e2a4a0116e154c11319/favico.js#L537 ``` var url = canvas.toDataURL('image/png'); ``` It looks like this reads the data in the canvas (which is prevented by firefox) and writes it back to the favicon (it writes blank because firefox blocked the read). This behaviour looks similar to a bug I saw for firefox when looking into this which said a similar thing except with the QR code for web.whatsapp.com (https://bugzilla.mozilla.org/show_bug.cgi?id=1446472)

deekerman commented

2026-02-28 02:55:37 -05:00

Author

Owner

@Computroniks commented on GitHub (Aug 9, 2023):

Given that the last update to that package was in 2016, I don't think we will get too far with getting this issue fixed there. We might be able to roll our own version of it with the fix though. I will have a bit of a play around with it and see if I can get anything working at all.

@Computroniks commented on GitHub (Aug 9, 2023): Given that the last update to that package was in 2016, I don't think we will get too far with getting this issue fixed there. We might be able to roll our own version of it with the fix though. I will have a bit of a play around with it and see if I can get anything working at all.

deekerman commented

2026-02-28 02:55:37 -05:00

Author

Owner

@louislam commented on GitHub (Aug 10, 2023):

According to https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting

It is likely that it may degrade your Web experience

I think it is the case. You have to accept that something may be broken in this mode. And it is not a web standard, nothing we can do here.

Since Uptime Kuma is a selfhosted and open source. You can always check the source code to see if Uptime Kuma really track you down via canvas. If possible, it should be safe to add your Uptime Kuma to the whitelist.

@louislam commented on GitHub (Aug 10, 2023): According to https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting > It is likely that it may degrade your Web experience I think it is the case. You have to accept that something may be broken in this mode. And it is not a web standard, nothing we can do here. Since Uptime Kuma is a selfhosted and open source. You can always check the source code to see if Uptime Kuma really track you down via canvas. If possible, it should be safe to add your Uptime Kuma to the whitelist.

deekerman commented

2026-02-28 02:55:37 -05:00

Author

Owner

@obfusk commented on GitHub (Aug 10, 2023):

nothing we can do here.

I think it should be possible to handle this in Uptime Kuma. But it may not be easy to, especially if it involves modifying a dependency that doesn't seem to be getting updates. And I certainly understand if this is not considered a priority, especially since it does indeed violate web standards.

If possible, it should be safe to add your Uptime Kuma to the whitelist.

I mostly reported this here to document why it's broken since that may not be obvious to users, and to see if there might be a way to handle this better in Uptime Kuma. Of course, whitelisting should indeed be a safe and effective solution.

@obfusk commented on GitHub (Aug 10, 2023): > nothing we can do here. I think it should be possible to handle this in Uptime Kuma. But it may not be easy to, especially if it involves modifying a dependency that doesn't seem to be getting updates. And I certainly understand if this is not considered a priority, especially since it does indeed violate web standards. > If possible, it should be safe to add your Uptime Kuma to the whitelist. I mostly reported this here to document why it's broken since that may not be obvious to users, and to see if there might be a way to handle this better in Uptime Kuma. Of course, whitelisting should indeed be a safe and effective solution.

deekerman commented

2026-02-28 02:55:37 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Apr 14, 2024):

I think it should be possible to handle this in Uptime Kuma

How do you think this can be done?
The issue is that reading the canvas element is blocked. I don't see a way to get around that.
We have a dynamic favicon and I don't think this should change..

I think solving this issue is fundamentally impossible while retaining the dynamic favicon
=> closing as wontfix. We can reopen if somebody comes up with a way to retain this functionality even in this submode of firefox.

In the meantime firefox has implemented a different method:

changes the behavior when detecting a canvas extraction without
user interaction. It will show a canvas identity block icon with a
hidden doorhanger when auto-blocking the canvas extraction. Users can
make their choice to either block or allow the canvas extraction by
clicking the identity block icon and then refresh the page to make
the canvas permission taking effect.

@CommanderStorm commented on GitHub (Apr 14, 2024): > I think it should be possible to handle this in Uptime Kuma How do you think this can be done? The issue is that reading the canvas element is blocked. I don't see a way to get around that. We have a dynamic favicon and I don't think this should change.. I think solving this issue is fundamentally impossible while retaining the dynamic favicon => closing as wontfix. We can reopen if somebody comes up with a way to retain this functionality even in this submode of firefox. In the meantime firefox has implemented a different method: > changes the behavior when detecting a canvas extraction without user interaction. It will show a canvas identity block icon with a hidden doorhanger when auto-blocking the canvas extraction. Users can make their choice to either block or allow the canvas extraction by clicking the identity block icon and then refresh the page to make the canvas permission taking effect.