Tag Archives: information security

Dmail enters ring for making users feel like they have control of their email

Dmail is now in the Chrome store. Delicious Science, which last year acquired social bookmarking service Delicio.us, has released this Chrome extension that provides Gmail messages with the ability to self-destruct.

After installing the extension, Gmail users can send a message to anyone, whether or not that person uses the Dmail extension, and configure the message to deny access after a period of an hour, a day, a week, or never. In addition, a “Revoke Access” button provides a way to immediately disable access to a protected message.

If the recipient has the Dmail extension, he or she can read the message in Gmail until it expires or is revoked. Dmail has designed the extension so that the neither Gmail nor Dmail servers ever receive both the decryption key and encrypted message. Only the recipient and sender can read the email legibly.

The accessibility of Dmail’s source code — Chrome extensions are just collections of JavaScript, HTML, and image files — may help security skeptics decide whether or not to trust Dmail. The software relies on Gibberish-AES, a JavaScript library for OpenSSL-compatible AES CBC encryption.

However, the presence of JavaScript modules for tracking and analytics suggests this software isn’t intended for people who want serious security; rather, it appears to be aimed at people who would like to feel they have more control over their data than regular email affords.

Concerns about real security would include the relatively weak encryption being used in the package. A further question is what is yet the friction offered to authorities who seek the keys to a message from all of the parties involved. But the package has addressed accessibility concerns with the wider community.

Don't put your auth tokens in your R source code

I’ve been working with the great open data source which is BLS. You can get some of the data with the v1 API, but to use the v2 API you need to have a token. That simply takes a registration and a validation. Cheers to BLS. And cheers to Mikeasilva

So, now you have your API token and you want to go grab some data into some R and cook it up. So you might do something like:

payload <- list('seriesid'=c('LAUCN040010000000005','LAUCN040010000000006'),
                'registrationKey'= 'MYVERYOWNTOKENREGISTEREDTOME')
response json

Sadly, when you check your code into github, or share it with someone else, they have your API token. A better way exists, padawan. Go to your home dir

> normalizePath("~/")

in the R console will tell you if you don't know. So will a simple

in a shell, but if you know what a shell is you knew that already :). In your home dir, edit a new file called .Renviron, unless it already exists, which questions why you are reading this post. In .Renviron, you can enter key-values per line:


and, beautifully, you can grab any and all of these values in your R code with the following:

myValueOfInterest <- Sys.getenv(KEY)
[1] "character"

so you can easily pass it as a parameter to those connections. All much better than embedding it directly into the source. N.B.: If you happened to include your home dir as part of your project dir, don't commit the .Renviron. Also, go change your project directory to something more sensible like a child dir. While you're at it, look at some of the other methods available via Sys, e.g.:


Now your interaction with the v2 API is more like:

payload <- list('seriesid'=c('LAUCN040010000000005','LAUCN040010000000006'),
                'registrationKey'= BLS_API_TOKEN)
response <- blsAPI(payload)
json <- fromJSON(response)
response json