An application firewall on the device serves a different purpose to that running off-device, namely the ability to filter traffic based on the origin (or destination) application.
Clearly if your kernel or userspace are compromised that's not much use, and that's where external controls kick in.
You can't determine (absent some custom network and protocols) which piece of software was responsible for a given packet once you leave the device though, so that's the (current) best place to do that - if you want to impose policies controlling the hosts and protocols an application can use, you will want to implement this on-device, then firewall for the superset of all of those at the network level.
In essence it's about raising the number of independent failures required to result in a compromise. If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.
To fight apps phoning home, I agree. But even the tweet linked in OP refers to a tweet that shows how to abuse the now removed whitelisting by piggybacking your traffic through one of those whitelisted apps. On a locked down system like Android or iOS this isn't that trivial, but in a classic desktop OS use case it's easy to abuse another app to exfiltrate data.
> In essence it's about raising the number of independent failures required to result in a compromise.
Sure, it doesn't hurt, minus maybe the case that a vulnerability in that firewall itself is used.
> If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.
That's a requirement I guess. You don't want accountants and HR people handling popups by a firewall app. :-)
Clearly if your kernel or userspace are compromised that's not much use, and that's where external controls kick in.
You can't determine (absent some custom network and protocols) which piece of software was responsible for a given packet once you leave the device though, so that's the (current) best place to do that - if you want to impose policies controlling the hosts and protocols an application can use, you will want to implement this on-device, then firewall for the superset of all of those at the network level.
In essence it's about raising the number of independent failures required to result in a compromise. If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.