What is the use case for this? Learning more about how Android apps communicate with their home server?
For a full bypass of that crap, you nowadays need a lot of resources including a Secure Enclave exploit - for now they're (relatively) cheap but eventually they'll be the kind of stuff traded for seven figures a pop.
Eternal shame on Google for not insisting that Android would follow the "PC model" of the user being root on their own machine and DRM and whatnot can go and screw themselves. They had the chance of actually delivering something that would not require jailbreaking and cat-and-mouse games like iOS, but they blew it (and blew the MAFIAA instead).
The funny thing is that they wouldn't have even needed to take this position. DRM works well enough on (e.g.) Windows to make the various studios more or less happy, and users have "root" on Windows as usual. Ditto for macOS. Hell, DRM works just fine on my Linux desktop install, as much as I despite its existence.
To be fair to Google, banks don't usually allow you to download and generate EMV tokens to perform card transactions on your PC, which places a different set of security requirements (legal requirements too) on Android phones for things like Google Pay to exist.
I might be less angry about that if there were a decent FULL backup solution for Android - with iOS I can do a backup and restore and almost everything will be restored, I think the sole exception is eSIM and Apple Pay because the secrets for that are in the SE. But for Android? Forget it, and there's enough games that don't even implement Google Play cloud-save integration. No way to backup these without root.
That requires HTTPS interception. Before TLS1.3 they would install root CAs on all company devices, have an edge proxy, and use SNI to determine whether an HTTPS session should be man in the middled. Because it would take way to much compute to MitM all trafic (like YouTube video).
After TLS1.3 encrypted SNI blocks this. But they still need (and other companies want) to selectively intercept HTTPS. With a tool like this you can achieve that clientside, rather than at the network edge.
It can be disabled if an organisation wishes to. I wrote about how to do this in Chrome [2,3], and will write about Firefox when I get a chance.
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ [2] https://chasersystems.com/blog/disabling-encrypted-clienthel... [3] https://news.ycombinator.com/item?id=37823262
I do find it sad it isn't pushed harder. Companies who need to do interception have legitimate concerns, but they can be addressed.
> L’employeur ne peut pas mettre en place un dispositif d’écoute ou d’enregistrement permanent ou systématique, sauf texte légal (par exemple pour les services d’urgence).
And there's afaik no such legal text for banks.
Employees also have the right to privacy on their work-provided computer (e.g. to check their personal mails) so all those packet inspection and decryption things would be flat-out illegal there, thankfully
If you want to check your private email, you can just use your personal device.