Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What types of capabilities should applications be allowed to request? #727

Closed
ddorwin opened this issue Jun 21, 2019 · 5 comments
Closed
Assignees
Labels
fixed by pending PR A PR that is in review will resolve this issue. privacy-and-security Issues related to privacy and security
Milestone

Comments

@ddorwin
Copy link
Contributor

ddorwin commented Jun 21, 2019

In addition to specifying when (#720) and how (i.e., #723) applications can request capabilities/features, we will need to determine what are the actual capabilities/features to be exposed. Before we get to that, though, it probably makes sense to explore the categories or dimensions of capabilities that should be exposed. Although the focus has been on consent, there may be other reasons that applications should request capabilities up front (see #723).

The privacy design (#638) details various threats and why consent might be required, but further work is necessary to determine how many different dimensions of consent make sense and what they should be.

As said in response to question 7 in #689 (comment), IMO, something like "spatial-tracking-unbounded" is probably too granular and would become difficult for developers to use. IMO, it probably makes more sense to define what the user is giving up, which may not map 1:1 to a single concept in the API surface.

@toji toji added the privacy-and-security Issues related to privacy and security label Jun 21, 2019
@NellWaliczek
Copy link
Member

It's funny, I was actually thinking in a very different direction with #723, though I can see why you'd prefer to separate this discussion from that one.

Do you have a specific proposal for what "defining the user is giving up" would mean? Are you optimizing for developer difficulty or end-user difficulty? Because my original though on the topic is developers might find it less confusing if they just indicated which APIs they plan on calling, which is even more granular. So i'm really interested in seeing what your alternative might look like.

@cwilso cwilso added this to the June 2019 milestone Jun 24, 2019
@NellWaliczek NellWaliczek self-assigned this Jun 24, 2019
@probot-label probot-label bot added the fixed by pending PR A PR that is in review will resolve this issue. label Jun 26, 2019
@probot-label
Copy link

probot-label bot commented Jun 26, 2019

This issue is fixed by PR #739

@NellWaliczek
Copy link
Member

NellWaliczek commented Jun 26, 2019

In terms of the way these consent prompts are communicated to the users, I totally agree that the api-level granularity doesn't make much sense. However, from a developer's perspective of knowing how to ensure necessary prompts are displayed, it does. In my proposal in #739, the communication from the developer to the UA is done granularly, but because it's all done up front the UA has the option to explain things in the way they think will make the most sense to their users.

@johnpallett
Copy link
Contributor

@NellWaliczek
Copy link
Member

Closed by #739

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed by pending PR A PR that is in review will resolve this issue. privacy-and-security Issues related to privacy and security
Projects
None yet
Development

No branches or pull requests

5 participants