Stealing the users back button with the History API (2013) | Hacker News Reader

Stealing the users back button with the History API (2013)

ryanseddon.com

31 pointslongrod19 comments

History API? Modifying user history should require an exploit, not be offered voluntarily by the browser!

I've never liked calling it "History API" it's more focused on modifying what the back button will do.

It exists primarily to support SPAs that have hard links for different specific resource views but never actually navigate the user off the single page - the History API allows these sites to drop some breadcumbs so that users can return to different visual states they observed on their screen while never actually navigating....

That all said - I think there are much better ways to accomplish this using, I believe (it's been a bit) location.Url updates that cause micro-reloads... however if your webapp is a 300 pound gorilla this approach is significantly less appealing due to the obvious breaks in user flow.

Man I really hate SPAs. Unless it's something like a drawing app or whatever where the back button doesn't even make sense they're usually awful.

I think the biggest problem with SPAs is trying to put them in a web browser. So many compromises we make just to use a technology that wasn't designed with the idea that you'd build an interactive app on top of it.

I don't know the solution, but I wish I could get a normal web, and then have a dedicated generic app sandbox that I can point at a particular app on the 'net.

Yep... most of the tracking and privacy issues exist, because browser expost too much apis to websites, many of those things not really needed for sites to work properly.

Hate to tell you, some form of this has existed for over 20 years. Once there was .back(), it’s been possible to pollute and corrupt browsing history. Even before the hashchange event, it was just a matter of polling the current state to detect history changes. The current API was designed to limit obvious abuse, but obvious abuse was already rampant and already too late to deprecate.

you can only use your own website history...definitely not an issue imo

Can you delete items from it? Even if it's the same domain, that's not something I want a website doing.

Yes. Keep in mind this relates to the back/forward buttons, not your personal history of all visited websites.

For the interested, the successor to the History API is the Navigation API: https://developer.chrome.com/docs/web-platform/navigation-ap...

I think a simple website redirect middleware can do this and much more reliably. If a site is being shady there is hardly a way to stop it.

Step 1: Redirect middleware checks for a cookie say 'A'

Step 2: If no cookie, set cookie and redirect to main content.

Step 3: User presses back button, comes to redirect middleware which sees cookie 'A' and this time it redirects to another shady website.

Didn't work for me though on Chrome or Slimjet. Worked in Firefox!

On Chrome based browsers, I see this error -

  [Report Only] Refused to load the script 'https://ryanseddon.com/dist/app.bundle.js' because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-MdC6fOvaO+dJENLQhOoRht9sHSJ++GoMxjtC5lOpUww=' 'strict-dynamic' https: 'unsafe-inline' 'report-sample'". 'strict-dynamic' is present, so host-based whitelisting is disabled. Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

CSP can be set through HTTP header, so a site with an explicit CSP configuration might allow this.

Huh...so you can add a third-party domain to the history? That seems like a security flaw. I would have imagined you could only add history for the current domain.

They can’t. Here’s the flow.

1. User goes to example.com.

2. The site immediately replaces the history state with example.com#history.

3. The site pushes a new history state example.com

At this point your history looks like

    …
    google.com
    example.com#history
    example.com <— you are here

4. The user clicks their back button and you’re taken to example.com#history

5. The JS sees the hash and does a location.replace (i.e. navigate to) to some unrelated URL.

I despise websites that capture my back button.

I don’t know why people do this because this is what makes people avoid your website completely. Fool me once…never again

Never understood why sites do that. Do they expect me to stick around and click some ads? I usually just close the tab and move on

Most sites (IME) do it by accident. The API as designed is a footgun, so much so that there’s an active proposal which would basically replace it. (I can’t speak to how much better the replacement might be.)

Obviously it can be used intentionally to hijack your session history, but it’s also surprisingly easy to do by mistake unless your state management is effectively designed for concurrency (which the API isn’t, but it encourages the same kinds of bad patterns).

Reply on news.ycombinator.com