Initial spec draft #120

johannhof · 2022-12-08T14:39:04Z

This is an initial spec draft for how user agents should integrate with FPS (as a companion document to the submission guidelines that specify submission format and server-side checks). It's largely complete but might be lacking some polish here and there, and I still need to add inline issues for some things @jyasskin identified in a quick review offline.

Preview | Diff

johannhof · 2022-12-12T16:37:49Z

@krgovind this should be ready for a review now :)

krgovind · 2022-12-19T15:27:04Z

spec.bs

+
+The FPS list is a [=UTF-8=] encoded file containing contents parseable as a JSON object, conforming to the [[JSON-SCHEMA index]] described in the [[SUBMISSION-GUIDELINES]].
+
+Note: Conformance to the schema is validated at submission time. Hence, it is not required for the user agent to validate conformance again on the client. The algorithms in this specification describe how user agents should parse the FPS list, and when a particular set should be considered valid from the client’s perspective.


I wonder if it does make sense for the user agent to re-validate the registrable domain check (See https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md#set-level-technical-validation), since that depends on the version of the PSL being used by the UA?

cc @cfredric since we've had this conversation in the past.

I think the spec doesn't need to require the UA to re-validate the list, but I think it should leave wiggle room for the UA to do so and prune out domains/sets that no longer pass for some reason or other.

(Seems like some revalidation of sites is already implied in the "if |json| is not an [=ordered map=], ..." clause? But that sentence says the UA must throw out the entire list, not just a single set/domain in case of any invalid input.)

+1 on giving UAs wiggle room.

Ok, yeah, that's true. Let me add something about PSL versions.

Or, actually, in the interest of getting this merged that task seems self-contained enough to be moved into a follow-up issue, if that's okay with you @cfredric @krgovind ?

Filed #125 and will add an inline issue. Thanks!

krgovind · 2022-12-19T16:00:09Z

spec.bs

+2. If |json| is a parsing exception, or if |json| is not an [=ordered map=], or if |json|[“sets”] does not exist, return and optionally retry fetching the list, or perform other error recovery tasks.
+3. For each |entry| of |json|:
+    1. Let |set| be a [=first-party set=].
+    2. If |entry|[“primary”] does not exist, continue.


[Ignore me if this is a normative way to specifying JSON parsing] Does there need to be an if-condition here? Almost seems like this should be an assertion/DCHECK?

Right, I actually discussed this with @cfredric before and I think Chrome currently fails the entire list on an invalid member (so diverges from this spec), but I said it might be preferable to just skip invalid entries. We should align either spec or implementation. I could file a follow-up issue for discussing that?

Filed #126 and will add an inline issue.

krgovind · 2022-12-19T16:01:20Z

spec.bs

+    1. Let |set| be a [=first-party set=].
+    2. If |entry|[“primary”] does not exist, continue.
+    3. Set |set|’s [=first-party set/primary=] to |entry|[“primary”].
+    4. Let |ccTLDs| be the result of [=parse an equivalence map|parsing an equivalence map=] from |entry|[“ccTLDs”]. If |ccTLDs| is failure, continue.


If |ccTLDs| is failure

Should this be s/failure/empty/? Or does this represent a parsing failure?

Yeah, this seems to be the way to represent a parsing failure, not extremely readable, I admit. It's a pattern I ~~stole~~ re-used from other specs, thus I'm inclined to keep it unless you feel strongly about this :)

krgovind · 2022-12-19T21:40:12Z

spec.bs

+    2. [=Clear cookies for origin=].
+    3. [=Clear DOM-accessible storage for origin=].
+    4. Let |descriptor| be a newly-created {{PermissionDescriptor}} with {{PermissionDescriptor/name}} initialized to “storage-access”.
+    5. Remove all permission store entries for |descriptor|, where key[0] is |site| or key[1] is |origin|.


I'm not sure how closely aligned this needs to be with practical implementation details; but I believe with recent spec discussions on SAA moving to a per-frame model, the storage-access permission doesn't persist across browser restarts (except where browser features such as session-restores occur, but I'm not sure if that feature is specified), and so this type of clearing may not be required?

cc @shuranhuang

Browsers do persist the storage-access permission across restarts; IIRC Safari's permission lasts 30 days of usage time. (Maybe session-restore gets involved there such that it's actually considered a single 30-day-long session, but I don't think we can assume that.)

However, as long as the browser's behavior is indistinguishable from what it would be if the browser implemented the spec exactly, it's fine. So a browser is free to implement this part of the spec as "delete the matching permission store entries", or as "don't bother to persist these permission store entries", since they both give the same observable behavior.

I agree with what Chris said. The permissions should be listed out as a clearing item in the spec, so that the actual implementation from different browsers does not matter as long as the behavior is indistinguishable. To add more implementation detail, right now Chrome and Edge both persist the SAA (implicit) permissions, but when a new user session is created during browser restarts, Edge can continue the life of those permissions if the restore feature is enabled, whereas Chrome removes those permissions (autogranted by FPS) regardless the restore feature.

Thanks @cfredric and @shuranhuang . Okay, I'm not sure what's recommended for specs in such situations; but I'll leave it to @johannhof 's judgement.

I think it's important to list this even if some implementations may have different lifetimes on the permission, to avoid leakage :)

cfredric · 2022-12-19T21:49:01Z

spec.bs

+    2. If |entry|[“primary”] does not exist, continue.
+    3. Set |set|’s [=first-party set/primary=] to |entry|[“primary”].
+    4. Let |ccTLDs| be the result of [=parse an equivalence map|parsing an equivalence map=] from |entry|[“ccTLDs”]. If |ccTLDs| is failure, continue.
+    5. Set set’s ccTLDs to |ccTLDs|.


Suggested change

5. Set set’s ccTLDs to |ccTLDs|.

5. Set |set|’s ccTLDs to |ccTLDs|.

cfredric · 2022-12-19T21:51:10Z

spec.bs

+
+The FPS list is a [=UTF-8=] encoded file containing contents parseable as a JSON object, conforming to the [[JSON-SCHEMA index]] described in the [[SUBMISSION-GUIDELINES]].
+
+Note: Conformance to the schema is validated at submission time. Hence, it is not required for the user agent to validate conformance again on the client. The algorithms in this specification describe how user agents should parse the FPS list, and when a particular set should be considered valid from the client’s perspective.


I think the spec doesn't need to require the UA to re-validate the list, but I think it should leave wiggle room for the UA to do so and prune out domains/sets that no longer pass for some reason or other.

(Seems like some revalidation of sites is already implied in the "if |json| is not an [=ordered map=], ..." clause? But that sentence says the UA must throw out the entire list, not just a single set/domain in case of any invalid input.)

cfredric · 2022-12-19T22:03:26Z

spec.bs

+    2. [=Clear cookies for origin=].
+    3. [=Clear DOM-accessible storage for origin=].
+    4. Let |descriptor| be a newly-created {{PermissionDescriptor}} with {{PermissionDescriptor/name}} initialized to “storage-access”.
+    5. Remove all permission store entries for |descriptor|, where key[0] is |site| or key[1] is |origin|.


Browsers do persist the storage-access permission across restarts; IIRC Safari's permission lasts 30 days of usage time. (Maybe session-restore gets involved there such that it's actually considered a single 30-day-long session, but I don't think we can assume that.)

However, as long as the browser's behavior is indistinguishable from what it would be if the browser implemented the spec exactly, it's fine. So a browser is free to implement this part of the spec as "delete the matching permission store entries", or as "don't bother to persist these permission store entries", since they both give the same observable behavior.

johannhof · 2023-01-05T14:40:28Z

Thanks for the comments, I'll merge this with some follow-ups deferred to issues :)

SHA: e9b53c8 Reason: push, by johannhof Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Initial spec draft

2e00088

johannhof requested a review from krgovind December 8, 2022 14:39

This was referenced Dec 12, 2022

Editorial: Consider renaming "equivalence map" #123

Open

Editorial: Recommendation for list update interval #122

Open

Editorial: Needs more detail on how FPS changes are computed #124

Open

Add more biblio refs, inline issues

a242958

cfredric mentioned this pull request Dec 16, 2022

Related Website Sets (formerly First-Party Sets) w3ctag/design-reviews#342

Closed

5 tasks

krgovind reviewed Dec 19, 2022

View reviewed changes

cfredric reviewed Dec 19, 2022

View reviewed changes

nits

6c3f27a

johannhof mentioned this pull request Jan 5, 2023

Describe client-side validation to prevent PSL mismatch #125

Open

Add follow-up issues

151d34e

johannhof merged commit e9b53c8 into WICG:main Jan 5, 2023

johannhof deleted the initial-spec branch January 5, 2023 14:40

github-actions bot added a commit that referenced this pull request Jan 5, 2023

Initial spec draft (#120)

7d120f8

SHA: e9b53c8 Reason: push, by johannhof Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

github-actions bot added a commit that referenced this pull request Jan 9, 2023

Initial spec draft (#120)

baa939f

SHA: e9b53c8 Reason: push, by johannhof Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial spec draft #120

Initial spec draft #120

johannhof commented Dec 8, 2022 •

edited by pr-preview bot

Loading

johannhof commented Dec 12, 2022

krgovind Dec 19, 2022

cfredric Dec 19, 2022

krgovind Dec 20, 2022

johannhof Jan 5, 2023

johannhof Jan 5, 2023

johannhof Jan 5, 2023

krgovind Dec 19, 2022

johannhof Jan 5, 2023

johannhof Jan 5, 2023

krgovind Dec 19, 2022

johannhof Jan 5, 2023

krgovind Dec 19, 2022

cfredric Dec 19, 2022

shuranhuang Dec 20, 2022

krgovind Dec 20, 2022

johannhof Jan 5, 2023

cfredric Dec 19, 2022

cfredric Dec 19, 2022

cfredric Dec 19, 2022

johannhof commented Jan 5, 2023


		The FPS list is a [=UTF-8=] encoded file containing contents parseable as a JSON object, conforming to the [[JSON-SCHEMA index]] described in the [[SUBMISSION-GUIDELINES]].

		Note: Conformance to the schema is validated at submission time. Hence, it is not required for the user agent to validate conformance again on the client. The algorithms in this specification describe how user agents should parse the FPS list, and when a particular set should be considered valid from the client’s perspective.

	5. Set set’s ccTLDs to \|ccTLDs\|.
	5. Set \|set\|’s ccTLDs to \|ccTLDs\|.

Initial spec draft #120

Initial spec draft #120

Conversation

johannhof commented Dec 8, 2022 • edited by pr-preview bot Loading

johannhof commented Dec 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johannhof commented Jan 5, 2023

johannhof commented Dec 8, 2022 •

edited by pr-preview bot

Loading