Open Bug 1320523 Opened 3 years ago Updated 3 years ago
location bar autocompletes bookmarked sites when "suggest bookmarks" is unchecked
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161104212021 Steps to reproduce: 1. Preferences -> Privacy, location bar section, uncheck "bookmarks", leave "history" and "open tabs" checked. (didn't try with those unchecked) 2. close preferences window, go to address bar, start typing a url Actual results: Location bar autocompletes a hostname beginning with the url fragment that you've typed. E.g. you have a bookmark for washingtonpost.com/something and you start typing "washington" (intending to go to washington.edu, say). "washingtonpost.com" shows up in the location bar (the path part of the url doesn't appear, just the host). Expected results: Autocomplete should not leak info from your bookmarks if your privacy settings are to not suggest bookmarks.
I think the suggestion is not from bookmarks, but from the history of sites that have been visited.
Component: Untriaged → Location Bar
autofill is a bit special, cause it has to provide a very quick response. Due to that, we made a choice that if history is disabled, we consider that a privacy problem, and we show only hosts that are bookmarked. The opposite is untrue, autofill will suggest bookmarks even if they are disabled in the prefs. Bookmarks are usually not associated with privacy concerns, so we evaluated that as an "acceptable" behavior even if untrue. While it's not perfect, this may end up being a wontfix if properly supporting that filter adds performance concerns.
Bookmarks ARE a privacy concern, which is why there's a checkbox in the privacy screen to disable suggesting them. Do you really want to demo your math application on a digital projector and have OctopusTentacle.com show up in the nav bar to the whole room when you start typing octave.org? Or jobs.YourCompetitor.com when you show something to your boss? Use your imagination, I'm sure you get the idea. I don't understand the part about filtering--bookmarks shouldn't be scanned in the first place if suggesting them is disabled. And scanning them sounds slower than filtering the scan output.
Here's a slashdot post from way back in 2009: https://yro.slashdot.org/story/09/08/26/1710216/ "Mozilla's Security team has disclosed a very interesting piece of research which suggests people refused to upgrade to Firefox 3 because they were afraid the browser would expose their porn collection. Mozilla's research found that the number one reason for not upgrading was the new location bar, and the fact that it delved into people's bookmark collections to suggest sites as they typed. 'When we expanded the capabilities of the location bar to search against all history and bookmarks in Firefox 3, a lot of people contacted us to say that they had certain bookmarks they didn't really want to have displayed,' Firefox's principal designer, Alex Faaborg, tactfully explains. 'In some cases users had intentionally hidden these bookmarks in deep hierarchies of folders, somewhat similar to how one might hide a physical object.'" We should not forget these old findings!
(In reply to Paul Rubin from comment #3) > Do you really want to demo your math application on a digital projector and > have OctopusTentacle.com show up in the nav bar to the whole room when you > start typing octave.org? Or jobs.YourCompetitor.com when you show something > to your boss? Use your imagination, I'm sure you get the idea. We support multiple profiles for a reason. It would also be trivial to disable all the locationbar privacy options for a short time when one has to do such things. One could also disable autoFill permanently or temporarily, by flipping browser.urlbar.autoFill. So, there are many solutions to the problem already. Moreover, if history is enabled those pages will very likely appear regardless, unless you also clear history on shutdown. > I don't understand the part about filtering--bookmarks shouldn't be scanned > in the first place if suggesting them is disabled. And scanning them sounds > slower than filtering the scan output. Basically this requires an additional condition in the query to the database, and that additional condition requires a JOIN between 2 tables. In short, it could make the query quite slower than it is. Since this query must return results while the user is typing, we need to keep it fast and small. (In reply to Paul Rubin from comment #4) > "Mozilla's Security team has disclosed a very interesting piece of research > which suggests people refused to upgrade to Firefox 3 because they were > afraid the browser would expose their porn collection. Mozilla's research > found that the number one reason for not upgrading was the new location bar, > and the fact that it delved into people's bookmark collections to suggest > sites as they typed." That's an interesting read. I think at one point was also suggested to create "private" bookmarks, and indeed there are add-ons doing that, like https://addons.mozilla.org/firefox/addon/hush-private-bookmarking/ the reality is that from when that article was written, a bunch of things changed and were added, among which Private Browsing. Btw, I'll keep this into consideration, since one of our main concerns is privacy, but as I said it may end up being technically a wontfix if performance should be a disaster.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Hmm, I hadn't thought of multiple profiles, maybe I'll look into that, but at the very minimum I'd suggest changing the text on the privacy page. It absolutely looks like a bug in Firefox to have a page that says "privacy" with the implication "uncheck this box to keep your bookmarks private from autosuggest" when it leaks info from the bookmarks. I don't know anything about the data layout but I'd have guessed omitting the bookmarks from autosuggest would be nothing more than changing some parameters to a SELECT without adding any JOINs. I still can't believe it makes much difference given how much other slow stuff is in Firefox.
You need to log in before you can comment on or make changes to this bug.