6 ms·

> 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

> 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.

kvdveer 6mo 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 6mo 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 6mo 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.
    - thepasch 6mo ago
      > More likely, advertisers will need you to insert a “bootloader” that fetches their code and passes it to eval(). Sounds like legal precedent waiting to be set. “Run our code so that it looks like your code, acts like your code, and has all the same access as your code” seems like it should be a slam dunk if said code ends up doing a Very Bad Thing to your visitors. But of course that’s assuming common sense, and the law’s relationship with that isn’t always particularly apparent.
      - ImPostingOnHN 6mo ago
        There is already plenty of precedent for real-time-served ads which are annoying, or malicious, or install malware; or outright exploit vulnerabilities in the browser.
- Ma8ee 6mo 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.
apatheticonion 6mo 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.
- friendzis 6mo ago
  > - if you want to do statistics tracking (how many hits your site gets and user journeys) You can do all of that server-side and much more reliably at that. The only reason to do any of this tracking client-side is advertisers trusting fake number go up more than sales numbers.
- jampekka 6mo ago
  Browsers now have window.navigation.addEventListener("navigate") that allows just this. https://developer.mozilla.org/en-US/docs/Web/API/Navigation/navigate_event https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...
  - apatheticonion 6mo ago
    Huh! Well I'll be
friendzis 6mo ago
Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.
- optionalsquid 6mo 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
  - arcfour 6mo 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.
    - optionalsquid 6mo ago
      That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
      - arcfour 6mo ago
        Sure, I should have said geolocation element, since the original API still exists and is used: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/geolocation https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - lxgr 6mo 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.
RobotToaster 6mo ago
anything loaded from a third party domain shouldn't be allowed to run scripts.
- pas 6mo 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... :/
- bell-cot 6mo 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.
- lxgr 6mo ago
  That restriction would both be trivial to circumvent by malicious advertisers and annoying for many legitimate web concepts.
zelphirkalt 6mo 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 6mo ago
  Your parent commenter didn’t suggest asking for permission, they suggested not allowing it, period.
dspillett 6mo 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.
ekjhgkejhgk 6mo ago
GOOGLE is an advertising platform.
ori_b 6mo ago
The history stack shouldn't be controlled by any loaded sites. The browser needs to treat websites as hostile.

kvdveer 6mo 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 6mo 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 6mo 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.
  - thepasch 6mo ago
    > More likely, advertisers will need you to insert a “bootloader” that fetches their code and passes it to eval(). Sounds like legal precedent waiting to be set. “Run our code so that it looks like your code, acts like your code, and has all the same access as your code” seems like it should be a slam dunk if said code ends up doing a Very Bad Thing to your visitors. But of course that’s assuming common sense, and the law’s relationship with that isn’t always particularly apparent.
    - ImPostingOnHN 6mo ago
      There is already plenty of precedent for real-time-served ads which are annoying, or malicious, or install malware; or outright exploit vulnerabilities in the browser.
Ma8ee 6mo 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.

apatheticonion 6mo 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.

friendzis 6mo ago
> - if you want to do statistics tracking (how many hits your site gets and user journeys) You can do all of that server-side and much more reliably at that. The only reason to do any of this tracking client-side is advertisers trusting fake number go up more than sales numbers.
jampekka 6mo ago
Browsers now have window.navigation.addEventListener("navigate") that allows just this. https://developer.mozilla.org/en-US/docs/Web/API/Navigation/navigate_event https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...
- apatheticonion 6mo ago
  Huh! Well I'll be

friendzis 6mo ago

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

optionalsquid 6mo 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
- arcfour 6mo 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.
  - optionalsquid 6mo ago
    That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
    - arcfour 6mo ago
      Sure, I should have said geolocation element, since the original API still exists and is used: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/geolocation https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- lxgr 6mo 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.

RobotToaster 6mo ago

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

pas 6mo 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... :/
bell-cot 6mo 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.
lxgr 6mo ago
That restriction would both be trivial to circumvent by malicious advertisers and annoying for many legitimate web concepts.

zelphirkalt 6mo 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 6mo ago
Your parent commenter didn’t suggest asking for permission, they suggested not allowing it, period.

dspillett 6mo 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.

ekjhgkejhgk 6mo ago

GOOGLE is an advertising platform.

ori_b 6mo ago

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