The reason the TTL for History data is 60 days is basically simplicity in the server as well as in the database pruning algorithm. 60 days TTL accommodates the average user’s browsing patterns with room to spare.

Regardless, here is how Sync deals with History. First, each History record is encrypted separately (not into a bundle like tabs). When the Sync client (in Firefox) connects, it uploads the changed data of the last 30 days of History (again, in encrypted records) and the *server* marks when they were uploaded and flags them for deletion after 60 days. Since the records use unique keys based on a hash of the visited URL, records are updated if they’ve been modified (again, the updated data is *also* encrypted, so Mozilla has no idea *what* is being updated or what the update contains). When another device connects, it only downloads the most recent 5000 History entries using the server-side time-stamps on data records (meaning no identifiable data is visible on Mozilla’s end).

Related to that, given the client-side encryption, what information did you have to tell you which history entries to prune, for your original plan of selectively pruning server-side? Does some kind of sequence number exist for history entries? (I would hope that no date information exists; even the timestamps on history entries expose private information, namely that the user browsed the web at that time.)