privacy.resistFingerprinting = true causes extension popup to think it's mobile

Add-ons Development
#1

We have an extension that we have ported to Firefox, that works in Chrome, but also web and mobile web. So in the CSS there are media queries based on the screen width. A user contacted us with a very weird issue, and after a lot of debugging I was able to see that there was an option called “privacy.resistFingerprinting” that this user had set to “on”.

When debugging the CSS in the extension popup window was that it was hitting media queries that it normally shouldn’t. It turns out that turning this setting to “off” fixed the problem! The CSS was fine and no media queries were hit.

Before:

with resistFingerprinting on
Screenshot 2018-01-04 18.25.04.png696×660 36.4 KB

After

with it off
Screenshot 2018-01-04 18.25.33.png728×604 41.8 KB

It seems that with the feature on the screen.width is set to the size of the of extension popup window ~320. When it’s off it is set to the full screen width.

I’d call this a bug in Firefox. How would one go about getting a statement from a Mozilla dev?

#2

That sounds like it’s working as intended to me. I am, however very intrigued how you are scaling your UI by screen.width and not using CSS. And why your UI size is dependent on the actual screen resolution and not something like the pixel density (which resist fingerprinting also modifies, but just sets it to one, which should be fine, afaik).

#3

We’re not using screen.width, we’re using the relevant CSS media queries. @media screen and (max-width: 768px) { etc. Bootstrap uses these for breakpoints, so I assume it is very standard. Pixel density wouldn’t be helpful for setting responsive breakpoints either.

The problem is that the resistFingerprinting inherently changes the screen width so much that regular CSS assumptions break, and the device is assumed to be mobile, when it is in fact desktop. The case is pretty unique to extension popup windows I guess, since they logic of what “screen width” is changes completely. I’m assuming that when browsing the regular web with resistFingerprinting = on, all sites display the same, and not their mobile/responsive counterparts.

#4

Then I think the bug is actually the other way around, since max-width should always report the viewport width, which is actually the width of the panel.

#5

OK my bad, we’re actually using @media only screen and (min-device-width: 320px) and (max-device-width: 480px) { to detect mobile devices. This is what’s breaking the extension with resistFingerprinting.

(max-width) works as intended.

Also it works perfectly in Firefox without resistFingerprint, Chrome and Safari extensions.

#6

That seems like it’s working as expected. Resist fingerprinting is tasked with hiding identifying information from websites, and most users of that feature would probably agree that extensions also fall into the bucket of not entirely trusted code (judging by the amount of requests for extensions to be able to block requests of other extensions to disable GA etc.).

I’m assuming mobile devices = touch screen in this case, since pixel density is not what you’re concerned about. May I instead suggest a media query along the lines of

@media (-moz-touch-enabled: 1), (pointer: coarse) {

or maybe using the any-hover feature instead, if you want to only show things if users can’t hover over features. Sadly Firefox does not yet implement these media queries, so you’d have to fall back to -moz-touch-enabled which would probably also activate on Windows machines with touchscreens.

#7

Don’t you agree that it’s weird that this case causes conventional CSS to think it’s a mobile screen? Would it not make sense for it to at least still think it’s a desktop screen in terms of size?

The bug is that it completely changes the meaning of the CSS query, breaking existing code that works across many different platforms. It breaks expectations that are solidified even by Firefox without this setting.

#8

I do not agree with that. I don’t agree on the basis that a website should not be concerned about the actual resolution of a screen if it’s just displaying unrelated content. There are legitimate reasons why you’d want to know the real screen size, but since those are so sparse this is being masked by resistFingerprinting and is a drawback of using that option. Like you potentially break sites that use the useragent etc.

“Just because it works” is one of the biggest problems of the web IMO, that has created more issues than it solved.

#9

Why is knowing the screen resolution any different then? Knowing if the device has touch or not? How can us developers rely on anything if the value reported is basically random? Your suggested workarounds wouldn’t work with your logic either.

#10

In any case, if you think the opposite behaviour is a bug, how do I go about reporting it so we can get a consistent behaviour whether this setting is on or off?

I do agree that one should not blindly accept things because the masses have chosen something. But I do think that any developer can agree that at least the behaviour should be consistent, so we don’t have to resort to vendor specific hacks and vendor prefixes.

#11

Touch or being able to hover things relate to how the user interacts with your site, while the full screensize is only relevant in very few cases (like picking the best wallpaper resolution for you).

resistFingerprinting is a trade-off the user opts into that gives them more privacy in turn of a potentially reduced experience, like websites not rendering properly or assuming the wrong things about their system.

The difference with that workaround is, that your touchscreen specific styling would only be applied when the user is willing to share that device detail with you, instead of relying on the user sharing his screen size with you, which makes no sense in relation to touch screens.

That was concerning the idea that max-width etc. were reacting based on the full screen size instead of the viewport, which you later confirmed was not the case.

Yes, mostly. However a user specifically choosing not to report you the correct value is not something you should be trying to work around. Unless you don’t believe in their choice. So no need for hacks. My suggestion was merely to remove your hack for touchscreen detection.

I assume you’re also referring to -moz-touch-enabled here. Since you are an extension I do think a certain degree of browser-specifc code is ok, even more so than on the web (where we have luckily mostly moved to feature detection). Even if the extension APIs are mostly compatible you will still end up writing some browser-specific code.

You could also do it like other websites and ignore -moz-touch-enabled and just offer a more condensed view on Firefox for Android and Windows devices with touchscreens.

#12

The problem isn’t though that the screen size is completely hidden or unavailable, it’s just that it is reporting a value that is off the charts. If it were to report a screensize of 1200x800 always, instead of 320x400, that would be fine for me, because then responsive design would still work.

The bug is that we want to optimize our CSS for small screens when the screen is small, but this value is making it impossible. We don’t care about the nuances of the size, it is only “is the screen big or is it small”. We are using very standardized CSS. We are not detecting anything. We are trying to know how we should render the page based on standard CSS that is defined by W3 to mean certain things. The option mentioned simply breaks the rendering by making a standard value mean something else.

The bug is that the value defined by W3 is not what Firefox reports, or even close to the same thing.