Slashdot Mirror


Encrypting Google Calendar With Firefox Extensions

mrcgran writes "IBM's Nathan Harrington has an interesting essay on using open-source tools to ensure privacy on Google Calendar: 'Today's Web applications provide many benefits for online storage, access, and collaboration. Although some applications offer encryption of user data, most do not. This article provides tools and code needed to add basic encryption support for user data in one of the most popular online calendar applications. Building on the incredible flexibility of Firefox extensions and the Gnu Privacy Guard, this article shows you how to store only encrypted event descriptions in Google's Calendar application, while displaying a plain text version to anyone with the appropriate decryption keys.'"

3 of 52 comments (clear)

  1. IBM pays people for this stuff...? by HappyUserPerson · · Score: 4, Insightful

    I get why this article is on Slashdot (it's kind of cool), but why would IBM pay employees to work on this type of thing? It's impractical for several reasons...

    Security & practicality:

    1. You must install an add-in to use it. You want to your encrypted calendar with some friends. You tell them "uhh, just install this arbitrary XPI." No thanks.
    2. No mention on how to securely transfer the private key to your friends. Email?
    3. From your browser, the add-in spawns a shell to run a Perl script which passes arbitrary content to gpg. Security much?

    Google:

    1. This component is dependent on Google not changing their page. How would you and your friends like to recompile each time Google changes their page?
    2. Who are you trying to protect your data from anyway? Google? They could change their page to by-pass your encryption and intercept new events as you post them. If you trust Google not to do that, what's the point? Just mark the entry as private and share it as appropriate...
    3. It goes against Google's business. Okay if just a handful of users encrypt their events, no problem. However, displaying a bunch of base64 encoded garbage messes up Google's ads. Which, you know, is virtually their entire source of revenue. In the unlikely event that this technique became popular, Google would be forced to shut it down.
    4. Google might shut it down anyway. It's a calendar. It's not for posting arbitrary base64 encoded data. If many users use Google calender for posting arbitrary binary data, calendar would quickly become a lawless file trading platform (think usenet) and create a performance, storage, and/or legal mess.
    1. Re:IBM pays people for this stuff...? by smallfries · · Score: 2, Insightful

      Under Security & Practicality you missed a few points:

      4. It leaks information. The encrypted version shows when you are busy and free
      5. There's no point using a 4096-bit key. Most calendar entries are 60 characters so the key size is overkill given there is probably less than 360 bits of entropy
      6. Calendar entries are highly regular, a dictionary attack would be tractable regardless of the key-size because of the limited input space

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
  2. Re:And the ads? by vain+gloria · · Score: 2, Insightful

    Are any of these extensions (CalendarEncrypt, Adblock Plus) against the TOS? As much as I believe that you should be allowed to do whatever you want on your computer, when your data is in the cloud the provider can always pull the plug so you better not ignore the TOS.

    The cloud is a lie. One we're better off not perpetuating at that. Our data is on Google's servers, under their control and used for their benefit. I realise you're referring unambiguously to this yourself when you talk about breaching their TOS, but I'm against embracing nebulous non-threatening jargon which obscures the true state of our personal information.

    As to your point, I have no idea whether these tools are against the TOS. Since everyone includes the proviso that their terms can be unilaterally revised at any time, there's no reason why they shouldn't become so in the future.