4 ms·
I can't really say if Google is taking this approach to secure a device from heavy handed enterprise admins; but if true, it's gone too far by allowing only the
by ffernand 10y ago
I can't really say if Google is taking this approach to secure a device from heavy handed enterprise admins; but if true, it's gone too far by allowing only the app from having private conversations with the api and not allowing the user to see what's being sent over the wire.
This isn't exactly new, we do after all, have certificate pinning. But now, this certificate pinning is done at the OS level by DEFAULT, un-trusting all certs except the ones that Google deems fit.
We know that there have been un-trustworthy Certificate Authorities that all our machines have trusted until its been deemed unworthy by our vendors... and eventually expunged! But this change explicitly un-trusts us, the users of our own phones -- in the name of security.
User deftnerd (https://news.ycombinator.com/item?id=12061342 https://news.ycombinator.com/item?id=12061342) had an excellent suggestion that the trusting of user added certs can be relegated to the TPM module (via password, passcode, fingerprint, etc..) -- not by the heavy handed approach of simply blocking us out of our own phones conversation.
- xg15 10y agoThis may be a conspiracy theory, but how probable is that this move is instead actually motivated by app developers that want to make reverse-engeneering harder? There have been cases in the past were hidden APIs were discovered that e.g. Twitter or WhatsApp were reserving for their own apps. (Not to mention privacy leaks). This will certainly become harder with the new change.
- Nullabillity 10y agoHonestly, it shouldn't change that too much, since third parties like Cyanogenmod should be able to reverse the change. Of course, it's still a horrible move.
- iancarroll 10y agoDevelopers who want to do this can already pin certificates relatively easily.