nsIContentPolicy::shouldLoad no longer called for favicons

NEW
Unassigned

Status

()

Firefox
General
--
minor
9 years ago
a year ago

People

(Reporter: Mike Perry, Unassigned)

Tracking

({sec-want})

3.0 Branch
x86
Windows XP
sec-want
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status1.9.2 wanted, status1.9.1 wanted)

Details

(Whiteboard: [sg:want])

(Reporter)

Description

9 years ago
It appears that the new places in FF3.0 code no longer calls nsIContentPolicy::shouldLoad for favicons. In the past, shouldLoad was called with a requestOrigin url of the browser overlay. Now it seems to be not called at all for favicon loads.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks

Updated

7 years ago
Flags: blocking1.9.0.19?
I'm sorry I missed this one. I don't seriously expect it to "block" Gecko 2.0, but it should be fixed anyway.
blocking2.0: --- → ?
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Whiteboard: [sg:want]
Duplicate of this bug: 602513

Comment 4

7 years ago
Right, I meant to file a bug on this but forgot. It only affects the legacy /favicon.ico request, favicons specified in the <link> tag go through content policies as expected.
As per your expectations!
blocking2.0: ? → -
Flags: blocking1.9.0.19?
Keywords: sec-want
The mixed content blocker needs to be aware of favicons linked from <link rel=icon> in order to correctly block <link rel=icon href=http://> in its strictest setting.
Blocks: 815321
I don't think this is actually a bug in favicons code, based on comment 4 looks like the browser code just fallbacks to trying the default icon if there is no <link ref=icon> specified in the page.
This code seems to confirm that http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#557
Though, getLinkIconURI always goes through ContentPolicy
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#3260

Should we also check the content policy for the default icon fallback, even if we make up an uri using docURIObject.prePath, that afaict preserves the current documentURI schema?

Updated

4 years ago
Component: Bookmarks & History → General
(In reply to Marco Bonardo [:mak] from comment #7)
> Should we also check the content policy for the default icon fallback, even
> if we make up an uri using docURIObject.prePath, that afaict preserves the
> current documentURI schema?

It isn't necessary to check the default icon fallback for the mixed content blocker because it will always be same-origin. And, I think that nsIContentPolicy should not be applied to requests that aren't based on web content such as OCSP requests and the default <scheme>://<hostname>:<port>/favicon.ico request.
No longer blocks: 815321
Depends on: 1119386
Blocks: 1119386
No longer depends on: 1119386
You need to log in before you can comment on or make changes to this bug.