OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Summary: History can fill FF3 addressbar suggestions with unwanted bookmarklets that look almost like real pages. → History can fill FF3 addressbar suggestions with unwanted bookmarklets that look almost like real pages but execute in the current page's scope.
No takers? I think this is really quite critical since a malicious page can redirect thru a bookmarklet for any number of times thereby increasing its rank in the suggestion list... or it could make subtle changes to the bookmarklet each time it redirects so that all entries in the suggestion list consist of this bookmarklet... combine that with the situation that almost anybody activates a suggestion entry by accident every now and then because the mouse cursor often jumps around a pixel or two and you have a semi-automatic cross-domain attack.
Component: History → Places
Flags: blocking-firefox3? → blocking-firefox3+
QA Contact: history → places
P.S. I'd appreciate it if you didn't kill the JS url icons in the process as these are at least in my opinion incredibly useful, as they allow for bookmarklets with an icon in a way that doesn't need a special API or Addon and doesn't break anything. Example: http://tapper-ware.net/devel/js/bookmarklets/ (Don't try to drag the two buttons: Click them, then drag the tab title of the appearing description page to the bookmarks bar)
Sounds good to me...
Mardak's idea sounds great.
Assignee: nobody → edilee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #304911 - Flags: review?(dietrich)
Summary: History can fill FF3 addressbar suggestions with unwanted bookmarklets that look almost like real pages but execute in the current page's scope. → History can fill FF3 addressbar suggestions (awesomebar) with unwanted bookmarklets that look almost like real pages but execute in the current page's scope.
Well, already providing a pref to turn it on and off is providing quite a bit more functionality than now. Dietrich, do we want a pref at all?
Definately... but is there a reason not to add two prefs? I mean, the about:config list has reached the point where you can't navigate it without the search years ago . And if the prefs are only read at startup, it shouldn't really affect performance either, right?
Comment on attachment 304911 [details] [diff] [review] v1 this is fine for now, better to start with this constraint and enhance as appropriate afterwards. the suggestions in comment #12 should be filed as a followup bug.
Attachment #304911 - Flags: review?(dietrich) → review+
Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.283; previous revision: 1.282 done Checking in toolkit/components/places/src/nsNavHistory.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v <-- nsNavHistory.cpp new revision: 1.259; previous revision: 1.258 done Checking in toolkit/components/places/src/nsNavHistory.h; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v <-- nsNavHistory.h new revision: 1.141; previous revision: 1.140 done Checking in toolkit/components/places/src/nsNavHistoryAutoComplete.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v <-- nsNavHistoryAutoComplete.cpp new revision: 1.43; previous revision: 1.42 done RCS file: /cvsroot/mozilla/toolkit/components/places/tests/unit/test_417798.js,v done Checking in toolkit/components/places/tests/unit/test_417798.js; /cvsroot/mozilla/toolkit/components/places/tests/unit/test_417798.js,v <-- test_417798.js initial revision: 1.1 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta4
*** VERIFIED Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre -Mike
verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032606 Firefox/3.0b5 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-GB; rv:1.9b5) Gecko/2008032604 Firefox/3.0b5
Status: RESOLVED → VERIFIED
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
You need to log in before you can comment on or make changes to this bug.