Re: "Fragment" request header

On Thu, Jun 6, 2019 at 10:17 PM Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> Hello Rob,
>
> An issue somewhat implicit in what Daniel wrote is that your header has
> privacy implications. Until now, jumping around on a single page, or
> jumping to a specific location in a page, is private, but that would
> change with the new header.
>

This claim of privacy is incorrect, afaik. Any app with a "feed" or
"timeline" eventually writes code to track how long you look at things (via
JavaScript).

These are just the most likely sites to track you in this way, but any site
could do it, since the fragment is available to JS and can be transmitted
via XHR etc.


> Also, Video and other continuous media are one of the places where
> sending fragment information to the server is most beneficial. This led
> to https://www.w3.org/TR/media-frags/. You can probably find reasons why
> such a header hasn't been proposed until now, and alternatives to your
> proposal, in that document, or in the discussion that lead to that
> document.
>

I have not read that, and I will check it out. Thank you for the link.

thanks,
Rob


>
> Regards,   Martin.
>
>
>
> On 2019/06/07 09:20, Rob Sayre wrote:
> > Reflecting on these objections,
> >
> > I think I'll just write up an Internet-Draft. It's simple, and would
> avoid
> > prolonged email threads, by using precise language.
> >
> > thanks,
> > Rob
> >
> >
> > On Thu, Jun 6, 2019 at 4:52 PM Rob Sayre <sayrer@gmail.com> wrote:
> >
> >> Hi Daniel, (I would say "dveditz" but I'm not sure what's appropriate
> here)
> >>
> >> It seems like any site "coded with the assumption that the fragment is a
> >> safe place to stuff data" would ignore the new header, right? The
> proposal
> >> does not place the fragment in the HTTP request line.
> >>
> >> The fragment header would not trigger any change in existing sites, but
> >> new servers aware of the header might vary their responses. So I think
> >> sending the fragment in a request header would be backward compatible.
> >>
> >> A concrete example is this blog post:
> >> https://avc.com/2011/04/finding-and-buying-a-domain-name/
> >>
> >> The link for "Eric Friedman" is currently broken, but Twitter might be
> >> able to efficiently vary their response if they knew the fragment
> >> identifier at request time.
> >>
> >> thanks,
> >> Rob
> >>
> >> On Thu, Jun 6, 2019 at 4:41 PM Daniel Veditz <dveditz@mozilla.com>
> wrote:
> >>
> >>> Hi Rob,
> >>>
> >>> A lot of sites have been coded with the assumption that the fragment
> is a
> >>> safe place to stuff data that explicitly won't be sent to the server
> (in
> >>> fact that's why AJAX sites started using #! -- seems odd that now you
> want
> >>> to send it). Before postMessage() it was even used as a message-passing
> >>> mechanism. Changing this is not backwards compatible in the big
> picture.
> >>> Maybe as an opt-in, but if a site wanted to opt-in why wouldn't they
> just
> >>> change their URLs to put the bit they want to share in front of the #
> >>> instead of after?
> >>>
> >>> When do you propose the fragment be sent? Would it start triggering
> loads
> >>> on each transition in an site that uses "#!" ? Or are you proposing to
> only
> >>> send it when current algorithms would trigger a load?
> >>>
> >>> -Dan Veditz
> >>>
> >>>
> >
>