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 184.108.40.206
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.
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.
moving out bugs that don't need to block b1
Following suit on the branch, need a trunk fix first.
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 220.127.116.11 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.
(In reply to comment #34) > 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. (almost 2 years later, Dan didn't comment) How should this issue be addressed ? Is the security popup the considered solution ?
I don't think there's any UI work here, removing uiwanted.
Not sure why this was nominated for e10s triage, it's not e10s specific.