Re: "Fragment" request header

On Thu, Jun 6, 2019 at 10:29 PM Kevin Kandlbinder <
kevinkandlbinder@gmail.com> wrote:

> Hi Rob,
>
> I see a big problem in the security of the sites which use it as a way to
> store crypto data. They assume fragments to not be sent to the server, so
> no third party can intercept the request and steal the encryption key.
>

That seems like a problem, since any JS injected into the page can read the
fragment (ad trackers, browser extensions, etc).

thanks,
Rob


>
> I think even if it was opt-in many of these sites would not be happy about
> that as it would significantly reduce the security as it would help a third
> party transparently stealing the fragment. Rouge actors would not even have
> to inject JavaScript.
> How do you think that could be fixed?
>
> Kind regards,
> Kevin
>
> Rob Sayre <sayrer@gmail.com> schrieb am Fr., 7. Juni 2019, 02:20:
>
>> 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
>>>>
>>>>