** How sanitized now? whitelist based? ** TODO: confirm whitelist * Feed items that are bookmarklets or data uris ** TODO: confirm in feeds code ** TODO: if we do drop bad entries, need to document that

They're sanitized by http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/components/places/src/nsLivemarkService.js&rev=1.27&mark=82,521-527#509 which calls CheckLoadURIStr with DISALLOW_INHERIT_PRINCIPAL, which bz says in bug 342484 should be using CheckLoadURIStrWithPrincipal, though I still don't understand that issue. But, TODO: is the siteURI properly checked? With "always use live bookmarks" set, adding one from data:text/html,<link%20rel="feed"%20href="http://mozilla.org/news.rdf"> gives me a |Open "Mozilla Dot Org"| item for that data: URI, which doesn't give me a warm fuzzy feeling. Also, if we ever fix bug 341972 so that the siteURI is whatever the feed said it was the last time we parsed it, that different place will need to sanitize it.

What's wrong with your data: example? The security check in question would fail if the target URI were data:, but in this case the source is data: and the target is http:. Which is a perfectly fine load to be doing, right? > though I still don't understand that issue. The question we should be asking is "can this person load this URI"? Right now we're faking it and pretending that all persons can be identified by URIs. Some can. Some can't. Most can, so we're not being bitten by this too much.

My data: example was maybe underexplained, how about STR? 1. Edit - Preferences, Applications tab, find the "Web Feed" row and change it to "Live Bookmarks in Firefox" 2. Load data:text/html,<link%20rel="feed"%20href="http://mozilla.org/news.rdf"> 3. There's now a white-on-orange icon in the addressbar - click it, and in the dialog that comes up choose to "Create in: Bookmarks Toolbar" and click "Add" 4. You now have a bookmarks folder on the toolbar, named "Mozilla Dot Org", in which we will refuse to create bookmark items from the feed items if they have a data: URI for a link, but which has an item at the bottom, with the label 'Open "Mozilla Dot Org"' which links to the page where you added the feed, in this case that data: URI. Of course, to be interesting, the data URI would need more content, but the question then becomes, "can anything bad happen, when sometime down the road you click that bookmarked data: URI while the current tab contains something worth stealing or attacking?"

The answer to that question is "yes".

Filed bug 405944; thanks!

Since this is a dependency of bug 375898, marking P2 so it stays on our radar for Fx3 triage/tracking.

(In reply to comment #0) > ** TODO: if we do drop bad entries, need to document that We've dropped bad entries (and for that matter, good entries that happen not to have a link) since 0.9 - why start documenting things now? ;)

This will not block the final release of Firefox 3.

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

Is there anything left to do for this bug?