[inetknght]

> *Nine of them have Google Workspace OAuth permissions that include reading all emails and accessing all Drive files. Nine. I authorized every one of them without reading the permissions because the onboarding flow asked and I was in a hurry."

No, you didn't authorize every one of them without reading the permissions because the onboarding flow asked and you were in a hurry.

You authorized it because the onboarding flow asked, and you weren't given an opportunity to say no. What are you to do: say no, and then not use the app?

This whole concept is just wrong. Instead of saying "no" and the app seeing that you didn't grant permission: you should be able to say "no", and the app shouldn't see any denial at all. It should just see empty data when requesting it. Problem fucking solved. You get to use whatever apps you want, apps get to ask for whatever permissions they want, and you get to deny that permission without the app fucking you over.

[lesuorac]

I think it's a bit easier to add a "Some" option so that then the App is unaware to the effective "No" answer.

But also a lot of the permissions are just bad. Like I think it's reasonable for somebody to make a web-app that uses my Google Drive as a backend for storing data. I don't think its reasonable that it should be able to open files it didn't create though.

[watchful_moose]

This just moves the problem to support. The app doesn't work for users, they don't remember clicking no, and then some CSR has to hand-hold them through clicking "yes".

[inetknght]

> This just moves the problem to support.

Boo-hoo. Support should exist. Support should be trained. Support should help educate the customer. If your business isn't doing that then your business is trashy anyway.

Many companies don't have support. That's a major problem. We have a lot of trashy businesses.

[SAI_Peregrinus]

The app shouldn't see empty data, it should see statistically likely fake data.

[inetknght]

While you're right, I'll be happy with just empty data for now. Generating statistically-likely false data is only recently available generally and turns out to be rather expensive.

[SAI_Peregrinus]

For the most sensitive fields (names, addresses, phone numbers) it's quite simple. For names, you get a list of the (say) 1,000 most common names, and pick randomly from the list. For phone numbers, you generate random numbers with valid formatting (not all area codes are valid, etc.). For addresses, you pick randomly from a database of real addresses. Etc. No LLM-style generation needed.

[losvedir]

What? This makes no sense to me. What's the threat model where you'd rather the OAuth flow result in the client app getting fake data?

If you reject the permissions the client already doesn't hear about it because the callback redirect isn't invoked (or at least, there's no reason for it to be, but that's up to you).

> What are you to do: say no, and then not use the app?

Um, yes? That's literally the point of what's happening. The app is asking for permissions because it needs it to do whatever it's doing. If you don't want to give it access to the data then there's no reason to use the app.