1681447 - window.location.replace is an anti-feature

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P5)

Description

[Andrew Cady]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Mozilla documentation says:

The replace() method of the Location interface replaces the current resource with the one at the provided URL. The difference from the assign() method is that after using replace() the current page will not be saved in session History, meaning the user won't be able to use the back button to navigate to it.

This gives web sites the power to erase one entry of URL history, losing information that may be useful to the user. The user has no way to preserve this information.

For example, WashingtonPost.com uses window.location.replace to redirect a logged-out user away from an article and to an advertisement to subscribe. If the user opens a Post article in a new tab from an article they are reading, and then navigates to that tab, the URL which they originally selected is lost information.

Firefox then requires the user to navigate back to the linking page (remembering which page that is), and then to remember which link(s) to re-click.

Yet the very reason the user opened that tab was to instruct the computer to remember that URL for them!

Why does FireFox respect WaPo's javascript's user-hostile decision to erase the user's navigation history?

I guess it's a holdover from the 1990s when web sites could just loop alert() and you'd have to reboot the whole machine to escape. Wrong mentality. The browser shouldn't assume the user trusts the web server to delete any of the user's navigation history.

Comment 1

[Daniel Bodea [:danibodea]]

I'm not sure I understand your issue here.

1. Can you write a set of steps I could take to reproduce your issue on my system?
2. Please check whether it reproduces in safe-mode? https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems
3. Which OS and Browser versions are you using to reproduce this issue?

P.S. Make sure you have your browser updated to the latest version when you retry to reproduce it.
Thanks!

Comment 2

[:Gijs (he/him)]

This is a technical report, it seems clear enough without answering the questions from comment #1, so I'm going to clear needinfo.

Comment 3

[:Gijs (he/him)]

(In reply to Andrew Cady from comment #0)

Why does FireFox respect WaPo's javascript's user-hostile decision to erase the user's navigation history?

As usual, it is difficult to infer intent or morality from technical API use. Just as the WaPo use is user-hostile, it's pretty easy to imagine benign / user-friendly uses (e.g. "click this to create a shortened link", or eliding 3 bits of a successful login flow so there's only the history entry for the actual article viewed, or ...).

Reporter, do you have any idea how we could determine whether the website's use of the API is user-hostile?

Johann/Anne, do you know if there's been any standards conversation around this? It feels a little like the history API usage that we're considering blocking without user interaction, for instance - perhaps location.replace should be "downgraded" to location.href = "..." (and history.replaceState to history.pushState) in the same circumstances, or something?

Comment 4

[Johann Hofmann [:johannh]]

So the user-interaction-for-session-history piece is tracking in bug 1645211, but the goal behind that is to avoid spammy/duplicate session history entries, which is kind of the reverse of what you're seeing here. If we want to use user interaction as our metric to avoid this "user hostile" behavior, I'm not sure it would be very effective. You're interacting with the WaPo website, but you still don't want them to overwrite your session history. It seems de-coupled from interaction.

Overall, yes, it's probably not impossible to downgrade replace actions to push a new SH entry instead, but it's also a significant amount of work for something where it's not clear whether it is actually a big problem on the web right now and where we have no idea how it could be exposed to users (probably not by default since that would be equivalent to unshipping replace).

I'm not aware of a standards discussion but Anne might be :)

IMO this is a P5 at best unless we get further evidence of a wide net of abuse of this API.

Comment 5

[Anne (:annevk)]

There has been no discussion that I'm aware of. To make progress here it would be interesting to know how often this API is used in general and if those using it are generally using it "correctly".

Comment 6

[Andrew Cady]

Yes, just unship replace, because it's a misfeature.

The web browser is supposed to be a platform for HOSTILE code to run in.

Every single place where Firefox trusts network-supplied Javascript code is always unambiguously a bug.

You don't have to think about it twice. It's simple. You guys don't see it but it's 2+2=4. Sorry you have to throw away your feature, but it's WRONG.

As far as the idea that you should investigate empirically how much a vulnerability is being exploited in practice, before deciding whether to fix it... that thought is a product of the wrong mentality. Imagine the IDEAL web browser. Suppose you had infinite resources to make the browser PERFECT. Does the perfect browser EVER trust network-supplied Javascript? EVER? The answer is no.

But Mozilla added a feature that accidentally said yes. Now it just takes some humility to admit to the mistake and undo the feature, because that is the wrong answer.

Comment 7

[Andrew Cady]

I said that but immediately realized it was wrong. All you have to do is add a bit to each history entry to specify whether or not it has been hidden by the host site. Then you can hide them in some UI elements (such as long-click on the back button) but expose them in others (such as the full history browser).

Comment 8

[Andrew Cady]

The difference is whether you remove information from the system, or retain the information but merely add a record of the intent of another party to delete it.

The second one is always correct if the other party is untrusted, as in this case.

Comment 9

[Anne (:annevk)]

Changing severity to S4 because N/A results in autonag emails.

Comment 10

[Mason]

Phishers are using window.location.replace to hide the final URL in phishing spam.
See bug 1756852