There's a bit of pragmatism involved in the level of control.
If you add too much friction to the process of accessing information, then it can actually impede on actually handling user support. For example, having access to someone's ride history when trying to resolve a dispute seems relatively normal.
Of course in Lyfts case it seems pretty clear that there can be more programatic locks. And auditable logs are able very good idea in general.
But programatic locks are tricky. How do you transform and e-mail from a user confirming permission to history into an unlock code?
If only we had modern phone infrastructure that could actually transfer useful info to the appropriate person... Instead we have terrible phone support that requires me to repeat the same info 3 times.
That info should be unlocked the millisecond I am connected with a rep . It's not a moonshot
My feeling is that stuff is doable, but hard-ish. For example, for this case now you're writing something to interface with the phones? How do you know the phone number is for a certain client?
Though I definitely see someone writing a thing where your ticketing/support system grants partial data access, you end up either making the support system pull in information from the DB... or your DB access controls being controlled through the support system.
the latter one can potentially introduce security issues. The former one's easier but you can easily run into the "oh, this information's not gettable through the ticketing system".
If you add too much friction to the process of accessing information, then it can actually impede on actually handling user support. For example, having access to someone's ride history when trying to resolve a dispute seems relatively normal.
Of course in Lyfts case it seems pretty clear that there can be more programatic locks. And auditable logs are able very good idea in general.
But programatic locks are tricky. How do you transform and e-mail from a user confirming permission to history into an unlock code?