The technical details page says this works by running a VPN and intercepting all the traffic. Therefore it seems it would only work on unencrypted traffic.
This makes the following claim seem inaccurate:
> Our system is accurate, identifying 98.2% of leaks for the vast majority of flows in our dataset
There is no way <2% of the web and application traffic is encrypted. Bypassing all detection would be as easy as going to the HTTPS version of a website.
This also seems like it would pose a significant security risk as the servers would be a very juicy target to hack (holding all their customer's personal information and passwords) as well as ability for the staff themselves to surveil their users.
They could require a root ssl cert to be installed and then just MITM all the traffic. And Org that wants to protect personal data might be willing to do something stupid like that.
For a properly engineered mobile app there are only downsides to using the public CA system (and thereby the devices CA store). So that would not work.
If you have a rooted Android (up to M, I believe) device, you can install Xposed[1] and XPrivacy[2], which prompts you when an app wants to do things like a DNS lookup, or access your address book. The most surprising thing I found with it was a fitness timer app that wants to be notified when my phone rings, with the phone number as a parameter... yeah, "Deny".
It's a good solution, but may be less capable than XPrivacy, at least in some areas.
For example, I think PMP doesn't have options to filter loading native libraries or executing external commands - and this is sometimes useful, e.g. by blocking loadLibrary calls for libYandexMetricaNativeModule.so (some apps would crash, some would survive and would probably leak less analytics)
I believe both tools (and anything Xposed-based) isn't perfect, though - native code can work around this stuff. I wonder if there's QubesOS-like Android-in-Android (using a virtualization) solution exists, besides that Samsung's proprietary enterprisey nonsense...
Any app with android.permission.READ_PHONE_STATE ("Phone calls — read phone status and identity")
All those apps receive android.intent.action.PHONE_STATE broadcasts whenever the phone state changes (new call, etc), and for the incoming calls that intent's data always (AFAIK, maybe some firmware builds have privacy controls for this) contains the phone number.
You can check the full list of permissions of the particular app you use. Full permissions list is also available in Google Play - there's "permissions details" link at the very bottom (https://support.google.com/googleplay/answer/6014972). Personally, I check this list for every app I find interesting.
If "read phone state" is listed then the app knows who's calling you, in a sense system feeds this data. Whenever the app uses it or not depends on how shady it is.
The middle screenshot in your linked page has a spelling error that really pops. It makes it hard for me to consider using something like this when I have to ask myself whether things like this are buried in the code making some of it do strange, unintended things.
This makes the following claim seem inaccurate: > Our system is accurate, identifying 98.2% of leaks for the vast majority of flows in our dataset
There is no way <2% of the web and application traffic is encrypted. Bypassing all detection would be as easy as going to the HTTPS version of a website.
This also seems like it would pose a significant security risk as the servers would be a very juicy target to hack (holding all their customer's personal information and passwords) as well as ability for the staff themselves to surveil their users.