Closed Bug 605206 Opened 14 years ago Closed 9 years ago

URL Display of Title instead of the URL Enables Phishing Attacks via URL Spoofing

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(fennec-)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
fennec - ---

People

(Reporter: mcoates, Unassigned)

References

Details

(Keywords: csectype-spoof, sec-low, Whiteboard: [sg:low spoof])

Attachments

(3 files)

Example of spoof. Actual site is defendtheapp.com
24.16 KB, image/png
Details
Example of spoof - fennec start page view
47.07 KB, image/png
Details
Screenshot showing spoofed paypal URL + spoofed lock icon
60.38 KB, image/png
Details 
Marking security sensitive. Adjust as you see fit.

The Fennec URL bar displays the title of the current page instead of the current URL.  This allows an attacker to create a convincing phishing page that will display the actual URL of the phished page within the URL display.

Steps to reproduce
1. Create an html page and set the title to: https://www.paypal.com
2. Browse to this test page at www.whatever.com
3. Observe the Fennec URL bar displays www.paypal.com to the user

Test page is available at http://defendtheapp.com


Recommended Remediation
Don't display the title in the Fennec URL bar. Instead either treat this URL bar the same as the desktop firefox browser or at a minimum display the domain from the actual URL. 

Selecting a value controlled by the page, such as the title, is encouraging phishing attacks that exploit a user's normal expectation of how the browser works (e.g. the URL bar displays the current page).
Group: core-security
Note: The spoofed URL from the title is also displayed on the fennec start page
under "Your tabs from last time"
Whiteboard: [sg:low spoof]
tracking-fennec: --- → ?
OS: Android → All
How much value do we get from displaying the title?  Looking through my
history, less than half the pages I visit have titles that fit in Fennec's
titlebar without being cut off (in portrait orientation).  Maybe it would be
better to have some secondary UI where the title is displayed, in a way that
allows for longer titles.
I find it useful, but yeah - it might be time to move away from a permanent on-screen title (and certainly URL). Where by "time to" I mean post-v4.  Something that could bring up a richer version of the larry info, so all the site identity info is in the same place.
Yeah, if we move away from page title, we should certainly move away from URL too.
Assignee: nobody → madhava
Let's make a decision on this for final
tracking-fennec: ? → 2.0+
This makes it much easier to phish people, so sg:low seems a bit understated to me.  sg:moderate (disclosure of sensitive information mitigated by requiring user interaction) seems more appropriate?
(In reply to comment #9)
> This makes it much easier to phish people, so sg:low seems a bit understated to
> me.  sg:moderate (disclosure of sensitive information mitigated by requiring
> user interaction) seems more appropriate?

I agree.
My feeling here is that page title is of much great value to the user than the
URL, which is why we have a titlebar here instead of a URL bar (which you get
when you tap on the title).  When we were designing for the small screen, we
made the decision that, without room for both, we'd pick the page title to show
instead.

Now, I realize you can agree with that statement and still find there to be a
problem here, which is think what is happening.

Mark had a suggestion, which was to detect when the page title is in the form
of a URL, and, in those cases, show the real URL instead.  That would help to
foil this particular "title masquerading as URL" attack, I think.

I'd strongly advocate against just showing the URL instead of the title all the
time.  It's my understanding that URLs are not well understood or parsed by
most users, and (you guys know more about this than I do here) showing URLS are
not even a very strong anti-phishing control compared to the anti-phishing page
interception we do on desktop (and should do, in some form, in Fennec).
(In reply to comment #11)
> Mark had a suggestion, which was to detect when the page title is in the form
> of a URL, and, in those cases, show the real URL instead.  That would help to
> foil this particular "title masquerading as URL" attack, I think.

If we decide to implement this, we'll need to be careful to catch ways that a title can *look* like a URI without actually being a valid URI or matching a naive regexp.  It might contain whitespace like U+2009 THIN SPACE, homoglyphs from other scripts, control characters or other hard-to-see Unicode characters; it could replace the slashes with backslashes or U+2044 FRACTION SLASH.  I'm sure there are more possibilities I haven't thought of.
> If we decide to implement this, we'll need to be careful to catch ways that a
> title can *look* like a URI without actually being a valid URI or matching a
> naive regexp.  It might contain whitespace like U+2009 THIN SPACE, homoglyphs
> from other scripts, control characters or other hard-to-see Unicode characters;
> it could replace the slashes with backslashes or U+2044 FRACTION SLASH.  I'm
> sure there are more possibilities I haven't thought of.

This is a really good point and something we should give thought to.  In the end attackers will think of clever ways that will bypass our blacklist filter. Do we want to get into this cat and mouse game of trying to prevent title based URL attacks?
Barring the removal of the URLBar completely, do we have any viable solutions for this?

Adding some form of phishing protection via a blacklist, url classifier is something we must do, but removing page titles and only showing URLs is not viable, imo.
(In reply to comment #13)
 
> This is a really good point and something we should give thought to.  In the
> end attackers will think of clever ways that will bypass our blacklist filter.
> Do we want to get into this cat and mouse game of trying to prevent title based
> URL attacks?

Yes agreed - a technique that tries to help people by showing a URL will be out-clevered pretty quickly;  I brought it up more as a speedbump.

The point remains - URLs have been shown to not be good anti-phishing cue. Approaches that we know (or strongly suspect) do help include the things we do on the desktop: a more sophisticated Larry that shows the domain/org-name; and, most importantly, the anti-phishing interceptor pages.  The latter would be very helpful. The former we don't include out of space restrictions -- we might be able to figure something out here, though;  it's not perfect, but a rich set of cues as to who you're talking to can only be helpful.

Sadly, no other mobile browser does this any better (by a long shot), so there's not obvious technique to emulate.  This is a hard problem, which is why I don't know that I'd block on it.
(In reply to comment #15)
> Sadly, no other mobile browser does this any better (by a long shot), so
> there's not obvious technique to emulate.  This is a hard problem, which is why
> I don't know that I'd block on it.

I agree with this - preventing phishing is noble work but I don't think I'd block on the specific solution proposed here. URLs are tricky to parse, and once you try to help users there ("eTLD+1!", I hear you say, "Org name for suitably trustworthy certificates!") we're back to what madhava mentions in comment 15 - exploring ways to port the desktop Larry UI to mobile. Even then, though, you're mostly providing affirmative context, and I don't know what that design would look like, either.

I assert that the best way we have right now to prevent phishing is to block those sites - and while I know the work is basically orthogonal, I would strongly prefer we prioritize work on getting some version of safebrowsing support integrated on mobile over giving our users URLs and asking them to do the detective work.

(Aside: I, too, agree with mbrubeck that trying to detect url-ish things in the title bar is a potential snake-pit of tar-babies in a rat-hole.)

(Aside #2: I could imagine it being pleasant to have the url show while the page is loading, and then transitioning to the page title once loaded. We already sort of do this, but in some cases the title transition happens too quickly to actually read it. And I would mostly like it as a piece of general contextual information, not as an anti-phishing defense.)
Another idea is to always show the actual url whenever the page includes a password form.  This way the pertinent data is displayed at the time a user is most likely to care i.e. when submitting their password.
(In reply to comment #17)
> Another idea is to always show the actual url whenever the page includes a
> password form.  This way the pertinent data is displayed at the time a user is
> most likely to care i.e. when submitting their password.

This is a really interesting line of thinking.  Showing the URL is one thing we could do here... are there others, like a notification when you focus a password field on a page you've never been to beore?
Password forms should also be fairly easy to spoof. Maybe there is some way we can show both, stacked, similar to results in the awesome bar?
(In reply to comment #19)
> Password forms should also be fairly easy to spoof. Maybe there is some way we
> can show both, stacked, similar to results in the awesome bar?

I am suggesting we show the current page's URL at the top of the screen within native Fennec Chrome when a password form is present on the page (possibly instead of the normal title display). 

I don't see any risk in a page displaying a password form since it would only cause the URL of that page to be more prominently displayed. Am I misunderstanding your "password form spoof" concern?
(In reply to comment #20)
> I am suggesting we show the current page's URL at the top of the screen within
> native Fennec Chrome when a password form is present on the page (possibly
> instead of the normal title display). 
> 
> I don't see any risk in a page displaying a password form since it would only
> cause the URL of that page to be more prominently displayed. Am I
> misunderstanding your "password form spoof" concern?

I think wes is pointing out that this defense doesn't stop anyone who's paying attention, since a phisher will just use a regular text field and some javascript hijinx, if using an actual password field gives them trouble.
tracking-fennec: 2.0+ → 2.0-
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Depends on: 653075
Wes pointed me at this bug regarding URL/title bar spoofing (not just spoofing the title to look like a URL, but spoofing the entire URL bar UI).  As far as I can tell this bug was a discussion of the latter.  Has there been a security review of the hideable URL bar?  The concern is that pages can force it to be hidden by scrolling themselves, then draw their own spoofed bar and collect user's input there (which was supposed to be entered into trusted UI).
Displaying the title in the urlbar is the most myopic thing I have seen the Mozilla project do.

This needs to be fixed. This is a major reason to recommend to people not to use firefox.

Now I am worried there's thousands of other huge security flaws in fennec that developers don't understand or care about. This is very troublesome.
Assignee: madhava → nobody
Product: Fennec → Firefox for Android
Depends on: 778216
I wonder if it would be helpful to force the url to show during page load and for the first few seconds after DOMContentLoaded (or first paint)? i.e. we're eventually going to scroll the header off a few seconds after page load anyway, maybe we hide the url and switch to the title then...
I find it bizarre that this is not fixed yet. I find it very jarring to use Firefox on my Nexus 10 just because I can't quickly see the current URL without tapping the address bar. chrome for android and every modern desktop browser(including desktop firefox!) have gone the opposite way and barely display more than the first couple words of the page title, yet keep the URL visible at all times.  


why can't we at the very least get an about:config value to change what gets displayed in the bar?
Now that we have a dynamic toolbar, I wonder if we can address this again? For the most part the title scrolls off and isn't even shown anymore on sites. I wonder if we could just use the url.... If we wanted to be more fancy, we could show the url until the urlbar is hidden, at which point we'd change to title (or vice versa?). Or we could do a fancy scroll animation like our tabs counter does and transition between the two after 10 seconds.
(In reply to Wesley Johnston (:wesj) from comment #29)
> Now that we have a dynamic toolbar, I wonder if we can address this again?
> For the most part the title scrolls off and isn't even shown anymore on
> sites. I wonder if we could just use the url.... If we wanted to be more
> fancy, we could show the url until the urlbar is hidden, at which point we'd
> change to title (or vice versa?). Or we could do a fancy scroll animation
> like our tabs counter does and transition between the two after 10 seconds.

Good point. Ian, what do you think?
Flags: needinfo?(ibarlow)
(In reply to Wesley Johnston (:wesj) from comment #29)
> Now that we have a dynamic toolbar, I wonder if we can address this again?
> For the most part the title scrolls off and isn't even shown anymore on
> sites. I wonder if we could just use the url.... If we wanted to be more
> fancy, we could show the url until the urlbar is hidden, at which point we'd
> change to title (or vice versa?). Or we could do a fancy scroll animation
> like our tabs counter does and transition between the two after 10 seconds.

I am still of the mind to keep the title, but I am happy to re-discuss now that we scroll off the screen (which is itself another attack vector), but I do not think we should do anything "fancy".

I thought we show the URL until we get a DOMTitleChanged message, where we then show a title.
(In reply to Lucas Rocha (:lucasr) from comment #30)
> (In reply to Wesley Johnston (:wesj) from comment #29)
> > Now that we have a dynamic toolbar, I wonder if we can address this again?
> > For the most part the title scrolls off and isn't even shown anymore on
> > sites. I wonder if we could just use the url.... If we wanted to be more
> > fancy, we could show the url until the urlbar is hidden, at which point we'd
> > change to title (or vice versa?). Or we could do a fancy scroll animation
> > like our tabs counter does and transition between the two after 10 seconds.
> 
> Good point. Ian, what do you think?

It's an interesting point, but I don't really see how this relates to having a dynamic toolbar. Iirc, ack in the XUL days of fennec (when this bug started), our title bar disappeared when scrolling as well.
Flags: needinfo?(ibarlow)
(In reply to Ian Barlow (:ibarlow) from comment #32)
> It's an interesting point, but I don't really see how this relates to having
> a dynamic toolbar. Iirc, ack in the XUL days of fennec (when this bug
> started), our title bar disappeared when scrolling as well.

On the other hand, in XUL Fennec the toolbar was the only place where the title was displayed.  Today we display titles in the tab tray, so *if* we decide to remove them from the toolbar they would still be visible elsewhere.
(In reply to Mark Finkle (:mfinkle) from comment #31)
> I thought we show the URL until we get a DOMTitleChanged message, where we
> then show a title.

We do. I just wonder if that's too short in some cases and we should at least have a minimum time we show things.

(In reply to Ian Barlow (:ibarlow) from comment #32)
> It's an interesting point, but I don't really see how this relates to having
> a dynamic toolbar. Iirc, ack in the XUL days of fennec (when this bug
> started), our title bar disappeared when scrolling as well.

I forgot about that. I think we did show the title's on tabs in XUL Fennec, but our tabs (on phones) were smaller (like our current tablet tabs). You never saw much of the url? With the dynamic toolbar, the textbox has moved in my mind from something similar to a titlebar, to more of a button I use when I want to go to a new page. I don't feel like I look there to see where I am.
(In reply to Madhava Enros [:madhava] from comment #11)
> My feeling here is that page title is of much great value to the user than
> the
> URL, which is why we have a titlebar here instead of a URL bar (which you get
> when you tap on the title).  When we were designing for the small screen, we
> made the decision that, without room for both, we'd pick the page title to
> show
> instead.

Ok this decision doesn't make any sense to me.

If the title is so valuable then why is it not visible on the desktop version?  the only place it is displayed is in the tab which only provides a few characters of space and is generally unreadable, a user has to hover on the tab to see the title which is a very similar use case as click on the url bar to reveal the url as is now done on Fennec.

Right now it seems to me that Fennec treats the title as the most important information which is counter to every desktop and mobile browser, and Firefox treats the url as the most valuable piece of information.

Firefox and Fennec should at least be consistent here..  otherwise we have two groups of UX designers that disagree..
(In reply to Erik Vold [:erikvold] [:ztatic] from comment #36)

> Right now it seems to me that Fennec treats the title as the most important
> information which is counter to every desktop and mobile browser, and
> Firefox treats the url as the most valuable piece of information.

Regardless of how this turns out, I do want to comment on that fact that you think showing the URL makes any difference in the phishability of the page. You, we, have no data to support that claim. Regardless of whether desktop and other mobile browsers show the URL.
>I do want to comment on that fact that you think showing the URL makes any difference in the phishability of the page.

So what was the reasoning behind highlighting the domain in the awesomebar?
(In reply to Gian-Carlo Pascutto (:gcp) from comment #38)
> >I do want to comment on that fact that you think showing the URL makes any difference in the phishability of the page.
> 
> So what was the reasoning behind highlighting the domain in the awesomebar?

I assume on the off chance someone looks at the URL and understands what 'domain' means and correctly guesses what the expected 'domain' should be and if they are not the same then they realize that they might be phished.

In other words, more aesthetic and less protection, IMO.
(In reply to Erik Vold [:erikvold] [:ztatic] (needinfo me if you have a question please) from comment #36)
> If the title is so valuable then why is it not visible on the desktop
> version?
> ...

I'm also wondering the same thing.

> Right now it seems to me that Fennec treats the title as the most important
> information which is counter to every desktop and mobile browser, and
> Firefox treats the url as the most valuable piece of information.
> 
> Firefox and Fennec should at least be consistent here..  otherwise we have
> two groups of UX designers that disagree..

That reasoning makes sense to me as well. If showing the title in the address bar is better UX, why not do 
it for desktop as well. Is there some reason why it's better on mobile to show the title in the address bar but not better on desktop?

Regardless, I think the combination of the ability to spoof a URL with the ability to spoof a green lock icon make this UX especially misleading to users. See https://bugzilla.mozilla.org/attachment.cgi?id=8494172 and the source at http://people.w3.org/mike/phish/
(In reply to Mark Finkle (:mfinkle) from comment #37)
> Regardless of how this turns out, I do want to comment on that fact that you
> think showing the URL makes any difference in the phishability of the page.
> You, we, have no data to support that claim. Regardless of whether desktop
> and other mobile browsers show the URL.

I don't have that kind data at hand either, but I'll try to get some.

But the address-bar area is browser chrome and I think it's common practice that you don't let the content of Web pages change browser chrome.

I think the core problem here from a user/UX perspective is that users believe that users believe that what shows up in the address bar is controlled by the browser. In particular, for any users that do look at a URL in the address bar and notice it, I think their expectation is that the URL is the address of the current document that the browser has navigated to -- the address of the document the browser is currently displaying. So, allowing Web content to spoof URLs there runs counter to those users' expectations.

Along with that, there is third-party guidance that (for better or worse) tells users that in order to make informed trust decisions, they should check the URL in the address bar, and do things like note whether it starts with "https" vs "http" (along with whether it shows a lock icon or other indicator).

Again, I don't have specific data to back this up, but it seems fairly intuitive that this UX could adversely affect at least some users' trust decisions (and that in general it may not be prudent to expose users to trust-decision-affecting UX that runs counter to what desktop Firefox does and what other browsers do).
Favicon spoofing is bug 1018994, and will apparently be fixed in the new tablet UI. (Which does nothing for the majority of users on phones, of course)
>I do want to comment on that fact that you think showing the URL makes any difference in the 
>phishability of the page.

If I didn't think this was a weak argument to begin with, then comment 41 surely has not just pushed it over but shot it in the face and then gave it a kick in the groin for completeness.

Any user who understands what a domain is, is quite clearly more susceptible to getting phished if we hide the URL (or far worse: allow it to be spoofed!) by default. I think - I hope - this is not a point of contention. There are a few tricks to mislead people with URLs, and we have defenses for them (highlighting, right-alignment of true top level domains, etc). Clearly, whatever UX team came up with them must've had quite a different idea about this than whatever lead to this bug being WONTFIXED.

Now, an argument can be made that showing the URL just fixes the problem for advanced users, thus hiding the true problems that a novice user - who doesn't know about domains - faces. This is fine and a valid point. But WE DON'T HAVE a solution for novice users. We didn't have one 4 years ago when this was filed [1]. We don't have one today. We don't have one in planning as far as I know [2]. Our competitors don't seem to have one either. If anything, the entire idea of security on the internet and all security decisions inside Firefox are moving towards using same-origin policy, HTTPS+HSTS and (EV) certs and educating people what those are.

Except for Fennec, which seems to have decided that if there's no perfect solution, it's not even worth bothering with all of that. Throwing up our hands, deciding that users are probably stupid, aren't worth educating and choosing the most insecure option of all possibilities. We've come far.

Please fix this. [3]

[1] Some of the original comments seem to have had the assumption that SafeBrowsing would magically catch all phishing pages, in the same way people with a virus-scanner have been known to never ever get a virus either. Independent studies show us catching about 95% of the pages, which means that only 1 in 20 people are getting all their money stolen. I'm not even getting into issues like stuff that doesn't qualify as a phishing page but still uses "suddenly another domain" tricks to steal privacy sensitive information, like Google Maps.
[2] Even if we had, anything that isn't a patch with an r+ on it and a green Try push isn't an argument either.
[3] If this plea doesn't convince you, I'll notice that although my contract prohibits the bribing of public officials, it does not say anything about fellow developers, and I'm not far off the source of Westvleteren 12. Not implying anything, just a factual observation.
With the work in the new Tablet UI giving us a different reason to look at favicons and page titles, we should use the opportunity to think about how we could change the Phone UI as well.

1. We already have a Setting to display the page URL instead of the page title. We could look at defaulting this to show the URL instead of the title.
2. Even though showing the page URL might only help advanced users, it's a non-zero sized group.
3. Removing the favicon completely from the toolbar might help with pageload performance too. We can do actual, objective science on this part.

I think there is a lot of security theater happening in this bug, which is why I have been asking for real data showing that people would not only be tricked by bad actors swapping the title for a fake URL, but also that people would be not-tricked by bad actors showing real URLs too. I don't see any data or research appearing, but I think we should still look into making some changes.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
The main reason for only showing URLs in the new tablet UI is that we'll show titles in the tab strip making the title in the toolbar redundant. Same for favicons: we're now showing them in the strip which makes them redundant in the toolbar.

This favicon/title redundancy is not present in the phone UI though. So the decision to change the phone UI to align with the recent changes in the new tablet UI need different arguments.

My take on this has always been that I think the toolbar feels too complex due to the constant visual state changes -- especially when loading a new page. Removing favicons from the toolbar on phones would probably make it feel simpler.

The same applies to showing titles in the toolbar. Right now, we always show the URL when the page starts loading and then switch to the page title once it becomes available. It's a switch that happens very quickly but, again, adds complexity to the toolbar. Always showing URLs would reduce the number of visual changes during page load.
(In reply to Michael[tm] Smith from comment #43)
> Along with that, there is third-party guidance that (for better or worse)
> tells users that in order to make informed trust decisions, they should
> check the URL in the address bar, and do things like note whether it starts
> with "https" vs "http" (along with whether it shows a lock icon or other
> indicator).

Not to beat this into the ground (I've read comment 46 and comment 47 and in particular Mark's statement "I think we should still look into making some changes" so I realize there's maybe some emerging agreement here to make some changes) but in the interest of providing some small amount of evidence to support the claim I made above about third-party guidance, here are a couple of links:

https://www.paypal.com/be/cgi-bin/webscr?cmd=xpt/Help/popup/RecognizeSpoof-outside
'Only enter your PayPal password on PayPal pages. These begin with https://www.paypal.com/'

http://www.fbi.gov/scams-safety/e-scams
'When taken to the payment page of a website, again verify the URL and ensure it is secure by starting with “HTTPS,” not just “HTTP.”'

There are a lot of similar "How to protect yourself from scams|phishing|fraud" guidance documents out there but I think (hope) the two examples of above are sufficiently illustrative enough to support the assertion that, in order to make trust decisions on the Web, many sources are advising users to (1) actually look at the URL in the address bar, and (2) check that the URL begins with "https".

Since the current Firefox Mobile UX allows both the entire URL to be spoofed and the in particular the "https" part of the URL to be spoofed, that existence of that advice to users from the likes of PayPal and the FBI risks giving Firefox Mobile users a (potentially dangerous) false sense of security.

So it seems that, short of getting PayPal and the FBI and N other different organizations providing this kind of "check the URL and make sure it starts with https" guidance to all remove that guidance from their "How to protect yourself from scams|phishing|fraud"-type documents in short time, the prudent choice to go with here in order to help mitigate the risks to users as much as possible is to make some change to what Firefox Mobile is currently doing with the display of raw title contents in the address bar.
(In reply to Mark Finkle (:mfinkle) from comment #39)
> I assume on the off chance someone looks at the URL and understands what
> 'domain' means and correctly guesses what the expected 'domain' should be
> and if they are not the same then they realize that they might be phished.
(In reply to Mark Finkle (:mfinkle) from comment #46)
> I think there is a lot of security theater happening in this bug, which is
> why I have been asking for real data showing that people would not only be
> tricked by bad actors swapping the title for a fake URL, but also that
> people would be not-tricked by bad actors showing real URLs too.

I still haven't had time to look much for such data, but in comment 48 I have at least attempted to provide some data which indicates that organizations like PayPal and the FBI are advising users to do what you described above -- that is, to actually look at the URL in the address bar and to then make a trust decision based on the contents of the URL.

So, given what seems to be fairly widespread existence of that kind of advice to users having been out there in the wild already for quite a while now, the question of whether there's hard data to show the URL actually makes any difference in the phishability of the page maybe becomes moot.

Also, with respect, I think your use of "security theater" in your comment is a bit of mischaracterization.

At least I know I'm not personally suggesting that you make a change here simply for the sake of making a superficial show for concern about user security that doesn't actually help users. At least in my case I can say that I think that changing this would materially help put users at less risk of making misguided trust decisions -- and as far as I can see from the rest of the comments here, that (not security theatrics) seems to be what's motivating the to comment as well.
It is somewhat surprising that this has not gotten security review. As far as I know this would be one of the only browsers that does not display at least a domain name in the URL bar for the user to base trust decisions on.

We could never ship a UI like this on Firefox Desktop. Now perhaps that is why we should push the boundaries here, but I highly doubt it.
Bug 1111729 has reverted to showing the full URL by default with a user facing preference in settings to toggle to title
(In reply to Aaron Train [:aaronmt] from comment #52)
> Bug 1111729 has reverted to showing the full URL by default with a user
> facing preference in settings to toggle to title

I retract that, the preference is removed https://bugzilla.mozilla.org/show_bug.cgi?id=1111729#c7
This bug was fixed by bug 1111729. That bug also removed the Setting allowing people to switch back to display the Title. We added the Setting back in bug 1118835.

In Fx37 you should see the URL displayed in the toolbar by default.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 9 years ago
Resolution: --- → FIXED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: