6 ms·

I implemented the history.pushState API in Firefox many moons ago. Dunno why I didn't add this protection then, other than, it was a simpler time. It was arou

by jlebar 8y ago

I implemented the history.pushState API in Firefox many moons ago. Dunno why I didn't add this protection then, other than, it was a simpler time. It was around then that we added the API for vibrating a phone and we all sort of said "eh, someone could abuse this, but why would they?" (In my defense on that one I was on the side arguing that they would do it specifically for ads and we needed to lock it down.) Anyway, I approve of this change.

aerovistae 8y ago
Can you explain how this change stops abusers while still allowing front-end routing? I’m a bit confused because they seem mutually exclusive to me, or should I say they come together or not at all.
- dfabulich 8y ago
  The commit comment explains, "Entries that are added to the back/forward list without the user's intention are marked to be skipped on subsequent back button invocations." The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page. So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today. But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.
  - Trufa 8y ago
    If I understood you correctly, if someone wanted to highjack my back history they could still do it on a random click? Is it only preventing non user interactive changes to the history or did I understand you wrong?
    - dannyw 8y ago
      You are correct!
  - nikanj 8y ago
    A lot of seedier sites already abuse these mechanisms, by doing nasty things when you click to close a GDPR notification, focus a search box, or similar intention. Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!
    - ht85 8y ago
      Yeah but in that case the malicious website should only be allowed to push a single frame, allowing you to escape by going back twice. This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.
  - wbkang 8y ago
    Is it possible for bad guys to just hijack on onmousemove? Or is that not sufficient?
juhzy 8y ago
Chrome keeps adding new QoL features and people will wonder why everybody uses Chrome. "why would someone abuse this" shows an incredible naivete. Anything that can be abused will be abused.
- dictum 8y ago
  The parent's non-specific "many moons ago" puts the date of such naivete long in the past, when Chrome was also adding a plethora of abusable APIs. There was a kind of "if we don't expand the web platform, native apps from walled-garden app stores will take over" discourse at the time, from all browser implementors — less so from Apple, which could hedge its bets with the App Store.

by jlebar 8y ago

aerovistae 8y ago

Can you explain how this change stops abusers while still allowing front-end routing? I’m a bit confused because they seem mutually exclusive to me, or should I say they come together or not at all.

dfabulich 8y ago
The commit comment explains, "Entries that are added to the back/forward list without the user's intention are marked to be skipped on subsequent back button invocations." The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page. So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today. But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.
- Trufa 8y ago
  If I understood you correctly, if someone wanted to highjack my back history they could still do it on a random click? Is it only preventing non user interactive changes to the history or did I understand you wrong?
  - dannyw 8y ago
    You are correct!
- nikanj 8y ago
  A lot of seedier sites already abuse these mechanisms, by doing nasty things when you click to close a GDPR notification, focus a search box, or similar intention. Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!
  - ht85 8y ago
    Yeah but in that case the malicious website should only be allowed to push a single frame, allowing you to escape by going back twice. This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.
- wbkang 8y ago
  Is it possible for bad guys to just hijack on onmousemove? Or is that not sufficient?

juhzy 8y ago

Chrome keeps adding new QoL features and people will wonder why everybody uses Chrome. "why would someone abuse this" shows an incredible naivete. Anything that can be abused will be abused.

dictum 8y ago
The parent's non-specific "many moons ago" puts the date of such naivete long in the past, when Chrome was also adding a plethora of abusable APIs. There was a kind of "if we don't expand the web platform, native apps from walled-garden app stores will take over" discourse at the time, from all browser implementors — less so from Apple, which could hedge its bets with the App Store.