* Posts by MrPrivacy

9 publicly visible posts • joined 15 Jun 2012

Lavabit bloke passes hat for open-source secure email master plan


While awaiting a Dark Mail service, try ThreadThat, a free end-to-end encryption service for sharing your most sensitive electronic secrets.

Snowden's email provider gave crypto keys to FBI – on paper printouts


Thanks Mr. Levison

His last name is actually Levison. I respect what he did, but I would not be willing to go to jail if I was served with a secret order for my secure messaging site, ThreadThat. Currently, I have posted a statement on the login page that I have not received any secret orders and should the notice disappear, users should take heed. I hope that Mr. Levison does not serve any jail time and that his actions result in change that benefits us all.

Oi, journos. Try NOT to get hacked again. Lots of love, Twitter



2FA is somewhat over-rated. The only thing it really protects against is someone logging into your account from an untrusted location after they have your password. It normally doesn't protect against someone resetting your password if they have control of the email account associated to the account being compromised. First, the attacker resets your email password. Then they reset your social network or bank or other account password which usually requires clicking a link sent to the associated email account (which they have taken control of). It may also require answering a challenge question, but the point is, it usually won't trigger 2FA. Once they have control of the account, they can turn 2FA off. Perhaps what we need is the option of not allowing a password reset at all (at least on sensitive accounts) only a password change when logged in. Assuming one uses different passwords for email vs. the accounts the email is associated with, they at least have a chance of retaining control. This solution assumes you can remember your passwords or store them someplace secure. Otherwise, a forgotten password may render the account useless.

Silent Circle aims for email that's as secure as it gets


Re: Expensive?

Cost, IMHO, is not the primary deterrent to widespread use of encryption tools. I own a website called ThreadThat which provides a sophisticated yet easy-to-use means to encrypt messages and files in a threaded conversational format. Even though it is ad free and cost free, it will never be popular. Why? I believe there are 3 primary reasons. (1) The general public either does not perceive that there is a threat or does not care if their email is compromised because they don't use email to exchange sensitive material. (2) When the average person hears the word "encryption" they immediately assume it is too difficult to use and for the most part, they are probably right. (3) Encryption only works when all parties are using the same toolset and it is very difficult to convince everyone you communicate with to switch. Cost is definitely a factor, but there are free solutions out there if one can get past all the other barriers.

Rotund Mega baron Dotcom offers bounty for breaking his crypto


It would seem that the popularity of MEGA is directly proportional to the ease with which pirated material can be shared. If it were just about being able to encrypt and share files with a small group, then my site, ThreadThat dotcom, would be more popular. It has been my experience that privacy is not a motivating factor in the use of file sharing services.

Google's Drive + Gmail: A 10GB Dropbox killer


Re: no such thing as "free" storage

I offer a service for sharing encrypted files and messages for free. It is ThreadThat.com. Perhaps this will help those that need the extra protection of encryption.

PGP Zimmermann teams with Navy SEALs, SAS techies in London


Re: 3 questions

I have struggled with this for years. In 2009, I created ThreadThat.com with the intention of providing a secure means of conducting online encrypted threaded conversations. TT is free service with no ads. I offer and support it for free because I believe there needs to be a way for the average non-geek to protect against eavesdropping and accidental discovery. Protecting against requests by law enforcement requests is a sticky wicket. The way TT works is that users can create their own pass key (a different pass key for every thread if that's what's desired). The user-supplied pass key is used to encrypt the system generated pass key used to encrypt the thread and any attached files. The only way someone can view the thread is if the creator of the thread authorized them and gave them the pass key. Great so far. But what if we were served with a court order that stated we had to compromise an account by capturing the pass key for a thread as it is entered on the web page and then decrypt any thread that was encrypted with that pass key and provide it to law enforcement? And we could not give any warning to the thread owner? We made a conscious decision to create a service that was easy to use acknowledging that a court order could force us to compromise a user's privacy. It is a major challenge to create an app the provides absolute privacy and can be used by my mother. I have considerable respect for any company that can do so.

Russia launches internet blacklist to protect the kiddies


I wonder if The Register is on their blacklist? If not, then I hope they see my post in Russia. My site, threadthat.com, will not be on that list because it is not well known, yet it is a powerful tool in the war on privacy. Free end-to-end encryption with user-controlled pass keys to protect all messages and files shared online. I hope it helps someone.

PGP founder, Navy SEALs uncloak encrypted comms biz


Re: Interception

@Interception - I developed a secure messaging app and launched it about 3 years ago. It uses a model whereby all messages and files sent to another user of the app via the app interface are encrypted over SSL (AES128) while in-transit and encrypted at-rest (AES256) in a MS SQL Server DB. Every communication thread gets it's own encryption key and the encryption keys are then encrypted by a passkey of the thread owner's choosing. Passkeys are persisted on the server as well, but they are encrypted by the plain text version of the user's password, which is not stored on the server. Passwords are only stored as an MD5 hash which cannot be reversed into its plain text equivalent. This allows for the passkeys to be accessible by the app only when the user is logged in (mainly as a convenience so that the passkeys do not have to be re-entered every time a thread is revisited. The app has regular users, but not a significant user base. It is hosted in the US, but it is unlikely that it will ever be affected by the "must have a backdoor" rule due to the low number of users. If it ever did, I would most likely shut the site down. You can find this site by Googling "private secure encrypted". It is the first site listed in the organic search results. In the spirit of transparency, the FAQ has considerable detail on how the app works. Unfortunately, it is not open source. It is written in VB.Net.