Why does the address bar show the tempolink instead of the permalink?

An important feature of HTTP is the temporary redirect, where a resource can have a “permanent” URI while its content moves from place to place over time. For example,
http://purl.org/syndication/history/1.0 remains a constant name for that resource even though its location (as specified by a second URI) changes from time to time.

If this is such a useful feature, then why does the browser address
bar show the temporary URI instead of the permanent one? After all,
the permanent one is the one you want to copy and paste to email, to
bookmark, to place in HTML documents, and so on. The HTTP
specification says to hang on to the permanent link (“since the
redirection MAY be altered on occasion, the client SHOULD continue to
use the Request-URI for future requests.”). Tim Berners-Lee says the
same thing in User Agent watch points
(1998): “It is
important that when a user agent follows a “Found” [302] link that the
user does not refer to the second (less persistent) URI. Whether
copying down the URI from a window at the top of a document, or making
a link to the document, or bookmarking it, the reference should
(except in very special cases) be to the original URI.”
Karl Dubost amplifies this in his 2001-2003 W3C Note Common User
Agent Problems
: “Do not
treat HTTP temporary redirects as permanent redirects…. Wrong: User
agents usually show the user (in the user interface) the URI that is
the result of a temporary (302 or 307) redirect, as they would do for
a permanent (301) redirect.”

So why do browsers ignore the RFC and these repeated admonitions?
Possibly due to lack of awareness of the issue, but more likely
because the status quo is seen as protecting the user. If
the original URI (the permalink) were shown we might have the following scenario:

  1. an attacker discovers a way
    to establish a 3xx redirect from
    http://w3.org/resources/looksgood to
    http://phishingsite.org/pretendtobew3 – either because w3.org
    is being careless, or because of a conscious decision to deed part
    of its URI space to other parties

  2. user sees address bar = http://w3.org/resources/looksgood with
    content X, and concludes that the X is attributable
    to the resource http://w3.org/resources/looksgood

  3. user treats the http://w3.org/ prefix as an informal credential
    and treats the http://w3.org/resources/looksgood content as
    coming from W3C (without any normative justification; they just
    do) when in fact it’s a phishing site pretending to be W3C

  4. user enters their W3C password into phishing form, etc.

Were the user to observe address bar = http://phishingsite.org/pretendtobew3 with the same content, she
might suspect an attack and decline to enter a password.

An attacker might make use of an explicit redirection service on a site similar to that provided by purl.org, or it might exploit a redirect script that takes a URL as part of the
query string, e.g.
http://w3.org/redirect?uri=http://phishingsite.org/pretendtobew3 .

This line of reasoning is documented in the Wikipedia article URL redirection and its references and
in Mozilla bug 68423.

There are two possible objections. One is that the server in these
cases is in error – it shouldn’t have allowed the redirects if it
didn’t really mean for the content source to speak on behalf of the
original resource (similar to an iframe or img element). The other is
that the user is in error – s/he shouldn’t be making authorization
decisions based on the displayed URI; other evidence such as a
certificate should be demanded. Unfortunately, while correct in
theory, neither of these considerations is very compelling.

If browser projects are unwilling to change address bar behavior – and
it seems unlikely that they will – is there any other remedy?

Perhaps some creative UI design might help. Displaying the permalink
in addition to the tempolink might be nice, so that it could be
selected (somehow) for bookmarking, but that might be confusing and
take too much screen real estate. One possible partial solution would
be an enhancement to the bookmark creation dialog. In Firefox on
selecting “Bookmark This Page” one sees a little panel with text
fields “name” and “tags” and pull-down “folder”. What if, in the case
of a redirection, there were an additional control that gave the
option of bookmarking the permalink URI in place of the substitute
URI? With further thought I bet someone could devise a solution that would work for URI copy/paste as well.

(Thanks to Dan Connolly, other TAG members, and David Wood for their
help with this note.)

4 Responses to Why does the address bar show the tempolink instead of the permalink?

  1. A solution exists already. Back in 2008, Tamura Jones (of JavaScript-free Chrome Frame detection fame) wrote the permalink trilogy, which discusses permalink conventions and best practice, and suggested that bookmarkers recognize class=”permalink” to make sure they bookmark the permalink to a page instead of a tempolink: Marking Permalinks.

  2. I actually *want* to know where I am being redirected. There are just too much clunky web site configurations out there. For us to assume that everything is in good order is very optimistic. Furthermore, when the site wishes to provide stuff that has to point to a different version over time, a cleaner method is to use Apache rewrites, (for non-techies:) which “forwards” the request internally, on the server itself, and returns the result of the proper version.

  3. The problem is that the address bar is serving two functions (at least): “what am I actually reading?” and “what is the reference to what I am reading?”. Showing the redirect answers (a) but not (b), and the reverse is true if you don’t.
    Perhaps we need a better way to get a reference; after all, you have to ‘just know’ if there is an anchor on the page you could point to, that would serve as a more precise reference. Some visual indication or affordance that showed where the closest anchor is (if any) and allowed you to copy the permalink (maybe #anchor) to the clipboard for pasting.

  4. Dave Singer has got it in one. Browser behavior isn’t really the issue here; browser user interface real estate is the issue.
    I think we want users to know when they have been redirected, or at least to be able to get that information. We also want them to have the (recommended) option of bookmarking the permalink.
    Tamura Jones’ solution requires HTML authors to anticipate user behavior, which is not a complete solution, IMO. I think a better option is for browser vendors to denote a redirection visually in the address bar while showing the permalink. Selecting the visual indication of a redirection could show the tempolink. That solution would be similar in concept to the display of a “lock” icon for SSL/TLS connections (including the display of certificate information in some browers when the lock icon is selected).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you comment here, note that your IP address is sent to Akismet, the plugin we use to mitigate spam comments.