User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:188.8.131.52) Gecko/20061204 Firefox/184.108.40.206
See this demonstration:
(In reply to comment #1)
Icons probably won't suffice - novices would be most vulnerable, anyway, and they might not be able to tell a difference.
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).
> It's probably slightly easier to fool someone into bookmarking an open data:
> page than a bookmarklet link
(In reply to comment #5)
It is still possible to implement bookmarklets by manually entering or right-clicking the link, but that seems sane.
requesting blocking 220.127.116.11
Created attachment 256397 [details]
Created attachment 256474 [details] [diff] [review]
So there are different things that could be done:
3- Do what IE does and store the last seen "physical" page (might be tricky to do, haven't figured that out, yet)
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).
Created attachment 256620 [details] [diff] [review]
branch patch v2
Ok, this includes Jesse's suggestions.
When bookmarking a single page, you get the alert.
I filed bug 371923 for adding a warning dialog, like IE does.
Might need similar changes to other apps....
Indeed. Camino is also vulnerable.
Not that I know many people who have data: bookmarks, and it seems the bookmarklet case is being addressed, but it's not clear to me from reading the bug so far what the eventual effect will be.
Tested on firefox 18.104.22.168.
Camino version of this bug is bug 372020.
SeaMonkey version of this bug is bug 372035.
Where does dragging a bookmarkable item fall into the use cases for this bug? Is it enough of a direct action to be "OK" to let happen in all cases?
I realize you will not get the extreme cases of having a suspicious tab burried in the middle of a tab group, but it is a bookmarking action with no current path for UI or warnings.
Mike: please find an appropriate person from your team to assign this to.
(In reply to comment #24)
> would it suffice to force the add bookmark dialog to appear when bookmarking
It does appear, but (in Firefox) only shows the page title not the URL itself. Not that naive users would know what a data: url can do anyway.
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.
We could take a better approach to fixing this on the trunk, perhaps by just using a dialog as suggested. That's the "uiwanted" part, I guess.
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 22.214.171.124 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.
*** Bug 528772 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> We won't take this for 126.96.36.199 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 still think it would be productive to fix the vector shown here, seems like a low effort:
For data: URLs, fixing bug 656823 would be better than e.g. refusing to bookmark.
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.