Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DevicesDetection] macOS 11 falsely detected as macOS 10.15 #18410

Closed
MichaIng opened this issue Nov 30, 2021 · 7 comments
Closed

[DevicesDetection] macOS 11 falsely detected as macOS 10.15 #18410

MichaIng opened this issue Nov 30, 2021 · 7 comments
Labels
answered For when a question was asked and we referred to forum or answered it.

Comments

@MichaIng
Copy link
Contributor

Expected Behavior

Since it is released for a while and AFAIK macOS users are not as afraid of updates as Windows users (?), I'd expect macOS 11 to be among the most used versions of this family.

Current Behavior

OPERATING SYSTEM VERSION VISITS
Mac 10.15 14.4% 11,254
Mac 10.13 0.6% 471
Mac 10.14 0.6% 452
Mac 10.11 0.1% 86
Mac 10.12 0.1% 41
Mac 11.0 0% 17
Mac 10.8 0% 14
Mac 10.10 0% 13

Hmm, 17 overall macOS 11 visits among ~80,000, while macOS 10.15 was (still) used by >11,000 visits? I think the macOS version is not detected correctly. Sadly I wasn't able to find where it is actually derived. I see $parser->getOs('version'); being used, but not where this function is defined, which must be somewhere in the DeviceDetector.

Possible Solution

Steps to Reproduce (for Bugs)

Context

Your Environment

  • Matomo Version: 4.6.0
  • PHP Version: 8.1.0
  • Server Operating System: Debian Bookworm
  • Additionally installed plugins:
API, Actions, Annotations, BulkTracking, CoreAdminHome, CoreConsole, CoreHome, CorePluginsAdmin, CoreUpdater, CoreVisualizations, CoreVue, DBStats, DarkTheme 1.1.7, Dashboard, DevicePlugins, DevicesDetection, Diagnostics, Goals, ImageGraph, Insights, Installation, Intl, LanguagesManager, Live, LogViewer 4.0.1, Login, Marketplace, Monolog, Morpheus, PagePerformance, PrivacyManager, Proxy, Referrers, Resolution, SEO, SegmentEditor, SitesManager, TrackingSpamPrevention 4.1.0, Transitions, UserLanguage, UsersManager, VisitFrequency, VisitTime, VisitorInterest, VisitsSummary, WebsiteMeasurable
  • Browser:
  • Operating System:
@MichaIng MichaIng added the Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. label Nov 30, 2021
@Findus23
Copy link
Member

Do you by chance have the useragent these visitors sent to Matomo?
If so, you can test at https://devicedetector.lw1.at how Matomo (or more precisely DeviceDetector) would detect it.

But I think in this it is an intentional feature by Apple: They are sending the same old user agent for every single browser version to limit the possibility of fingerprinting there.
You can read about it here for example:

Froze the user-agent string to reduce web compatibility risk and to prevent its use for fingerprinting
https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/

@MichaIng
Copy link
Contributor Author

MichaIng commented Nov 30, 2021

We have no access logging enabled and as far as I can see the user agent itself is not stored by Matomo (?). But your link is a pretty good explanation. Just wondering how the 17 macOS 11.0 visits were detected then 😄.

Their first reason is a pretty funny one, as the user agent can be exactly used by websites to check or assure compatibility with a client while using as modern web features as possible. Hence freezing it implies a risk of either being presented with an incompatible website (e.g. the website knows about the freeze and then treats all those agents as newest macOS) or with a less appealing compatible one if the website decides to treat all those agents as lowest possible macOS version. In case of Safari this is e.g. relevant for knowing whether webp images can be provided or not, as this is only supported on Safari >=14 from Big Sur on. There are more reliable ways, I know, but freezing a user agent definitely has a higher change of breaking compatibility than preventing it, when the websites makes use of it at all.

And with the ratio of macOS systems vs versions out there, for privacy the user agent is of minor interest, while blocking ads and commercial tracking providers is what one should invest in.

However, the question is how to deal with this in Matomo: If there is no other way to derive the macOS version, showing 10.5 - 12, 10.5 or newer, >=10.5 or something instead? (I recognised just now that macOS 12 was released last month)

@sgiehl
Copy link
Member

sgiehl commented Dec 1, 2021

Some useragents still include information that makes it possible to determine the correct version. You can see the regexes for that here:
https://github.com/matomo-org/device-detector/blob/master/regexes/oss.yml#L692-L714
Even though Safari might have frozen the user agent string, that doesn't apply for all other apps or browsers on apple devices.

@MichaIng
Copy link
Contributor Author

MichaIng commented Dec 1, 2021

I see, not sure how to resolve it best as we cannot know whether it is the correct version or the frozen (false) version then. But currently Matomo gives false/misleading information for the majority of macOS systems, so something needs to be changed.

@peterhashair
Copy link
Contributor

peterhashair commented Dec 21, 2021

@MichaIng I guess mac has some privacy protection. Like my system is on 12.1, but my user agent is displayed as 10.15.7

image
image

@MichaIng
Copy link
Contributor Author

Jep, as linked by Findus23 above. Still not sure how this protects your privacy as it still does not contain private information. If Apple would allow anonymous usage of their OSes and App stores, that would be something, but freezing the user agent? 🤔

@sgiehl
Copy link
Member

sgiehl commented Feb 22, 2022

Closing this one. It should get solved with #16125

@sgiehl sgiehl closed this as completed Feb 22, 2022
@sgiehl sgiehl added answered For when a question was asked and we referred to forum or answered it. and removed Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. labels Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
answered For when a question was asked and we referred to forum or answered it.
Projects
None yet
Development

No branches or pull requests

4 participants