Add opt-in/opt-out mechanism
bokand opened this issue ยท 23 comments
As shown in #76 and #79, there are ways to leak information across origins due to the initial scroll. They rely on specific circumstances on a page so they aren't general but they are possible so we should consider ways to mitigate them.
I think it'd be useful to add a mechanism for a page to opt out of fragment navigation. i.e. Guarantee it'll load at the initial scroll offset. This can opt-out of element-id and name based fragments as well, which are susceptible to the same issues.
IMHO, it'd also be reasonable for UAs to weigh the trade-offs differently so I'd like to explore adding an auto|on|off switch. By default (auto), the UA can decide whether or not to scroll into view. "On" would be a signal that the page has explicitly deemed it ok to scroll on load and allow all UAs to scroll to a fragment whereas "off" would block all UAs from scrolling into view.
The highlights themselves, if implemented according to spec, aren't detectable by pages so I think this opt-in/out need only apply to the scrolling aspect.
A meta tag seems like a good start to me but I'm open to alternatives. e.g.
<meta name="allow-navigation-scroll" content="auto|block|allow">
An alternative (syntax-wise) we're looking into is using feature-policy. However, I think the semantics would be the same as described above.
Is this implemented in M80?
Im thinking that just adding a redirect in a page header that triggers on :~: might work, but really a whole domain needs to be able to block this.
regardless, adding this to a browser just violated the security of millions of web pages, mostly medical.
Is this implemented in M80?
No, an author-usable opt-out will be in available M82.
Users who want can disable this for now using chrome://flags/#enable-text-fragment-anchor
In the case of a meta tag, whatwg/html#2335 suggests it should rather be:
<meta allow-navigation-scroll="auto|block|allow">
.
We've implemented the opt-out as a force-load-at-top document policy (described in the explainer), and created an origin trial to bridge the gap until document policies ship.
I wanted to add some spec text describing the document policy, but I'm not sure where it would live. AFAICT the document policy spec doesn't define a set of policies. @clelland do we have a way of standardizing available policies that I should add force-load-at-top
to?
FYI: I have added the OT info to the article.
Hi @nickburris
On the page you linked to, it states " To allow websites to opt out of text fragments, we propose adding"
Emphasis my own.
Then you state,
"We've implemented the opt-out "
Can you let me know if this actually works right now, or it will be available in M82?
Thanks a lot!
This works from Chrome 83โ84. The origin trial link to opt-in is https://developers.chrome.com/origintrials/#/view_trial/3253850730775183361.
Thank you for the reply.
Sorry if this sounds rude, but it looks really unattractive on some websites I manage. Is there any way to change the highlight colour that you know of?
While at the first sight it looks like <mark>
, it's not. Here's a quick demo where you can see the difference:
- The first line is user-agent text fragment styling (note how the visited link is black, not purple).
- The second is user-agent
mark
styling (note how the visited link is purple). - The third line is custom
mark
styling.
@nickburris I believe this is unstylable on purpose. Can you confirm?
I opted in to the origin trial and it had the effect of disabling element fragment identifier based navigation at all times, not just on load. Is this intentional?
Thanks
This is indeed intentional. From the origin trial's description:
"The ForceLoadAtTop feature allows sites to indicate that they should be loaded at the top of the page, and not perform any scroll on load, including element fragment identifiers, scroll restoration, and Scroll To Text."
Thanks for the quick reply.
My reading of that passage is that scrolling is only restricted on load.
@nickburris to clarify if it's intended for first load only, or throughout the session.
Sorry, that's a bug in the implementation. I've filed https://crbug.com/1091247
The highlight used is the same one as from find-in-page. AFAICT that cannot be changed.
I'd support adding styling options - it's something we considered early on and agreed would be useful but didn't make the cut for the initial set of features. That said, there's no immediate plans to add it at this time.
The highlight used is the same one as from find-in-page.
I guess it's using the mark
default color internally. Note that this color was just promoted to an own CSS named system color called Mark
alongside MarkText
.
AFAICT the document policy spec doesn't define a set of policies. @clelland do we have a way of standardizing available policies that I should add
force-load-at-top
to?
There's an unofficial registry at https://github.com/w3c/webappsec-feature-policy/blob/master/features.md (to be official per w3c/webappsec-permissions-policy#366).
There's an unofficial registry at https://github.com/w3c/webappsec-feature-policy/blob/master/features.md (to be official per w3c/webappsec-permissions-policy#366).
Thanks for the link! That looks specific to Feature Policy (now Permissions Policy). The Document Policy spec mentions it has an attached registry but I couldn't find it.
I've added related spec text text-fragments in #131 - @clelland can verify if there's a registry we should also add the new document policy to.
Sorry if this sounds rude, but it looks really unattractive on some websites I manage. Is there any way to change the highlight colour that you know of?
FYI: There's discussions afoot on how to do this in w3c/csswg-drafts#5233
The ForceLoadAtTop origin trial ended on the 30th Sept and the "Document-Policy: force-load-at-top" method doesn't appear to have shipped yet.
Is anyone able to extend the origin trail end date?
https://developers.chrome.com/origintrials/#/view_trial/3253850730775183361
The DocumentPolicy is shipping in M86 which is being pushed out in the next few days.
I have seen discussions about allowing authors / sites to opt out, but there seems to be a lack of concern for users to be able to opt out.
Granted, this feels like a more general discussion, but perhaps web standards need to be more user-centric as well?
EDIT: I forgot there's #122