On top of that, while I wouldn't rely on this cryptographically, the relationship is one-way. Gravatar links email addresses to gravatar images, but it's not intended to link in the other direction, so the same is true for any information stored in the gravatar.
You can use my system to reply with encrypted text to a comment on a blog post without knowing the email address of the person you're replying to, only their gravatar image.
Get full disk encryption and be happy.
Full disk encryption and per-user encryption are good steps. But an accidental backup of Pidgin will still reveal passwords that would be safe if they bothered to use platform specific APIs for such storage.
The logs of the conversation can be protected in the same way, so I'm not sure what that has to do with anything. (Although you might wish to keep logs as plaintext, to facilitate backups, if you're not backing up the user's keychain info.)
> No. The Pidgin developers are generally open to, and would encourage integration with keyrings (KeyringSupport).
and then goes on to state that this is difficult to do, since Pidgin runs on so many different platforms, then stating again that they will happily accept such patches.
However, I find it understandable, that the devs don’t go out of their way to support use-cases they don’t feel necessary to support. On their systems, they trust the filesystem and are happy with that, if others don’t have that level of trust in their computer, that’s fine, but not necessarily their problem.
My point about the logfiles was that to store these in the keyring (rather than a key to the encrypted files) would probably annoy the keyring somewhat (at least the poorer implementations thereof), given that it is intended for use with few-byte passwords and not multi-megabyte logfiles.
As far as logs, do what everyone does when you can only store a bit of material: Store your bulk encryption key there.
With SaaS, you don't even have the power to say - Damn your improved version, blast your hip new design, I will stick with the old one, thankyouverymuch. You are always on Version Now.
The more intertwined your relationship and dependence on integration with related products, the messier the ensuing divorce.
This, to my mind, represents a far more inevitable reason to figure a way out of GMail.
Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA
Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA
Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?
ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)
I wonder why/when the connections end up RC4-SHA instead?
Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.
If I tell you a secret, and you tell someone else ... there's not a lot I can do a about that. If you don't want a third party to be able to hand over your plaintext (or store it) -- don't give them your plaintext (or a means to access your plaintext).
Similarly, if I send you a PGP encrypted email, I can't know if you decrypt that and hand it over to someone else (willingly or unwittingly).
-----BEGIN PGP MESSAGE-----
hQIMA13LrXtLThhwAQ/+LmYMzmaQ3Ui0AF5yRKzCVL/rXzUO3h+cKZVnA2AL/SAR PHcVjgGkm4BT3C8pokeTl+UQPqsBj/i3gteC0zi5QTMyXYxnkCC6915yVGON86BS E5i+pEpXIubnWiKZh81Ik+YARYnTqi+Ea5zW0OAzKmd48FX9m21MK0fKHcdjoYZk 56JaMbTgcSTcW2RIztwQr9EeTnf/XIHsIrhQuOGmZd9kTmbxn9mA+W2AKzgPmv7s Z+RUgEMrbyjNK+s2V/ibPE0CDpBKR6cleWRmAgEknu2Z8QaBIgiv+a64mKMbtL6I H8ZCcM1djgBmXvjfHRwJEvEKEIfJKVQ5Q1SMyskAkWt23CQIbd1toLzx/2e0F0O3 Zjppm+qnBhM6JUOnuc5L42uvZK1+0L3aT99UX5L2xOV8OdqgVto1u+d/Q35LUhNl jjslEKidDxhxFWVHJvVhY/4ogQZIq4WrEpDMoYjRzniECMi779MTl6UnX0vRjVuw 3dbXppozqhB40P7q9Om+ORXGfMrzpIRwABltY6NI5PPjeFgHeNZ/gAFxfWn6INYa mielp57irCYBAVaVIodds2EZNSJ3o8m8A/p4HKbuS8W1qDkU2QY4k+Ns27LY3EQM 0fXx6Ug5INql6vHQpj02W4q4S8A0FipS70WZIH4eWm/aLDWV4PT/0hMoGAhYPgvS lgFoQeoAPeaPJ+Tlb1WX5V7cePBH3EZte+0WcBwlZBBejCBNVAjpyFUG4jMcOv/B IPPa+7IFWjE/1kf7n6e+/OsqDjXWem2j5wJd8R0SJlJk97/VjGDvYAn2mdNCqQ43 /sLRy5oTgEE+kljtFriL5Qfdhkei5UR8RZxV3Yv3J+ARohj7JJovSi0psR9hVI5J BGL2emenig== =Eqf+ -----END PGP MESSAGE-----
It is still better than them not enabling it -- because if we can assume they do not log the data by default, on their own (aka: we can trust google) -- old data won't be accessible once a (theoretical) new warrant arrives.