537922 - Viewing bookmark properties causes HTTP retrieval

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Microsummaries, enhancement)

Description

[rifojxh]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8pre) Gecko/20100102 Ubuntu/9.10 (karmic) Shiretoko/3.5.8pre
Build Identifier: 3.5 to 3.7 tested

Viewing bookmark properties causes HTTP retrieval to happen if the bookmark URL is for HTTP protocol.
This happens whether the bookmark is selected in the Library or Properties is selected from the toolbar.

I suspect that the retrieval is intended for site icon handling and that the property browser.chrome.site_icons should enable or disable it.  None of the following properties had effect on the behavior described in this report:
browser.chrome.site_icons
browser.chrome.favicons
network.prefetch-next

"Work Offline" did suppress the retrieval.

This is a security issue as it causes an unintended network retrieval.


Reproducible: Always

Steps to Reproduce:
I tested in Firefox 3.5 and 3.7 daily build.
I tested this by observing traffic in wireshark.
Select a bookmark in the browser. It may be that the bookmark must have no site icon. You may need to import bookmarks to cause loss of information which will then be retrieved.
Actual Results:  
A HTTP request results.

Expected Results:  
There should be no network traffic.

Comment 1

[Jeff Walden [:Waldo]]

Not security-sensitive -- an unintended (only for some people) network retrieval is nowhere close to the end of the world, probably happens all the time with sites that don't use caching headers optimally.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Try browser.microsummary.enabled to false.

Comment 3

[David Dahl :ddahl]

This sounds like a WONTFIX or INVALID to me. 

Reporter:
Does 'browser.microsummary.enabled = false" solve this for you?

Comment 4

[Marco Bonardo [:mak]]

this is not privacy nor security issue, and is known and due to microsummaries (so even wanted), we check if the page has an available microsummary to present to the user eventual auto-updating titles for it.

Comment 5

[rifojxh]

Yes, that fixed it.

I found the documentation at
https://wiki.mozilla.org/Microsummaries
and was going to link it in to
"Firefox makes unrequested connections"
http://support.mozilla.com/en-US/kb/Firefox+makes+unrequested+connections?bl=n&s=unrequested%20connections
but registration reports it is "unable to validate" my e-mail address.

I think this issue can be considered solveable by documentation.
(that does not mean I am advocating that as the best way)

For the user to find and resolve the issue in documentation it would be good to have a path that led from
Help Contents → Bookmarks → Microsummaries → property browser.microsummary.enabled .

Comment 6

[rifojxh]

Also, I think that if "private browsing" is to serve as a single switch for most privacy options, it should disable microsummaries.

Comment 7

[Marco Bonardo [:mak]]

but it is still invalid, first it is not an issue, second it is expected, third privaty browsing does not work blocking connection, but not allowing user's actions registration in the local database.

Comment 8

[rifojxh]

You would perhaps expect it, but most users will not, which is what can lead to the privacy issue.  If you can't imagine examples, I will provide a mild one. (There are less mild ones.)

Consider someone who brought his laptop to work and is sorting his "Unsorted Bookmarks". Some of them are NSFW, and he would not intentionally retrieve them at work.

If cookies are sent with microsummaries, they will also identify the originating source (IP address or network or P2P net) as belonging to the owner of the cookie.

I would understand the point of view,
"In my estimation, this is so little an issue or an issue for so few circumstances that we are never going to address it." (Won't Fix)
but if you think there is no issue at all, I think there are some scenarios you have not imagined yet.

Comment 9

[Marco Bonardo [:mak]]

You can just disable microsummaries to solve your problem. Do we want to expose an option to do that in an easier way than in about:config? Answer is no, otherwise we would have already done that, reason is that we don't want to provide thousands of settings that are meaningless (and hard to understand) to most users, that's why about:config exists (among other things).

Do you want to suggest a solution without exposing a new preference UI?
If it's a better documentation, then this bug should be moved to documentation, that said, i think the "Firefox makes unrequested connections" support topic is pretty clear.

Comment 10

[rifojxh]

Here is a suggestion of how it could work without a new preference UI entry.

For any given bookmark, the button for the microsummaries list would be always available, whether microsummaries exist for the bookmark or not. The button has a style that indicates firefox has no microsummaries to choose from when the list is empty.  Clicking on the button for the drop down list will initiate the microsummary retrieval and open the generated list if there were any retrieved. If microsummaries have become available, the style of the button is altered to reflect that.  The style change of the button could be the greyed-out/inactive versus full contrast/active style change.

About the current documentation:
There is a statement which is false on the "unrequested connections" page:
"If you have any Live Title bookmarks, they may be updating themselves. Deleting all your Live Title bookmarks will stop these connections from being made."
The suggestion I made for the firefox bookmark UI would make firefox consistent with this documentation.

Also about the user documentation of Microsummaries, the browser.microsummary properties are not mentioned.

Comment 11

[Marco Bonardo [:mak]]

(In reply to comment #10)
> For any given bookmark, the button for the microsummaries list would be always
> available, whether microsummaries exist for the bookmark or not. The button has
> a style that indicates firefox has no microsummaries to choose from when the
> list is empty.
  Clicking on the button for the drop down list will initiate the
> microsummary retrieval and open the generated list if there were any retrieved.

This is a bad experience, because then users, to know if a page has microsummaries, need to click a button. So supposing i have 1000 bookmarks, i have to click all of them one-by-one to know if they could provide me further information?
This is just not how the thing is supposed to work :(

> Also about the user documentation of Microsummaries, the browser.microsummary
> properties are not mentioned.

We should fix the docs.

Comment 12

[Chris Ilias [:cilias]]

Re: user-doc-needed
For clarification, you want:
* A section added to "Firefox makes unrequested connections" dedicated to favicons.
* The "Live Title updating" section to tell users to set browser.microsummary.enabled;false.

Anything I have incorrect or am missing?

Comment 13

[rifojxh]

"So supposing i have 1000 bookmarks, i have to click all of them one-by-one to know if they could provide me further information?"
Checking for Live Title availability could also be done by selecting a subtree in Bookmarks.  Think of how checking for updated sites was done in some versions of Navigator. If Mozilla/Firefox did not implement bulk checking, I think it is the sort of thing that a bookmark AddOn maker would eagerly provide. Automatically checking even without the user's request would still be the most convenient. There is some trade off.

About
* The "Live Title updating" section
"Deleting all your Live Title bookmarks will stop these connections from being
made."
Needs to be removed or amended because it is a false statement.
"tell users to set browser.microsummary.enabled;false." is worthy content for that document.

About
* A section added to "Firefox makes unrequested connections" dedicated to
favicons.
I had presumed favicons were only updated when a page was retrieved and that the traffic referred to in this report only concerns Live Titles.  So I don't know whether or not favicons are an issue.

Comment 14

[Marco Bonardo [:mak]]

yeah, i don't think favicons are an issue. just better description for how to disable microsummaries would be nice.

Comment 15

[Chris Ilias [:cilias]]

Edit has been made to <https://support.mozilla.com/en-US/kb/*Firefox+makes+unrequested+connections>. Just waiting for someone to review it.

Comment 16

[Chris Ilias [:cilias]]

It was approved. You should be able to see the changes now.

Comment 17

[rifojxh]

I read the Live Title section.
I think it is sufficient to enable a user to address the issue in this report.

There may be some worthwhile ways to improve the documentation further, such as:

wiki.mozilla.org
and
support.mozilla.com
are using different terms. support.mozilla.com uses "live title" and does not refer to "microsummary" except in the name of the config option. The article on microsummaries does refer to "live title". Could 1 term be chosen and the other eliminated? Is it permissible to link the wiki page from the support page?

The information in the documentation about microsummaries is good.
It would be good for a user to be able to find the documentation by following links rather than only by landing on the page by entering search terms.
A sensible path would be
Help Contents → Bookmarks → Microsummaries.
In the Bookmarks page, I would expect to find the information about microsummaries in the section on editing or setting bookmark properties or managing bookmarks.

Comment 18

[Chris Ilias [:cilias]]

https://wiki.mozilla.org/Microsummaries is not meant to be user documentation. For a user doc dedicated to Live Titles (which is the user terminology for it), see bug 412609.

Comment 19

[rifojxh]

The existing changes to documentation satisfy me that a user can address the problem and the status of this issue is no longer 'bug'. Documentation is 'Resolved'. Addressing further documentation improvements can continue in Bug 414609.

Opinion is subjective on the ideal UI is.
Work on the UI could possibly occur as an 'optional enhancement', so I change the bug to 'enhancement' in case anyone else finds it who wishes to work on it.

Comment 20

[rifojxh]

I gave the wrong bug number, I meant Bug 412609.

Comment 21

[Marco Bonardo [:mak]]

- BUGSPAM -
Wontfixing all Microsummaries bugs, since the feature has been removed from the core product and previous versions won't get further fixes for it.
If interested in supporting Microsummaries in your add-on, you're free to use our old microsummaries code and to search all previously open bugs by looking for [microsummaries-feature-removal] in the status whiteboard field.