Friday, March 20, 2009

Gmail discards and the law

Recently I was composing an email in gmail and - like I sometimes do - decided to press the discard button and not send the email. But not before gmail indicated that it had saved my message. After I discarded the email, I checked my "Drafts" to see if it showed up there. No, as I expected. But where do they go? Anywhere? Are they in some kind of Google never-never land?

And more important: are they retrievable when someone comes to Google with a court order for someone's emails? Are they stored but Google doesn't release them because technically they are not email? Might they be of value, perhaps revealing information someone had decided was too hot to send in an email?

These things are not clear from gmail's Privacy Policy Notice and Google's broader Privacy Policy.

And no, I wasn't concerned about any of my own discarded emails. :-)


shailen said...

... probably part of a bunch of random 64K blocks waiting to be reclaimed ...

Regarding luSql, GREAT product, btw ...
Actually, I did not know of any way to contact you (I've sent you a mail earlier). You must be busy, but I have a requirement for your luSql tool:
1. Since it can be used for any database accessible through jdbc, can I use Oracle instead of mysql?
2. I'm in the middle of a Grails app that does full text searching using Compass abstractions over Lucene - unfortunately, the indexes produced by luSql are not readable by the Grails app: is there a place I can get access to the source code so that I can try and figure out how to make my app work with luSql indexes (Currently, indexing using Compass/Lucene takes upward of 3 days(!), while luSql does the same job in 2 hours!

Glen Newton said...

Thanks for the feedback on LuSql.
Your questions:
1 - it can be used with other databases besides LuSql, including Oracle. In order to do this, you must have all the dependencies (including the Oracle JDBC driver) in the CLASSPATH, and then invole the application directly, NOT via the JAR. You also need to use the v0.901 version of LuSql which fixes an Oracle-related bug (see
2 - The source code is available here: However, if you can email me ( a description or URL location of a small instance of this Lucene index (created by Compass), I can try and figure out what the problem is. If we can figure this out, then LuSql can be a viable alternative to the slower method you describe. :-)