5 ms·

I despise sites that hijack my back button (No, I don't want to check any of these DENTISTS HATE THIS MOM'S NEW TRICK clickbait articles thanks) so I can't say

by Arrath 4y ago

I despise sites that hijack my back button (No, I don't want to check any of these DENTISTS HATE THIS MOM'S NEW TRICK clickbait articles thanks) so I can't say I'm surprised there are malicious uses for it, but wow!

shadowgovt 4y ago
Unfortunately, the feature itself is vital for making web apps work in anything like a coherent fashion, so it isn't something that can be disabled (though there may be meat on the bones of permission-gating it).
- svnpenn 4y ago
  > web apps work in anything like a coherent fashion Why should I care about that? If you have to break the browser for your app to work, maybe you should be doing a desktop/mobile app instead.
  - shadowgovt 4y ago
    > Why should I care about that? Because they are major use-cases for the web browser framework. I mean, that's a bit like asking why you should care about Web Audio API, or the accessibility layer... The fact you're not using it doesn't mean it isn't vital for those who do.
    - svnpenn 4y ago
      > I mean, that's a bit like asking why you should care about Web Audio API, or the accessibility layer Nope. Those are both useful elements of a browser, that don't even require JavaScript to use. What you're talking about is the monster/frankenstein that is web applications.
      - shadowgovt 4y ago
        How do you use the web audio API without JavaScript?
  - rrwo 4y ago
    If people have to install an app just to us your site, then many of them won't bother. And a significant portion of business users will be in desktop browsers with restricted permissions, so they can't install an app
    - svnpenn 4y ago
      > If people have to install an app just to us your site, then many of them won't bother. If you have some "thing", that is so grotesque that it needs to break a users web browser in order to work correctly, you no longer have a "site". You have a creature, you have an application. Some people would step back at that point and maybe think about the path they are going down. Others would trundle forward, oblivious to the fact that they are hammering a square shaped JavaScript peg into a round hole.
      - rrwo 4y ago
        > If you have some "thing", that is so grotesque that it needs to break a users web browser in order to work correctly, you no longer have a "site". You have a creature, you have an application. There is nothing "grotesque" about writing web applications. That is the entire point of HTML5 + CSS3 + AJAX. With modern Chrome-based browsers and Firefox I can write an application that can be used by Windows, Mac, Linux, BSD, iPhone and Android users who need only visit that site. No installation necessary, and (most importantly) no gatekeeping of apps by Apple, Google or Microsoft.
        svnpenn 4y ago
        > No installation necessary, and (most importantly) no gatekeeping of apps by Apple, Google or Microsoft. This is kind of misleading, as you need to install a browser for it to work. Granted, most computers already have that, but the browser is acting as a "runtime" in this situation. Contrast with other programming languages such as Go or Rust, that produce a single executable that can be dropped in a folder and ran.
      - shadowgovt 4y ago
        In the year 2022, the browser supports full motion video, 3D rendering, dynamic audio synthesis, local key value database storage, a USB access API, and an API for interacting with head mount displays and hand trackers. The simple dynamically-linked page displaying application you are imagining a browser to be is long dead, in much the same way the simple programmable calculating machine that was the personal computer was long dead by the time John Carmack got it to run Doom.
- ysavir 4y ago
  So removing it will simplify web pages? Sounds like a win/win to me.
  - shadowgovt 4y ago
    Not for users of Sheets, Docs, AutoCAD Web, myriad tools companies have built for their intranets, and hundreds of other apps, no. It will make them more complicated.
    - ysavir 4y ago
      I can't see any argument for how removing javascript navigation will make apps more complicated. The desired functionality is literally built into the browser.
      - shadowgovt 4y ago
        Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/exports https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. ... but to get that seamless behavior, it has to inject history entries so that the back button takes the user to a previous logical page, not a previous URL the browser requested. Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open.
- post-it 4y ago
  Just include a back button in the webapp.
  - shadowgovt 4y ago
    Users will not understand why there are two back buttons. That'd be like working around pastebin issues by including a different "copy selection" button.
    - post-it 4y ago
      They'll click the browser back button, get thrown back onto the search/new tab page, they'll click forward to get back to the webapp (which will have saved all of their state), and they'll understand just fine going forward.
      - shadowgovt 4y ago
        First of all: user testing I've observed strongly suggests that no, they won't. You would. The average user doesn't have nearly your level of savvy. Secondly: that's already a bad user experience in contrast to just unifying the behavior behind one button. Why did the user have to discover that a button doesn't work the way they expect? Why are they going to have to remember it doesn't work the right way now? And they'll have to repeat that experience for every web app they use? That's a mess.
- ghayes 4y ago
  I think there are some solutions to this problem. Akin to "after a back navigation, you cannot add to the history state without a user interaction"-- or better "the history stack can never grow beyond the number of user interactions". Basically, I should always be able to navigate back to the referrer in a definitive number of actions.
  - shadowgovt 4y ago
    I think that can still be gamed by forcing nonsense interactions that seem meaningful on the user. This is a really tricky one to solve because the protection that is intended to guard against it ("The user is aware the current domain they are accessing doesn't match the site they expect it to match") isn't working. I think that aspect is the larger problem... IRL, people know if they're standing in a Target vs. a used car dealership, but they rarely know if they're at target.com instead of target.used-car-dealership.com. It's possible the browser's framing should be changed to make it harder to be confused about that (color-and-texture-hash the TLD and apply it to the URL bar as a background, so there's a major visual difference if I'm on the wrong site?).
- tgsovlerkhgsel 4y ago
  It would be pretty simple to open a web page, do a few user interactions that shouldn't trigger this behavior, and then penalize or deindex web sites that hijack the back button. Add manual penalties for the ones that slip through the automated testing. Once it becomes known that doing this means saying bye-bye to your traffic, sites will stop doing it.
veddan 4y ago
We actually had an accidental back button hijack at a place I used to work at. It was an SPA, where if you navigated to / it would check if you were logged in. If so, you would be redirected (client-side) to /home, otherwise you were sent to /login. This was done with pushState() instead of replaceState(), so going back from /home would take you to / which would immediately see that you were logged in and send you back to /home.
deleted 4y ago
[deleted]

by Arrath 4y ago

shadowgovt 4y ago

Unfortunately, the feature itself is vital for making web apps work in anything like a coherent fashion, so it isn't something that can be disabled (though there may be meat on the bones of permission-gating it).

svnpenn 4y ago
> web apps work in anything like a coherent fashion Why should I care about that? If you have to break the browser for your app to work, maybe you should be doing a desktop/mobile app instead.
- shadowgovt 4y ago
  > Why should I care about that? Because they are major use-cases for the web browser framework. I mean, that's a bit like asking why you should care about Web Audio API, or the accessibility layer... The fact you're not using it doesn't mean it isn't vital for those who do.
  - svnpenn 4y ago
    > I mean, that's a bit like asking why you should care about Web Audio API, or the accessibility layer Nope. Those are both useful elements of a browser, that don't even require JavaScript to use. What you're talking about is the monster/frankenstein that is web applications.
    - shadowgovt 4y ago
      How do you use the web audio API without JavaScript?
- rrwo 4y ago
  If people have to install an app just to us your site, then many of them won't bother. And a significant portion of business users will be in desktop browsers with restricted permissions, so they can't install an app
  - svnpenn 4y ago
    > If people have to install an app just to us your site, then many of them won't bother. If you have some "thing", that is so grotesque that it needs to break a users web browser in order to work correctly, you no longer have a "site". You have a creature, you have an application. Some people would step back at that point and maybe think about the path they are going down. Others would trundle forward, oblivious to the fact that they are hammering a square shaped JavaScript peg into a round hole.
    - rrwo 4y ago
      > If you have some "thing", that is so grotesque that it needs to break a users web browser in order to work correctly, you no longer have a "site". You have a creature, you have an application. There is nothing "grotesque" about writing web applications. That is the entire point of HTML5 + CSS3 + AJAX. With modern Chrome-based browsers and Firefox I can write an application that can be used by Windows, Mac, Linux, BSD, iPhone and Android users who need only visit that site. No installation necessary, and (most importantly) no gatekeeping of apps by Apple, Google or Microsoft.
      - svnpenn 4y ago
        > No installation necessary, and (most importantly) no gatekeeping of apps by Apple, Google or Microsoft. This is kind of misleading, as you need to install a browser for it to work. Granted, most computers already have that, but the browser is acting as a "runtime" in this situation. Contrast with other programming languages such as Go or Rust, that produce a single executable that can be dropped in a folder and ran.
    - shadowgovt 4y ago
      In the year 2022, the browser supports full motion video, 3D rendering, dynamic audio synthesis, local key value database storage, a USB access API, and an API for interacting with head mount displays and hand trackers. The simple dynamically-linked page displaying application you are imagining a browser to be is long dead, in much the same way the simple programmable calculating machine that was the personal computer was long dead by the time John Carmack got it to run Doom.
ysavir 4y ago
So removing it will simplify web pages? Sounds like a win/win to me.
- shadowgovt 4y ago
  Not for users of Sheets, Docs, AutoCAD Web, myriad tools companies have built for their intranets, and hundreds of other apps, no. It will make them more complicated.
  - ysavir 4y ago
    I can't see any argument for how removing javascript navigation will make apps more complicated. The desired functionality is literally built into the browser.
    - shadowgovt 4y ago
      Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/exports https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. ... but to get that seamless behavior, it has to inject history entries so that the back button takes the user to a previous logical page, not a previous URL the browser requested. Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open.
post-it 4y ago
Just include a back button in the webapp.
- shadowgovt 4y ago
  Users will not understand why there are two back buttons. That'd be like working around pastebin issues by including a different "copy selection" button.
  - post-it 4y ago
    They'll click the browser back button, get thrown back onto the search/new tab page, they'll click forward to get back to the webapp (which will have saved all of their state), and they'll understand just fine going forward.
    - shadowgovt 4y ago
      First of all: user testing I've observed strongly suggests that no, they won't. You would. The average user doesn't have nearly your level of savvy. Secondly: that's already a bad user experience in contrast to just unifying the behavior behind one button. Why did the user have to discover that a button doesn't work the way they expect? Why are they going to have to remember it doesn't work the right way now? And they'll have to repeat that experience for every web app they use? That's a mess.
ghayes 4y ago
I think there are some solutions to this problem. Akin to "after a back navigation, you cannot add to the history state without a user interaction"-- or better "the history stack can never grow beyond the number of user interactions". Basically, I should always be able to navigate back to the referrer in a definitive number of actions.
- shadowgovt 4y ago
  I think that can still be gamed by forcing nonsense interactions that seem meaningful on the user. This is a really tricky one to solve because the protection that is intended to guard against it ("The user is aware the current domain they are accessing doesn't match the site they expect it to match") isn't working. I think that aspect is the larger problem... IRL, people know if they're standing in a Target vs. a used car dealership, but they rarely know if they're at target.com instead of target.used-car-dealership.com. It's possible the browser's framing should be changed to make it harder to be confused about that (color-and-texture-hash the TLD and apply it to the URL bar as a background, so there's a major visual difference if I'm on the wrong site?).
tgsovlerkhgsel 4y ago
It would be pretty simple to open a web page, do a few user interactions that shouldn't trigger this behavior, and then penalize or deindex web sites that hijack the back button. Add manual penalties for the ones that slip through the automated testing. Once it becomes known that doing this means saying bye-bye to your traffic, sites will stop doing it.

veddan 4y ago

We actually had an accidental back button hijack at a place I used to work at. It was an SPA, where if you navigated to / it would check if you were logged in. If so, you would be redirected (client-side) to /home, otherwise you were sent to /login. This was done with pushState() instead of replaceState(), so going back from /home would take you to / which would immediately see that you were logged in and send you back to /home.

deleted 4y ago

[deleted]