Closed Bug 461820 Opened 16 years ago Closed 13 years ago

searchbar history should be stored uniquely in Satchel

Categories

(Toolkit :: Form Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla10

People

(Reporter: Dolske, Assigned: MattN)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [sg:moderate])

Attachments

(1 file)

Search history from the search box is simply stored in Satchel with a field name of "searchbar-history". This has two unfortunate side effects:

1) You can't easily clear form history and search bar history separately, since they're not quite independent.

2) If content uses <input name="searchbar-history">, history for that field will be mixed in with search box history.

The reverse of #2 seems a bit disturbing -- search box history will be available in content. I'm not sure this is a huge problem, because we already share form history across sites (it's only indexed by field name). Perhaps having this span content/chrome is too much, though.

OTOH, at some point in the future I'd like to have smarter form history matching -- aka awesomebar -- and it seems like having searchbox history available for that would be useful.
yeah, combined with one of Jesse's "navigate through this maze while I steal your auto-fills" PoCs, this is potentially a significant privacy breach.
Bug 270697 made stealing this data a little bit harder, but I was wrong in assuming that it was now impossible, given bug 381681.
Whiteboard: [sg:moderate]
Probably the easiest short-term (!) fix here is to just blacklist web site form autofill when the field name == out special chrome field name.

In the long term I'd still like to be able to have form inputs suggest completions regardless of origin, but that's a security issue we can take up if/when that feature ever tries to land.
Assignee: nobody → mnoorenberghe+bmo
Status: NEW → ASSIGNED
Attachment #563249 - Flags: review?(dolske)
Attachment #563249 - Flags: review?(dolske) → review+
What's the procedure for landing this fix since it's sg:moderate? I couldn't find a policy about this. Do I include the bug number and summary in the commit message?  Can I land the patch and test together on mozilla-inbound?
(In reply to Matthew N. [:MattN] from comment #5)
Jesse said to land the fix now and test separately later.

Fix landed on inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c244aa48ba1b

When is appropriate to land the test?
Flags: in-testsuite?
Whiteboard: [sg:moderate] → [sg:moderate] [test still needs to land]
Target Milestone: --- → mozilla10
Merged to m-c:
https://hg.mozilla.org/mozilla-central/rev/c244aa48ba1b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Tests: https://hg.mozilla.org/integration/mozilla-inbound/rev/78e4144065cc
Flags: in-testsuite? → in-testsuite+
Whiteboard: [sg:moderate] [test still needs to land] → [sg:moderate]
Tests: https://hg.mozilla.org/mozilla-central/rev/78e4144065cc
Blocks: 906163
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: