The proper way of doing things should be that an app controls access to jailbreak features. By default nothing gets them and you can whitelist the ones which need it. I'm not sure if anything like this exists for ios but it should.
Depending on how much access you have, it's always possible for jailbreaks to hide their presence from applications (which are running at a lower privilege level). There are a couple of "jailbreak hider" implementations out there.
They also get tripped up by Apple internal devices, which as an Apple employee is quite annoying when I get locked out of a financial app.
I feel like Apple employees shouldn't be using special iPhones for personal use (out of good engineering practice; nothing special.
Who else would be the best to test new phones, software and features, and understand how they may create bugs with 3rd party apps?
In fact it’s critical to do so.
If that's your goal, shouldn't you be using a customer install?
Re:Tethered Jailbreaks Are Back
by Bnshsysjab on Monday September 30, 2019 @03:01AM
(#21112416)
Out of interest, why do you care if your users run your application on a jailbroken device? It’s been a question I’ve had for a while..
We don’t care but when a crash occurs we collect diagnostic data that we think will help us narrow down the source of the crash. Sometimes a crash happens only on jailbroken devices in which case we usually don’t spend time on it.
Re:Tethered Jailbreaks Are Back
by benbristow on Monday September 30, 2019 @03:29AM
(#21112587)
Same reason as why rooted Android devices get blocked by certain applications. Security for the user's sake. Usually it's financial applications (banking etc.) and stuff with sensitive user information.
Re:Tethered Jailbreaks Are Back
by yjftsjthsd-h on Tuesday October 01, 2019 @12:03PM
(#21126965)
As an Android user, this is super annoying: I rooted the device because I want to control it. Now some stupid app comes along and claims that, for my own protection (supposedly), they're going to break for me. It's insulting, really.
Jailbroken devices can attack application logic to cheat in multiplayer games, somewhat attack DRM systems for video content (though Fairplay isn't especially vulnerable here), gain access to chargeable features without paying for them (decompiled Spotify APKs that do not feature advertising without having to pay exist on Android and are a non-trivial revenue risk) etc etc.
In more open systems you are usually more able to run detection software for the above without sandboxing.
Piracy for Android doesn't require a jailbroken/rooted device.
It only requires one jailbroken device on iOS. Or, if you're using the right tools, none.
I maintain my company's in-house mobile app crash reporting system and I had to remove jailbreak checks from our iOS SDK. It turned out that some of the checks were causing crashes themselves due to buggy anti-jailbreak-detection code some jailbroken devices had in place. e.g. checking whether a file could be accessed that normally iOS disallows would end up causing a crash instead of just a permission error.
Instead, I just do some basic server-side detection. Basically, looking for libraries loaded into the app (e.g. cydia) that are only present on jailbroken devices. Some jailbreaks don't even try to hide their presence.
I don't know what iVerify does. I hadn't heard of it before. I'm curious how it avoids crashes though... perhaps it avoids invoking any dynamic system calls.