Re: RFC on Fragment Directives

On Thu, Sep 5, 2019 at 1:28 PM Roy T. Fielding <fielding@gbiv.com> wrote:

> On Sep 5, 2019, at 10:09 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> On Sep 5, 2019, at 9:37 AM, David Bokan <bokan@chromium.org> wrote:
>
> Hello all,
>
> I'd like to get some broader feedback on the proposal of a "fragment
> directive". The basic idea is to encode a section of the URL fragment for
> "UA instructions". e.g.
>
> https://example.org#fragment##fragment-directive
> <https://example.org/#fragment%23%23fragment-directive>
>
>
> Absolutely not. Only one # is allowed in a reference because some
> implementations parse
> left-to-right (correctly) and others parse right-to-left (incorrectly),
> and there is absolutely
> nothing you can say or do that will ever make that interoperable in
> practice.
>
> I see, thanks for explaining; I was wondering where the restriction came
from. By chance, is there
a place documenting the history and the reasoning behind these kinds of
decisions? I'd be curious to
learn more.

> In contrast,
>
>  https://example.org/#text=what%20I%20am%looking%20for
>
> will do exactly what you want (it has been specified many times before)
> without changing
> reference parsers or the meaning of identifiers: all you need to do is
> change the default action
> for the browser to take in HTML when there is no matching id for the
> fragment in the target
> context and the fragment's prefix= matches this new semantic.
>
> Unfortunately, |#text=| isn't quite enough. A non-trivial amount of
existing web content uses the
fragment for routing and state management. Adding unexpected content there
can cause these to
break in unpredictable ways. One could argue it's an abuse of the fragment
but, if our proposal does
ship, we don't want URLs that only work in some cases. Worse still, a URL
that works today might
break in the future as the site author makes changes and has no control or
knowledge of incoming
links. So I do think we need a way to make this robust.


> Oh, and I should also mention this creates a new timing attack on secured
> content,
> but I personally think such attacks should be prevented at their source
> (scripts
> permitted to make infinite requests at high speed).
>

Yup, we've considered this and several other attack vectors and think we
have sufficient mitigations
in place to prevent abuse. These are documented in
https://github.com/WICG/ScrollToTextFragment/#security Comments welcome.

Thanks!
David