It's probably slightly easier to fool someone into bookmarking an open data: page than a bookmarklet link (but that's just a right-click away) . We can't take away bookmarklets but we can probably block this without breaking any current legitimate use. A fix might fall out of bug 255107, or we could have the bookmark code clear the current content before loading the data: URL as we do when loading them from external apps into existing windows (the old default).
-> http://www.heise-security.co.uk/news/85728 requesting blocking 188.8.131.52
I don't know what the best solution is. As far as I know, string changes are not allowed for branch, so alert/confirm dialogs are not possible for branch. If someone knows a good solution, I'll be happy to give it a try.
Ah, yeah, that makes sense. But for the single bookmark, that still would mean that nothing happens. Someone should say if that's ok or not. And I guess for trunk it might be better to add some annoying warning dialog like IE does.
For the single-bookmark case (or the "none of these tabs can be bookmarked" case) I'd rather see an error dialog than a security dialog. Perhaps something simple like "This page cannot be bookmarked". A security dialog might be appropriate for adding a bookmarklet through "Bookmark this link...", but that's a discussion for another bug (bug 28387).
Might need similar changes to other apps....
Indeed. Camino is also vulnerable.
Camino version of this bug is bug 372020.
SeaMonkey version of this bug is bug 372035.
Mike: please find an appropriate person from your team to assign this to.
Assignee: nobody → mconnor
No one likes this approach, FF devs would prefer waiting until we have a better solution.
waiting for a trunk fix, pushing out to the next branch release.
Flags: blocking184.108.40.206+ → blocking220.127.116.11?
moving out bugs that don't need to block b1
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Following suit on the branch, need a trunk fix first.
Priority: -- → P3
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Right, that's what I was proposing. I forgot about the drag and drop case that Chris mentions in comment 23, though. That change wouldn't help with the drag and drop case, which is just as easy to convince the user to do. In fact drag and drop is the most common way to "install" a bookmarklet, so any attempts to cover-up that hole will surely draw the ire of bookmarklet authors and users.
We won't take this for 18.104.22.168 because the fix we want might be more complicated. Dan will comment on it shortly.
Wanted, but not going to block on something where we don't have a viable solution in place that won't destroy bookmarklets as useful things.
Assignee: gavin.sharp → nobody
Priority: P3 → --
Target Milestone: Firefox 3 beta3 → ---
(In reply to comment #34) > We won't take this for 22.214.171.124 because the fix we want might be more > complicated. Dan will comment on it shortly. (almost 2 years later, Dan didn't comment) How should this issue be addressed ? Is the security popup the considered solution ?
Whiteboard: [sg:want] → [sg:want][xss with nearly normal user interaction and no upside]
I don't think there's any UI work here, removing uiwanted.
You need to log in before you can comment on or make changes to this bug.