Consistent detection of "Safari shells" in iOS
igorsantos07 opened this issue · 13 comments
After giving up on some "simple regex" to detect common browsers (yep, you know for which project lol), I landed in this library :)
Thus, I already had a bunch of UA strings to test against; I noticed that, while iPhone/CriOS is detected as Chrome on iPhone, FxiOS and EdgiOS end up simply as Safari.
This seems related to #40 since there might not be much value on distinguishing them all, but looking from a statistical POV, it would make some sense to separate the shells from the actual Safari. Besides that, consistency is always good :)
Samples:
Mozilla/5.0 (iPhone; CPU iPhone OS 15_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/103.0.5060.63 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPad; CPU OS 15_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/103.0.5060.63 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 12_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/101.0 Mobile/15E148 Safari/605.1.15
Mozilla/5.0 (iPad; CPU OS 12_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/101.0 Mobile/15E148 Safari/605.1.15
Mozilla/5.0 (iPhone; CPU iPhone OS 15_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 EdgiOS/100.1185.50 Mobile/15E148 Safari/605.1.15
I've gone back and forth and back and forth on how to handle iOS browsers. It's a complex issue with no right answer.
As you've seen, thus far I've just landed on just not handling them to and letting them be parsed as Safari.
I've got two groups of people who use this
a. people who use it for deploying features by browser
b. people who use it for stats/analytics
I suspect for the majority of users, not parsing them is in their best interest -
If I called CriOS "Chrome", someone offering up a feature only available on Chrome could be burned because CriOS isn't actually Chrome and doesn't behave like Chrome.
On the other hand people using it for analytics might be burned because they get inflated states for Chrome use, despite it actually being Safari, so they invest more time in optimizing for Chrome and not enough time optimizing for Safari that people are actually running.
As for the specific advantages of detecting them, there are certainly going to be people specifically targeting features towards specific Safari wrapping pseudo-browsers - I imagine propper feature detection is more optimal in these cases.
As for the stats people, I don't know why you'd actually care what Safari wrapper they're running, it doesn't really affect you?
Please push back though, this is just the state of my thinking currently. I'm more than happy to hear you out.
If I called CriOS "Chrome", someone offering up a feature only available on Chrome could be burned because CriOS isn't actually Chrome and doesn't behave like Chrome.
This makes total sense. It would definitely be misleading.
And indeed... not sure how useful it is to know what browser the person uses, if in the end the actual data is "how to support our users".
That all said.......... I'm really reporting a bug in this topic
I'm really reporting a bug in this topic
😅 CriOS is reported as iPhone Chrome, while the others go as Safari, as it would make more sense.
HAH - I need to work on my reading comprehension
There's a translation happening here.
I guess EdgiOS and FxiOS should also be included in that array?
Seems I just copy-pasted without reading lol nvm
I guess EdgiOS and FxiOS should also be included in that array?
See, that's the question. You're completely right, the inconsistency sucks. I don't know how or why I did that.
My gut says this means I need to add iOS Firefox and Edge, but my heart says I should drop Chrome
I'm not exactly sure what's going on, I didn't took the time to fully grasp the codebase. Anyhow, I would guess by the time you coded the CriOS override, FxiOS and EdgiOS weren't available yet, so we could guess it's just outdated?
Another idea, as to cater to that duality you face, is adding an option to the class instance (or parse() call, so it feeds directly to the procedural function), like parse($keepSimilars = false). Go with the default behavior the library currently has (if I understood it righ) - which is to translate all "similar browsers" to their original counterparts (e.g. IceWeasel to Firefox, CriOS to Chrome, and add EdgiOS/FxiOS to the bucket), and then allow the user to request that all similar browsers are kept as-is, so the library can better serve their statistical purposes.
Does that make any sense?
Fun fact: a while after the discovery of your fake clone, I stumbled upon this dependency on the project and realized I was kinda talking to you here as if you were really working with us (re: "yep you know for which project" in the description and all)
Anyhow, at least I didn't include this because of the other guy, it was just a coincidence. I guess I should've asked him for help, instead of formally opening this issue lol
a while after the discovery of your fake clone, I stumbled upon this dependency
My fake clone?
Oh, I see. You worked with the person who stole my identity! Did you work for one of the two companies that have already reached out to me - or is there a third I’m just learning about now?
Thanks for the heads up. I contacted GitHub and their account is already gone. It was really quick.