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.

Sign up for GitHub

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

Jump to bottom

Integrate with the Permissions API or its model? #32

Closed
hober opened this issue Apr 28, 2020 · 7 comments · Fixed by #138
Closed

Integrate with the Permissions API or its model? #32

hober opened this issue Apr 28, 2020 · 7 comments · Fixed by #138
Labels
future Will consider for a future revision integration Integration with other specs

Comments

@hober
Copy link
Member

hober commented Apr 28, 2020

@Brandr0id wrote, in #29 (comment):

Now that we have a concept of a map storing the storage access flags does it make sense to just integrate with permissions that are keyed to the top-level and embedder origins rather than introduce a storage access map that's unique to this spec?

I could see the [=storage access map=] being a permission for Storage Access set with the [=partitioned storage key=] properties and the state "granted" or "denied" representing a success/failure of the API. The presence of the permissions "prompt" state and the concept of potentially prompting the user for access if no implicit grant is made may also tie nicely into this.
@hober hober mentioned this issue Apr 28, 2020
Merged
@hober
Copy link
Member Author

hober commented Apr 28, 2020

See also #12.

This was referenced Apr 29, 2020
Open
Closed
@hober hober added integration Integration with other specs agenda+ Request to add this issue to the agenda of our next telcon or F2F labels Jul 6, 2020
@TanviHacks TanviHacks removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jul 14, 2020
@jimmywarting
Copy link

I would like to se the Permission API being used instead of document[hasStorageAccess|requestStorageAccess].
Annoying to have to see new permission proposal all the time with different quirks and api structure

the permission api have two things i was currently interested in, namely revoke and potentially observing for changes

@johannhof johannhof added the future Will consider for a future revision label Mar 22, 2022
johannhof added a commit to johannhof/storage-access that referenced this issue Jul 18, 2022
@johannhof
Change permission policy feature name to "storage-access" (fixes priv…
d1d54fc 
…acycg#104)

This was discussed before in privacycg#12 and there was some valid concern around
the "storage-access" name based on the fact that this PP feature is more
focused on "requesting" storage access, and there is no delegation
mechanism like with other permissions that would make it semantically
consistent.

However, I think that in light of privacycg#32 and the possibility of integrating
with the permissions API (giving us important functionality such as
observing when storage access is granted) it seems more useful to be
consistent with the (future) permission name and call both "storage-access".
@johannhof johannhof mentioned this issue Jul 18, 2022
Merged
johannhof added a commit that referenced this issue Aug 11, 2022
@johannhof
Change permission policy feature name to "storage-access" (fixes #104)
97ccd6c 
This was discussed before in #12 and there was some valid concern around
the "storage-access" name based on the fact that this PP feature is more
focused on "requesting" storage access, and there is no delegation
mechanism like with other permissions that would make it semantically
consistent.

However, I think that in light of #32 and the possibility of integrating
with the permissions API (giving us important functionality such as
observing when storage access is granted) it seems more useful to be
consistent with the (future) permission name and call both "storage-access".
@annevk
Copy link
Collaborator

annevk commented Oct 7, 2022

Integrating with the model is tracked in #121.

If we integrate with the API, is the expectation that permissions.query() and hasStorageAccess() are aligned? It's not entirely clear to me that's possible given how storage access is scoped differently. In that Permissions are typically origin-scoped (though here they would be origin+top-level-site-scoped) and storage access is document/page-bound.

@titi714
Copy link

titi714 commented Oct 7, 2022 via email

@johannhof
Copy link
Member

See my comment in #121 (comment)

Maybe we should dupe #121 into this one or vice-versa @annevk?

@annevk
Copy link
Collaborator

annevk commented Oct 10, 2022

I was hoping we could use this issue for the API discussion in particular, which I think is somewhat distinct. Although perhaps they need to be decided upon jointly.

@titi714
Copy link

titi714 commented Nov 7, 2022 via email

@johannhof johannhof linked a pull request Dec 6, 2022 that will close this issue
Use the Permissions API (closes #121, #32) #138
Merged
3 tasks
johannhof added a commit that referenced this issue Jan 5, 2023
@johannhof @annevk
Use the Permissions API (closes #121, #32) (#138)
a20c3cc 
This is building on top of w3c/permissions#390 to integrate SAA with permissions. It's deleting a lot of old manual state management but doesn't get rid of the (global) storage access map altogether, since that is done in #141.

Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
future Will consider for a future revision integration Integration with other specs
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use the Permissions API (closes #121, #32) johannhof/storage-access
7 participants
@hober @johnwilander @jimmywarting @annevk @johannhof @TanviHacks @titi714