Closed
Bug 461820
Opened 16 years ago
Closed 13 years ago
searchbar history should be stored uniquely in Satchel
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
RESOLVED
FIXED
mozilla10
People
(Reporter: Dolske, Assigned: MattN)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [sg:moderate])
Attachments
(1 file)
(deleted),
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•16 years ago
|
||
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.
Comment 2•16 years ago
|
||
Bug 270697 made stealing this data a little bit harder, but I was wrong in assuming that it was now impossible, given bug 381681.
Updated•16 years ago
|
Whiteboard: [sg:moderate]
Reporter | ||
Comment 3•13 years ago
|
||
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 | ||
Comment 4•13 years ago
|
||
Assignee: nobody → mnoorenberghe+bmo
Status: NEW → ASSIGNED
Attachment #563249 -
Flags: review?(dolske)
Reporter | ||
Updated•13 years ago
|
Attachment #563249 -
Flags: review?(dolske) → review+
Assignee | ||
Comment 5•13 years ago
|
||
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?
Assignee | ||
Comment 6•13 years ago
|
||
(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
Comment 7•13 years ago
|
||
Merged to m-c: https://hg.mozilla.org/mozilla-central/rev/c244aa48ba1b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•13 years ago
|
||
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]
Updated•11 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•