Bobuam default browser OOD

[mikeruss1]

I think the defaults for out of date browsers in bobuam are a bit aggressive. They are set to around a year old and will lose a lot of valid traffic. Mine are set around 6 years old and maybe could be updated. The bad guys generally use really out of date UAs.

[Maikuolan]

It's a bit tricky. BOBUAM, both the original from MacMathan as well as the v3-compatible version which I'd committed recently, aimed to allow blocking browsers on the basis of "end of life" (hence the eol in the block_eol_browsers directive). Unfortunately, between Google Chrome, Safari, and Mozilla Firefox, none of them at all actively publish any actual EoL dates anywhere as far as any of us have been able to tell, which makes working from a literal defintion of EoL a little difficult. What I think MacMathan had been setting before, from memory, was just treating anything more than two major versions behind the current major version as effective EoL. For the v3-compatible version, I've actually been a little more conversative and had pushed it back to 10 major versions behind when I'd most recently updated it (all other than the recommended version for Safari, seeing as the current major version is merely 16, which means, even leaving it alone as it was, at 13, it's already set to only a mere 3 versions behind the current latest major version).

Likely going to become even more tricky in the future too, when they eventually start expecting us all to work from "client hints" instead of user agents to identify anything (because, AFAICT, for the client hint model to actually work would require at least two separate requests, and CIDRAM is designed in such a way as to try to identify everything right away at the first request, without any intermediary interference beyond the occasional CAPTCHA request or block event, in order to not adversely affect the user experience at the websites it protects). Still no idea how we'll resolve that when the time comes, but we'll cross that bridge when we get to it.

For the moment, though.. Looking at the Google Chrome version history, going even 10 major versions back brings us to.. only February 2022, which is.. barely 10 months ago. So yeah.. even 10 back might not be anywhere near conservative enough.

To push it 6 years back, we'd be looking at something more like 50 major versions back (given the frequency at which Google releases new major versions of Chrome), which might be a little too conversative, possibly.

[Maikuolan]

(Marking this issue as RFC. Would be good to hear from others about this, too).

[737simpilot]

Interesting about the "client hints" thing. I saw an article several years ago I forwarded to Macmathan about Google messing around with the UA. Do you have a link I can read on this new UA scheme?

[Maikuolan]

Interesting about the "client hints" thing. I saw an article several years ago I forwarded to Macmathan about Google messing around with the UA. Do you have a link I can read on this new UA scheme?

The nice, reasonably short MDN write-up about client hints: https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints

An issue at another package which I follow, which is likely to end up dealing with the same problem at some point in the future (some relevant links attached to that issue): serbanghita/Mobile-Detect#906

More tedious, lengthy documentation, for those with the patience necessary to be able to read through it:

• https://datatracker.ietf.org/doc/html/rfc8942
• https://wicg.github.io/ua-client-hints/

[mikeruss1]

my site uses Mobile-Detect, life would be easier if there were a desktop / mobile / tablet indicator in the header.

[737simpilot]

It's looking like to me that the use of other privacy invading fingerprinting may need to be used to correctly ID a client and its capabilities and thus deliver the correct content that device client can accept. Like the use of the privacy invading WebGL for example. Now if the CH (Client Hint) looks like crap and you don't know if it's a phone or tablet, I'm sure the WebGL et al metrics could positively ID that client device. That is unless the client decides to omit that too. LOL

Which all leads me to these two speculations:

1. More CPU work needing to be done server side.

2. This idea of "privacy" with the new CH is nullified.

On the other hand, I see some potential with the CH metrics and the use of better resource management based on client capability via the CH. Like the Downlink metric. That's an interesting one in that you can send the client certain scaled resources or whatever.

It'll also be interesting to see how the bad guys show their CH. They may even omit it completely if the server sends the request. I have to wonder now how Cloudflare will do this. Currently in my Cloudflare logs the UA is present which is nice, but moving forward, Cloudflare would have to request the CH. If it does at all.

I'm also seeing potential for abuse, like a DDoS. Where evil client keeps making the server send a request. If that's possible. I haven't read the in depth stuff on Client Hints.

https://browserleaks.com/

[mikeruss1]

v2 Bobuam wont let me change any of the settings? Just ignores update.

[737simpilot]

Yeah, I had something changed I think in the code of that module for it to work. The license is GNU, but I'm still a little reluctant to share the code I have because there's a Macmathan copyright. @Maikuolan knows more about this copyright crap than I do, so I'll let him chime in. I mean, I don't code, so he'd know a little more on that copyright/GNU/MIT license stuff than I do.

[Maikuolan]

@737simpilot Legally speaking, if it's licensed as GNU/GPL or MIT, you're fine to share it. But, depending on who or where the code came from, there may be other considerations, like social implications, etc (which may or may not matter; up to whoever's sharing to decide, I guess).

[Maikuolan]

v2 Bobuam wont let me change any of the settings? Just ignores update.

BOBUAM for v2 and earlier is totally unsupported now. It was being managed and maintained by MacMathan, who has since ended support from his end. I'd opted to pick up managing and maintaining BOBUAM for v3 and onward, but not for v2 and earlier, partly because ending support from his end happened after development towards v3 had already begun, and partly because of potential complications there could've been when it comes to switching over to new update channels for existing components with v2 and earlier (and the same applies to all his other blocklists and modules).

I wouldn't even recommend using it anymore for v2 and earlier due to the risk of new bugs emerging over time, its recommended defaults becoming stale over time and so on, all which would be difficult to predict or prevent. If anyone feels that using BOBUAM with CIDRAM is absolutely necessary, better to just upgrade to v3 in order to be able to use BOBUAM without the risk.

[mikeruss1]

Not a problem, wholly v3 now

[Maikuolan]

In the time that this issue has remained open, a number of new major versions have since been released, so, what might've been a bit too aggressive back then as a minimum major version, might actually be okay at this point today. I'm thinking of leaving things be as they are at this point and just leaving it to BOBUAM users to adjust these values themselves via the configuration if the defaults cause any problems. Should be good?

[mikeruss1]

your call - suggest you point users to the need to review on installation

[Maikuolan]

Good point. I'll do that.