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

Use the Permissions API (closes #121, #32) #138

Merged
merged 10 commits into from
Jan 5, 2023

Conversation

johannhof
Copy link
Member

@johannhof johannhof commented Nov 18, 2022

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 the per-frame change being worked on by @cfredric.

This is a bit WIP just by virtue of the other change not having merged yet. I removed some of the references to the other spec to avoid the build from breaking.


Preview | Diff

storage-access.bs Outdated Show resolved Hide resolved
@annevk
Copy link
Collaborator

annevk commented Nov 22, 2022

How would this not expose "storage-access" to permissions.query()? As I mentioned before we shouldn't regress on the goals of #120 so that ought to be tackled at the same time.

storage-access.bs Outdated Show resolved Hide resolved
@johannhof
Copy link
Member Author

How would this not expose "storage-access" to permissions.query()? As I mentioned before we shouldn't regress on the goals of #120 so that ought to be tackled at the same time.

I had hoped to tackle this problem as a separate follow-up but yeah, I can make a PR for permissions to add support for that and then we can add it to this PR.

@johannhof
Copy link
Member Author

@annevk if you're okay with this PR I think it would be good to merge given that the Permissions changes merged.

Thanks!

@annevk annevk mentioned this pull request Dec 13, 2022
Copy link
Collaborator

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mostly seems okay, but there's a couple things that are somewhat questionable which I tried to call out in inline comments.

storage-access.bs Show resolved Hide resolved
storage-access.bs Show resolved Hide resolved
storage-access.bs Outdated Show resolved Hide resolved
storage-access.bs Outdated Show resolved Hide resolved
storage-access.bs Outdated Show resolved Hide resolved
1. [=Queue a global task=] on the [=permission task source=] given |global| to [=/reject=] |p| with a "{{NotAllowedError}}" {{DOMException}}.

ISSUE: [since this is UA-defined, does it make sense to follow-up separately with a user prompt?](https://github.com/privacycg/storage-access/pull/24#discussion_r408784492)
1. If |doc|'s {{Window}} object has [=transient activation=], [=consume user activation=] with it.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be consumed as part of the task in the next step. (Although maybe we should also point to the open issue regarding this.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, let's do this separately from this PR, it's not really related.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you file an issue for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, what I meant was that #141 is moving consumption anyway and that we should do that in that PR. I'll add a note there.

storage-access.bs Outdated Show resolved Hide resolved
storage-access.bs Show resolved Hide resolved
storage-access.bs Outdated Show resolved Hide resolved
storage-access.bs Outdated Show resolved Hide resolved
Copy link
Collaborator

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just like to note on the record that there are still many issues with this Permissions integration, which actually makes it hard to tell if any of them are critical in some manner.

storage-access.bs Outdated Show resolved Hide resolved
@johannhof
Copy link
Member Author

I'd just like to note on the record that there are still many issues with this Permissions integration, which actually makes it hard to tell if any of them are critical in some manner.

Ok, can we list them out for a moment (also to figure out if this PR needs to address any of them)? I'm aware of #144 and #143 (missing WPTs for observing permissions). What else were you thinking of?

@annevk
Copy link
Collaborator

annevk commented Dec 14, 2022

The things I notice are mainly editorial, but given there's many it makes me worried I'm overlooking other things. It's not just this PR though.

  • There's a lot of state changes in "in parallel" sections that should be inside tasks.
  • We're inconsistent on linking terms such as reject/resolve.
  • We sometimes return early but then still use "Otherwise".

I should make time to do a pass at one point.

Looking at the PR again I wonder if we were firmly settled on using origin for the embedded website?

@johannhof
Copy link
Member Author

Looking at the PR again I wonder if we were firmly settled on using origin for the embedded website?

So, I think we said that we could use origin for now but note that user agents have the liberty to auto-grant requests that have existing permissions with same-site embedees. Thinking about this now I think I actually prefer the (site, site) boundary now, as that would allow observers from adjacent same-site iframes to see the permission grant.

Depending on what @bvandersloot-mozilla thinks we could move to (site, site), but maybe we should do this in a follow-up to have the decision recorded explicitly?

@bvandersloot-mozilla
Copy link
Collaborator

I'm okay with setting (site, site) now, given the other discussions on preserving origin boundaries for security.

@johannhof
Copy link
Member Author

Ok, filed #147 for (site, site) and happy to follow-up with that.

@johannhof
Copy link
Member Author

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1401266 for Chromium supporting and WPTesting the Permissions API for storage-access.

@johannhof
Copy link
Member Author

Copy link
Collaborator

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with merging this, modulo follow-ups and renaming of the permission key tuple items.

1. [=Queue a global task=] on the [=permission task source=] given |global| to [=/reject=] |p| with a "{{NotAllowedError}}" {{DOMException}}.

ISSUE: [since this is UA-defined, does it make sense to follow-up separately with a user prompt?](https://github.com/privacycg/storage-access/pull/24#discussion_r408784492)
1. If |doc|'s {{Window}} object has [=transient activation=], [=consume user activation=] with it.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you file an issue for this?

1. Set |status|'s {{PermissionStatus/state}} to |permissionDesc|'s [=permission state=].
1. If |status|'s {{PermissionStatus/state}} is [=permission/denied=], set |status|'s {{PermissionStatus/state}} to [=permission/prompt=].

Note: The "denied" permission state is not revealed to avoid exposing the user's decision to developers. This is done to prevent retaliation against the user and repeated prompting to the detriment of the user experience.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's have a follow-up issue on this as we will to some extent expose denied to websites anyway (but they won't know whether it's persisted).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You were thinking of #149, right?

storage-access.bs Outdated Show resolved Hide resolved
@annevk
Copy link
Collaborator

annevk commented Dec 20, 2022

(I seem to not have sufficient access to unresolve an issue. It's the first of the three threads above.)

@johannhof
Copy link
Member Author

I'll merge this now but will leave the follow-up bits unresolved in case you had something else in mind. :)

@johannhof johannhof merged commit a20c3cc into privacycg:main Jan 5, 2023
johannhof added a commit that referenced this pull request Jan 18, 2023
This is an attempt to migrate to a "per-frame" model, as discussed in #122. This is built on top of #138 as a starting point.

The approach is to define a flag that lives on environment, and is set by document.requestStorageAccess and read by document.hasStorageAccess. In order to propagate storage access during self-initiated, same-origin navigations, we also add a flag to the source snapshot params used during create navigation params by fetching, and conditionally copy the sourceDocument's relevant settings object's flag over to the new environment that will be created. This should let us achieve the benefits of the BrowsingContext approach discussed in #122, without having to add and clear state in BrowsingContext.

Co-authored-by: Johann Hofmann <johannhof@chromium.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants