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

Fragment Directives API #40

Closed
eligrey opened this issue Oct 2, 2023 · 8 comments
Closed

Fragment Directives API #40

eligrey opened this issue Oct 2, 2023 · 8 comments

Comments

@eligrey
Copy link

eligrey commented Oct 2, 2023

I am proposing a specification for adoption by the PrivacyCG that aims to codify a way to read and write fragment directives from all supported location interfaces while accounting for the privacy concerns introduced by accessing potentially privacy-sensitive directives (e.g. text).

My proposed spec: https://github.com/eligrey/fragment-directives

Related issue in scroll-to-text spec repository: WICG/scroll-to-text-fragment#128

@jyasskin jyasskin added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 2, 2023
@eligrey
Copy link
Author

eligrey commented Oct 2, 2023

@zcorpan left some feedback here about permission prompts and determining what directives should be considered sensitive: eligrey/fragment-directives#1

@eligrey
Copy link
Author

eligrey commented Oct 2, 2023

I intentionally chose to re-use URLSearchParams in this spec for implementation simplicity, but I can introduce URLFragmentDirectives if there is interest for it. If we re-use URLSearchParams there will be a slight API ergonomics concern with the leading ? in string representation. That could be easily special-cased to be ignored.

Aside from the obvious string representation difference, a URLFragmentDirectives constructor could also parse out fragment directives from a full hash fragment.

@eligrey
Copy link
Author

eligrey commented Oct 3, 2023

Full disclosure: I work for Transcend, and we currently use performance.getEntries() as part of our implementation of accessing custom fragment directives for our consent manager SDK. We use the compat behavior to help ensure that our URL-based configuration options won't interfere with routing on customer sites.

@martinthomson
Copy link

@eligrey can you explain why you think Privacy CG is the right forum to develop this proposal? From what I can see, this is a straightforward extension to the text fragment work that is being developed in WICG. I would suggest that you seek to engage in that forum, probably with the proponents of that work.

@jyasskin you asked for time on our agenda for this. Can you give me a little more context? If we are going to set aside time, then we'd need to know who would be leading that work and what you would hope to achieve. Is it simply a request to discuss adoption as Eli requests?

@jyasskin
Copy link

Eli asked someone to agenda+ it in https://w3cping.slack.com/archives/CSVA13FJB/p1696271146530939, so I did.

@erik-anderson erik-anderson removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Nov 2, 2023
@erik-anderson
Copy link
Member

This was discussed on our October 12th call: https://github.com/privacycg/meetings/blob/main/2023/telcons/10-12-minutes.md. While it wasn't captured in the minutes, I think something along the lines of Martin's feedback about taking this proposal to the WICG was given.

@eligrey any objections to closing out this issue here? Feel free to add a pointer to the new location.

@eligrey
Copy link
Author

eligrey commented Nov 2, 2023

Yeah, I'm fine with closing this out. I'll post a new link here once I've moved the proposal over to WICG.

@eligrey eligrey closed this as completed Nov 2, 2023
@eligrey
Copy link
Author

eligrey commented May 22, 2024

This has been re-proposed under WICG: WICG/proposals#154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants