It almost seems like they do it intentionally to improve tracking and desensitize users. Only a terrible engineer would think needing to know if the phone is ringing needs a permission, let alone one that provides unique IDs plus the phone numbers on phone calls.
It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and history. They use dark UI patterns to trick people into activating stuff.)
Adding to that: In Android Lollipop, One can't edit / delete local (phone-stored) contacts. They have to be synced to cloud in order to edit / delete them. If this is intentional, it is a sick dark UI pattern.
On one hand it's backwards from the user experience POV. On the other hand it garantees consistency and resolves most of the weird edge cases of contacts syncing.
I think the common wisdom would be to put the burden on the engineers to find a solution that somewhat handles all the quircks. Personally I've had so many sync failure and weird behaviors from all the services tried until now that I would settle for a more reliable system, even it had severe usability limitations.
I envy organizations that can omit "obvious" features when they don't have a good enough solution to satisfy all the edge cases.
It wouldn't matter if contacts were encrypted client-side, but Google seen to have a severe allergy to client-side encryption. Mozilla are really leading the way on this issue.
What I think is particularly sad is that Google could still make a huge amount of money without exposing one's private information directly.
Full-device encryption does nothing when data are transmitted off-device.
E.g., as long as my photos stay on my phone, they are encrypted, but if I back them up to Google+ then Google may read them.
Which is really pretty crazy: Google don't need to read those photos (or my contacts, or my documents); my computers need to, and the computers of those I share the photos with need to.
I could encrypt each photo with a unique key, and encrypt that key with my own private symmetric key, as well as my friends' public asymmetric keys, and then both they and I could view the photos at any time (our devices knowing how to access the keys we have authorised for them), but Google would not.
It should need a permission in my opinion. Why should a calculator (for example) know if there is incoming call?
But this case should be handled by a permission in dialer (or whatever handles incoming calls) - something like "allow to broadcast mute to all other applications".
> Why should a calculator (for example) know if there is incoming call?
Because it's running on a phone.
Remember those cool requestAnimationFrame side-channel timing attacks. I think it'd be pretty hard to hide at least certain things like these from an app if it really wanted to know. In this case I think it's pretty fair to just give it an API call for it.
Why shouldn't it? It's on a phone; it's part of basic usability. And the cure in Google's case is far, far worse. Give them access to your IMEI and phone numbers in and out. I know assume incompetence over maliciousness, but this stretches belief. Especially combined with the rest of Google's little tricks.
> I know assume incompetence over maliciousness, but this stretches belief.
It's worse than that. Android had a saner permission interface, with a separated permission just for detecting if the phone is ringing. Google "updated" it to the current format alledging the previous one was too confusing.
It's one more reason I've gone from loving Google to actively avoiding them. (Also, they've very aggressive in getting people to turn on location info and history. They use dark UI patterns to trick people into activating stuff.)