Skip to content

64-bit detection doesn't work if the user agent string is missing "Win64" #1467

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

Closed
aaronfranke opened this issue May 25, 2020 · 10 comments · Fixed by #1468
Closed

64-bit detection doesn't work if the user agent string is missing "Win64" #1467

aaronfranke opened this issue May 25, 2020 · 10 comments · Fixed by #1468

Comments

@aaronfranke
Copy link
Contributor

aaronfranke commented May 25, 2020

Problem

https://git-scm.com/download/win

Currently, the download page tries to detect the bit-ness of the system and automatically provide the correct download option. However, not all browsers provide this information the same way.

I've found that when the user agent contains "Win64", the website correctly detects that it's a 64-bit system. However, when the user agent is missing this, the website provides 32-bit downloads, even if the user agent string also contains "x64" or "x86_64".

To fix this issue, the 64-bit detection should also look for the presence of "x64" and "x86_64".

Alternatively, the website could default to 64-bit, and detect 32-bit platforms.

@pedrorijo91
Copy link
Member

pedrorijo91 commented May 25, 2020

Thanks for reporting the issue @aaronfranke !

The 'bitness' detection is done at https://github.com/git/git-scm.com/blob/master/app/controllers/downloads_controller.rb#L49, and it's fairly basic.

but there's a problem: user agent it's not very reliable. It can be faked, different browsers act slightly different, and there are also other situations like a 32 bits browser running on a 64 bits OS. And then there's google trying to stop user-agent: https://9to5google.com/2020/01/14/google-deprecate-chrome-user-agent-string-privacy/

So, we can extend the detection for now (I found this in a quick search https://stackoverflow.com/questions/27188292/detect-if-chrome-browser-installation-is-64-bit), but maybe it's not the path we want to follow in the future.

Let us know if you want to contribute by improving the browser detection for now :)

Random idea: a page with 3 nav-panes/tabs where the user would select the OS and list the existing options. And sort them by most visited

@peff
Copy link
Member

peff commented May 26, 2020

@dscho may have some input here as the GfW maintainer. Possibly on techniques for detecting the platform, but mainly I'd be curious what you'd most like to see on the download page (default to 64-bit, or stop default-downloading at all and just give options, or something else...).

@aaronfranke
Copy link
Contributor Author

In my opinion, it would be nice for 64-bit to be the default, and to discourage users from downloading the 32-bit version (such as by making the 32-bit links have a smaller font size). In my experience, most of the time the reason people are running 32-bit software is by accident. However, I completely understand if Git-SCM wants to try and auto-detect the user's system information.

@peff
Copy link
Member

peff commented May 26, 2020

Certainly in the Linux world, I'd agree that 64-bit is the vast majority these days, and 32-bit users usually know that they need a special version. I have no clue how true that is on Windows, though. I could well believe it's the same. Let's see what @dscho says; my preference is to defer to the Git for Windows project here.

@dscho
Copy link
Member

dscho commented May 26, 2020

32-bit is still the safe bet, as it also works in 64-bit OSes.

I'd rather tweak the bit-ness detection than defaulting to 64-bit.

@dscho
Copy link
Member

dscho commented May 26, 2020

32-bit is still the safe bet, as it also works in 64-bit OSes.

I should have clarified: it is the safe bet because it works, while 64-bit won't work in a 32-bit OS. Also, 32-bit works on ARM64 while 64-bit Git for Windows does not (ARM64 has an x86 emulator but not an x86_64 one).

@peff
Copy link
Member

peff commented May 26, 2020

Thanks. So it sounds like a pretty safe and small change would be to tweak the detection to match x64 and x86_64 in the user-agent string.

It also doesn't need to be part of the same fix, but I think we should consider moving the check out to the browser-side as part of our long-term effort to make all pages static and cachable.

@aaronfranke
Copy link
Contributor Author

aaronfranke commented Dec 26, 2021

I'm on a new device, Windows 11 for ARM (64-bit ARM64). Starting with Windows 11, it can run x86_64 apps, so 64-bit x86 is preferred over 32-bit x86 (although it would be nice if there were native ARM builds available).

My user agent in Firefox is this:

Mozilla/5.0 (Windows NT 10.0; rv:95.0) Gecko/20100101 Firefox/95.0

And my user agent in Chrome is this:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36

In Chrome, the website successfully gives me the 64-bit version (although note that the user agent still claims to be x64 despite the system being ARM), but in Firefox it gives me the 32-bit version.

It may be that when the bitness is missing from the user agent, it's still a safer bet to default to the 32-bit version, but maybe this will change in the future. Also, at the same time, it's likely a bug that Firefox doesn't include the architecture in the UA.

So I'm not sure that there's anything that the Git SCM website team needs to do, but I just wanted to leave a note here :)

@pedrorijo91
Copy link
Member

thanks for exposing the issue @aaronfranke . i also think there may be little to do here. user-agent is just an effort to provide the best version, but there will always be edge cases

furthermore #1660 is removing the auto download feature

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants