← Back to context

Comment by andreareina

3 days ago

> Notably, some instances of back button hijacking may originate from the site's ... advertising platform

I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.

47 comments

andreareina

Reply
kvdveer  3 days ago

While i agree, the current JS security model rally doesn't allow for distinguishing origin for JS code. Should that ever change, advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.

  • lmm  3 days ago

    > advertisers will just require that you compile their library into the first party js code, negating any benefit from such a security model.

    It will become harder for advertisers to deny responsibility for ads that violate their stated policies if they have to submit the ads ahead of time. Also site operators will need a certain level of technical competence to do this.

    • miki123211  3 days ago

      More likely, advertisers will need you to insert a "bootloader" that fetches their code and passes it to eval().

      Alternatively, they might require you to set up a subdomain with a cname alias pointing to them (or a common CDN), negating any security benefits of such a practice.

      2 replies →

  • Ma8ee  3 days ago

    The advantage would be that I know beforehand, and have the opportunity to test and, possibly, reject, what the advertiser want me to send to someone’s browser.

zelphirkalt  3 days ago

If it happened browsers started to warn their users about third party JS doing back button history stuff, I have a hunch, that many frontendies would just shrug and tell their visitors: "Oh but for our site it is OK! Just make an exception when your browser asks!" just like we get all kinds of other web BS shoved down our throats. And when the next hyped frontend framework does such some third party integration for "better history functionality" it will become common, leading to skeptics being ridiculed for not trusting sites to handle history.

  • latexr  3 days ago

    Your parent commenter didn’t suggest asking for permission, they suggested not allowing it, period.

friendzis  3 days ago

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

  • least  3 days ago

    The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.

    This feels like a reasonable counter-measure.

    • hnlmorg  3 days ago

      Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful.

      SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.

      17 replies →

    • TeMPOraL  3 days ago

      > It's also a great way to store state so that a user may bookmark or link something directly.

      Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.

      2 replies →

  • optionalsquid  3 days ago

    It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide

    • lxgr  3 days ago

      > clicking back on a slide-show bringing you to the overview page

      That behavior is expected in exactly one case (assuming slides, not the whole presentation, are modeled as a page each): If I navigated to that specific slide from the overview.

      In any other scenario, this behavior amounts to breaking my back button, and I'll probably never visit the site again if I have that choice.

    • arcfour  3 days ago

      Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.

      2 replies →

dspillett  3 days ago

> I feel like anything loaded from a third party domain

Unfortunately this would break some libraries for SPA management that people sometimes load from CDNs (external, or under their control but not obviously & unambiguously 1st-party by hostname) instead of the main app/page location. You could argue that this is bad design IMO, and I'd agree, but it is common design so enforcing such a limit will cause enough uproar to not be worth any browser's hassle.

I do like that they follow up this warning with “We encourage site owners to thoroughly review …” - too many site/app owners moan that they don't have control over what their dependencies do as if loading someone else's code absolves them from responsibility for what it does. Making it clear from the outset that this is the site's problem, not the user's, or something that the UA is doing wrong, or the indexer is judging unfairly, is worth the extra wordage.

ori_b  3 days ago

The history stack shouldn't be controlled by any loaded sites. The browser needs to treat websites as hostile.

RobotToaster  3 days ago

anything loaded from a third party domain shouldn't be allowed to run scripts.

  • pas  3 days ago

    facebook.com does this as a first party site, shit sites trying to squeeze eyeball time from visitors should be put on Google's malware sites list, but apparently those are the best sites nowadays... :/

  • lxgr  3 days ago

    That restriction would both be trivial to circumvent by malicious advertisers and annoying for many legitimate web concepts.

  • bell-cot  3 days ago

    Maybe it's not quite your meaning - but there are browser plugins which allow per-domain blocking of js. I use one, with the default set to deny js.

apatheticonion  3 days ago

There are valid use cases however the issue is rooted in lacking browser APIs.

For instance,

- if you want to do statistics tracking (how many hits your site gets and user journeys)

- You have a widget/iframe system that needs to teardown when the SPA page is navigated away

- etc

The browser does not have a;

   globalThis.history.addEventListener('navigate')

So you must monkey patch the history API. It's impractical from a distribution standpoint to embed this code in the page bundle as it's often managed externally and has its own release schedule.