Cartodb: [OAuth] New scope `datasets:r:*`

[VictorVelarde]

Context

In the context of external apps integration, we've found the need of a coarse-grained scope related to datasets, to have a fluid UX

After some conversations between @rjimenezda and @alrocar, the decision was to implement: datasets:r:* --> it will allow to read all datasets in the user account.

See https://github.com/CartoDB/kepler.gl/issues/16 for more context

[gonzaloriestra]

What about if we add schemas:r instead? It would be easier for us, but also more natural in my opinion. @alrocar?

[alrocar]

Let's clarify first the convenience of having that scope for potentially any app requesting permissions to read any data from a user account.

Ideally we talked about supporting some kind of mechanism to not grant read access over the whole user schema. Not sure if we want to consider an approach like this.

On the other hand, schemas:r looks like the most straight forward way of solving the issue, but I'd consider this scope to be restricted just for certain applications. The reason is we would be giving apps the ability to read the contents of datasets (existing or newly created) that the user might want to be private.

I've seen Google Drive has Restricted scopes. Apps that want to request that scope need to pass a security assessment.

Thoughts about this?

1. Think on a different approach?
2. Allow schemas:r but restricted for certain apps (and properly documented it). If we go with this approach, I'd suggest to add some warning for the user on the consent screen + some legal statement for application developers. This is what Google says:

Limited Use: Your use of data obtained via the Restricted Scopes must comply with these requirements:

Limit your use of data to providing or improving user-facing features that are prominent in the requesting application's user interface. All other uses of the data are prohibited;
Only transfer the data to others if necessary to provide or improve user-facing features that are prominent in the requesting application's user interface. You may also transfer data as necessary to comply with applicable law or as part of a merger, acquisition, or sale of assets with notice to users. All other transfers or sales of the user data are prohibited;
Don't use or transfer the data for serving ads, including retargeting, personalized, or interest-based advertising; and
Don't allow humans to read the data, unless
You first obtained the user's affirmative agreement for specific messages;
It is necessary for security purposes (such as investigating a bug or abuse);
It is necessary to comply with applicable law; or
Your use is limited to internal operations and the data (including derivations) have been aggregated and anonymized.
These prohibitions apply to the raw data obtained from Restricted Scopes and data aggregated, anonymized, or derived from them. You must ensure that your employees, agents, contractors, and successors comply with this Google API Services: User Data Policy.

Secure Data Handling: Applications accessing Restricted Scopes must demonstrate that they adhere to certain security practices. These applications must pass an annual security assessment and obtain a Letter of Assessment from a Google-designated third party. Local client applications that only allow user-configured transmissions of Restricted Scope data from the device may be exempt from this requirement.

[gonzaloriestra]

After discussing with @alrocar, we have 4 alternatives:

1. Initial plan: unrestricted access to read all datasets.
2. Restrict access like Drive. It would require us to manually enable each app to be able to use this new scope.
3. Filter by regular expressions.
4. Filter by tags.

We would prefer to avoid 1), as the user wouldn't have a way to limit access to other apps, and they could even read stuff from other apps. If we really need to allow reading anything, we prefer option 2.

The solution we like the most is 4), but only cartodbfied tables can have tags. The number 3 seems a bit complicated (we would need to add another trigger for the tables to check each regular expression), but it could work with non-cartodbfied tables.

Also, allowing access to non-cartodbfied tables sounds a bit unsafe because there could be some "hidden" tables that users usually don't know about (like the ones used for analyses).

[VictorVelarde]

Then it looks like option 2 could be the best one, cause we do need to deal with non-cartodbfied tables.

In the short term, only this kepler app will be enabled. And probably the next ones will be from our side, so I don't see a big problem in manually enabling apps.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[VictorVelarde]

Hopefully these have just been implemented (datasets:r:*). Thx @amiedes !

[rjimenezda]

[VictorVelarde]

Better late than never... 😄 !