Closed Bug 405925 Opened 12 years ago Closed 12 years ago

ensure secure deletes for places.sqlite


(Firefox :: Bookmarks & History, defect, P2)




Firefox 3 beta4


(Reporter: dietrich, Unassigned)



(Whiteboard: [sg:investigate])

* ensure that secure delete is enabled
* quantify and document the details of how secure the deletes are
Blocks: 375898
in particular, we are talking about SQLITE_SECURE_DELETE

which we define here:



  /* Overwrite deleted information with zeros when the SECURE_DELETE 
  ** option is enabled at compile-time */
  memset(&data[start], 0, size);


  /* If the SQLITE_SECURE_DELETE compile-time option is enabled, then
  ** always fully overwrite deleted information with zeros.
  rc = sqlite3PagerWrite(pPage->pDbPage);
  if( rc ) return rc;
  memset(pPage->aData, 0, pPage->pBt->pageSize);



note, we are just memsetting to zero.

perhaps we want an upstream sqlite feature request for "more secure" delete, that would write out random data (and write to disk x times) or what ever the right thing to do is?

note, other mozilla (and non-mozilla) sqlite consumers might want this, for example, nss.
we might care about this for content-prefs.sqlite, cookies.sqlite, downloads.sqlite, formhistory.sqlite, search.sqlite, search.sqlite, etc.

note, SQLite 3.5.3 (the current version) still uses memset, so I've logged a feature request.  See

In addition to writing out random data (instead of memset() to 0), it appears that we're also supposed to do this and write to disk several times.  That part of "secure delete" may not be as easy (as just the random data part.)
perhaps this bug should move to toolkit / storage?
I don't think it's worth the effort and perf hit to attempt to protect Firefox profile data from forensic data recovery.  It's really hard to get right, especially at the app level, and we don't want to give users a false sense of security by trying.

Any given data is likely to appear in many physical locations on the disk due to swapping, journaling, automated backups, and continuous defragmentation [1].  When you try to overwrite part of a file, you find yourself fighting against optimizations in operating systems and in disks themselves [2].  Data also appears in RAM, which can survive power cycling [2] and is even harder to control.

Zeroing sounds reasonable; it will protect against casual snooping, and depending on the file system, might protect against forensic software.  But I don't think we should go beyond zeroing (e.g. multiple overwrites) in an attempt to defeat forensic analysis of the physical hard drive and RAM.

Extremely paranoid users can use operating system features to encrypt an entire hard drive or automatically do multiple overwrites every time data on disk as it is changed.

I agree with Jesse. It's really ugly to try and solve this problem in the app. It's easier and more robust to handle this in OS, by using encrypted folders/filesystems.
thanks jesse / justin.

Dr. Hipp agrees:

"I don't think writing random bits or writing multiple times
will help any.  There are too many layers (operating system,
file system, disk driver, and disk controller) in between
SQLite and the oxide for SQLite to really have much control
over what is truly stored on media.  SQLite might write the
same page multiple times, for example, but the OS would
likely coalese the writes into a single write.  Perhaps we
could force multiple writes using fsync() but that would be
a *huge* performance penalty.  And even if we did, just 
because we write to the same offset in some file does *not*
mean that the information is written to the same place on 
mass storage.  Some filesystems (YAFFS) intentionally spread
the writes around to different places for the purpose of
wear leveling.  And even if the operating system doesn't do
this, then on-drive disk controller might.

What problem, exactly, are you trying to solve?  The existing
SQLITE_SECURE_DELETE is adequate to prevent casual snooping.
It is not, as you observe, adequate to prevent snooping from
major governments.  Against a determined adversary, the only
sure defense is to physically shred the disk platter."
Back to the original two issues:

> * ensure that secure delete is enabled

I've ensured it by code inspection.  

Were you thinking of compile time:

#error "Zoinks, not building with secure delete" 

Or were you think about a test?  We might be able to develop a clever test to create / write / delete / quit and then attempt to casually snoop the file.  (I wonder if sqlite already has a test case for this?)

> * quantify and document the details of how secure the deletes are

I believe this bug now does this.
Note, dcamp (for urlclassifier) and others may want to figure out a way to make secure deletes "per database" (with a pragma, maybe) instead of global per compiled instance of the code.
Since this is a dependency of bug 375898, marking P2 so it stays on our radar for Fx3 triage/tracking.
Flags: blocking-firefox3?
Priority: -- → P2
Target Milestone: --- → Firefox 3 beta4
Agree with Seth in comment 7 that the intent of this bug appears to be satisfied
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [sg:investigate]
Flags: blocking-firefox3? → blocking-firefox3+
Verified per comment #10
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.