I was earnestly surprised how much data macOS and Android devices tend to put into the user agent. Not only the exact patch level of the browser, but also the OS patch level and Android devices even tend to broadcast the precise device model as well -- more accurately than just looking at the device!
Some examples:
Mozilla/5.0 (iPad; CPU OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.0 Mobile/14G60 Safari/602.1
Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_1 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) iOS/16.0.7.121031 Mobile/15C153 Safari/9537.53
Mozilla/5.0 (Linux; Android 7.0; LG-H840 Build/NRD90U) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.111 Mobile Safari/537.36
A Linux in comparison:
Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
While it includes the version number, no patch level (57.0.X) is included.
As a developer:
Without user agent: How would I easily detect which browser breaks a certain feature on my project?
If I deploy a new feature and see through logging that a browser X is not able to do Y then I can install X on my machine and test and fix it.
If I don't have a user agent then I can just detect that after deploy there are more cases where Y fails but I don't know which browser is responsible for this.
If it's a major browser which management cares about, then you should be testing with it already. If you're not, then logging user agent strings isn't going to help.
Logging user agent strings would help if, for example, an unexpectely-large proportion of users are using a "non-major" browser, in which your site is broken.
If the proportion is small, management won't care.
If the proportion is expected, then market/demographic research is partly to blame; update the spec.
If the browser is "major", you should be testing with it anyway.
If the site isn't broken, there's no problem.
Even if Chrome followed the spec to a T, programmers still write bugs. So, I'm not going to expect a browser (at least) 15 versions old to behave perfectly. And we all know that the spec isn't perfectly implemented.
So, no. Unfortunately sometimes there are things that will make management care a lot about a browser that they really shouldn't.
I never said management should or shouldn't care about this or that browser. I never said anything about browsers being new or old.
I said that developers should be testing with whatever browsers management cares about. If management care about it, and there's some justification, then add it to the spec.
> unfortunately, especially in enterprise, the browser version is often locked to something quite old. One of our clients has locked to Chrome 48.
That's an excellent justification for having Chrome 48 compatibility as part of the spec, so you should already be testing your sites with it. What has that got to do with user agent strings?
Is Chrome 48 even old? I tend to ensure IE6 compatibility, unless I have a good reason otherwise (e.g. voice calls over WebRTC, or something). When I'm using w3m, e.g. to read documentation inside Emacs, I occasionally play around with my sites to ensure they still degrade gracefully.
And if you are using the latest and "greatest" JS features, you have to expect the failures that happen. If you enjoy sitting on the bleeding edge, don't complain about getting cut.
If you implement features using known, simple and stable tech, things will generally work great without needing to worry about special cases.
Why would you willingly do that to yourself? If we pushed browser developers to actually do their job, they wouldnt be pushing their weight around like they do now.
Extreme ownership of problems. It's a really helpful concept. You'll stop trying to blame people all of the time for things that you can control and find solutions for them instead. On top of that, if you can't control it you can let it go as something that you can't fix.
If you need your car to be reliable, don't bolt experimental features onto it, and test it before you need to take it on the road.
I run whatismybrowser.com and it's a perfect case of why user agents are useful information. It'll tell you what browser you've got, what OS, and whether you're up to date or not. It's extremely useful to know this info when helping non-tech users - you would not believe how many people still reply "I just click the internet" when you ask them what browser they're using. My site helps answer all those complicated "first" questions.
I completely agree that using User Agents for feature detection/brower compatibilty is a terrible idea, but apparently enough websites still do it to warrant having to keep all that useless, contraditory mumbo jumbo in it too - it isn't what they should be used for any more!
And also, I don't think there's any problem with including "too much" information in the user agent either - point in case: Firefox used to include the full version number of Firefox in the user agent, but now it only shows the major version number, not the exact revision etc. The problem is I can no longer perfectly warn users if they're actually up to date or not.
The reasoning for this is given as a security concern, which I still don't understand - if there's a security problem in a particular point-revision version of Firefox which can be exploited by a malicious web server - odds are they're just going to try that exploit for any version of firefox and it either will or won't work - how does the malicious site knowing the exact version make the situation any worse?!
I don't know why we ever thought sending all this data to the server was a good idea
Remember: incentives. The goal of a web developer is to make sites people use.
> Remember: incentives. The goal of a web developer is to make sites people use.
The goal should be to empower users. Anyone can make a site that people "use"
I mean, in an ideal world, of course it does. But again: incentives. Keep in mind: search engines themselves are extremely empowering, and they are not generally considered to be something a person pays directly for.
Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0Or if you're concerned as a user of a regular "safe" site... Google Analytics does all of these things: link tracking, hover tracking, media query tracking. GA or something like it is being used by vast swaths of the web. I don't claim it's the majority, because I don't know, but that's what I assume, that all sites are tracking (whether or not the site even knows it.)
In other words: Do you not want a third party (like Google) to have that data or the second party (web administrators)?
It's not bad for people to analyze how users interact with their site. It's bad when one entity (or a handful) can track you across the Internet.
So in other words, I don't mind Piwik and have considered sending in a patch to uBlock and others with a switch to disabled "locally hosted analytics" or something similar. Like the drive to push "ethical advertising", I think it's reasonable to permit some benign tracking as a way to coerce more sites into decentralizing user analytics.
My primary objection is automated profile-generation and identifier sharing - third parties don't need realtime updates on my reading habits. I like to think folks who run their own analytics aren't sharing identifiers with adtech shops, but of course can't know.
[1]: https://whotracks.me/trackers/google_analytics.html [2]: http://randomwalker.info/publications/OpenWPM_1_million_site...
Oh my. I wish this madness ended. Quoth tedu:
> I don’t know a whole lot about typography and fonts, but there’s two things I know about font files. They’re ridiculously complex and their parsers have only just begun to experience life with hostile inputs. In short, I’d put fonts second on my list of files likely to pwn your browser, after Flash [...].
There's still a lot of attack surface here, but "only just begun to experience life with hostile inputs" isn't quite true either.
It doesn't; without media queries you can't detect thing like browser window size or screen pixel density.
> * Font checking - Can help fingerprinting...browsers need to start restricting this list better IMO (not familiar w/ current tech, but would hope we could get it down to OS-specific at the most)
There's a lot of trade-offs here. Plenty of people have fonts installed for various reasons (some because none of the system fonts cover a script they want, some because they're using fonts designed to mitigate some issues caused by dyslexia, etc.), and breaking it for those people would not be good.
Sorry if I wasn't clear. I shouldn't have said media queries, I should have said "CSS property queries". What CSS properties you have doesn't leak any more than your UA I would guess.
> There's a lot of trade-offs here [...]
I'll take it as an option to have a strict subset (though would prefer it as opt-out to discourage font-list-based fingerprinting as a practice, though metric-based may never leave). With downloadable fonts, I don't really like the "script they want" excuse. For accessibility reasons, I am admittedly naive, but I would assume it would be a substitute for an existing font name. Unique font names per user seem unnecessary.
>> Unique font names per user seem unnecessary.
As a dev that has worked in CSS for over a decade, I have no idea what either of those mean.
EDIT: I see the unique font names part now, totally missed that while focusing on the other parts.
https://github.com/reddit/reddit/blob/master/r2/r2/lib/cssfi...
https://www.reddit.com/r/cssnews/comments/24anzb/css_change_...
All of this is an easy fix: disable css. In the same way that "I don't want to be tracked by javascript" can easily be resolved by disabling javascript. I'm not seriously suggesting everyone does that, but anyone who is so paranoid that they don't want a site knowing that they're reading its content might want to consider it.
Honest question: how much of this is left? What popular sites are still accessible this way? HN might be the only site I visit frequently where browsing with no js/css has any hope of working.
I get that some people have low tolerances for things not being perfect. CNN stories without JS usually have a pile of empty images at the top, for instance. But that is probably fixable; I just haven't bothered to figure out which bit of JS to allow for that.
Usability depends on your tolerance for imperfections vs. your tolerance for being observed.
[1] Current setup uses JS Blocker 5, uBlock, an aggressive cookie manager and my home proxy, which does a ton of things, many of which I don't even remember at this point.
("anonymously" assuming I'm blocking their cookies, which I would if I were that paranoid)
Note that cookies are mostly a convenience vis-a-vis tracking. For user tracking, there's nothing really stopping the server from vending you a version of their site with custom CSS that loads images with a fingerprint in the URL, which would still work with cookies disabled. That'll get you coherent signal on a session (gluing different sessions together would be a bit more challenging, of course, but I wouldn't be surprised if it were possible).
What I hate, is the fact that I go to agoda, I search for hotels in jiufen in taiwan, I look at only 2, I book one of the 2, I close it. Open up Facebook on my phone seconds later and have adverts saying: hey how about these 2 hotels in jiufen.
That shit annoys me. Stop following me and tracking what I’m doing and sharing it with all these companies. It makes me want to not use the internet...
There's little interest in proxying through a token system (this would require a DB read at each click, and a DB write at each page generation), which means the actual link is available client-side and the whole thing can be bypassed.
'/redirect?url=...'
* Link click tracking - So what, the site could route you through a server side proxy anyways
* Hover tracking - Can track movements of course, but doesn't really help fingerprinting. This is still annoying though and not an easy fix
* Media query - So what, user agent gives this away mostly anyways
* Font checking - Can help fingerprinting...browsers need to start restricting this list better IMO (not familiar w/ current tech, but would hope we could get it down to OS-specific at the most)
If you're concerned as a site owner that allows third party CSS:
* You should have stopped allowing this a long time ago (good on you, Reddit [0] though things like this weren't one of the stated reasons)
* You have your Content-Security-Policy header set anyways, right?
Really though, is there an extension that has a checkbox that says "no interactive CSS URLs"? I might make one, though still figuring out how I might detect/squash such a thing. EDIT: I figure just blocking url() for content and @font-face.src would be a good compromise not to break all sorts of background images for now.
0 - https://www.reddit.com/r/modnews/comments/66q4is/the_web_red...