You see he's ok because he writes code and drug laws are bad, man.
I'm disgusted by people trying to claim he is anything but a horrible person while trying to brush away the fact that he paid for people to be murdered.
Sure, no one was killed, but that's only by the grace of his stupidity, and massive ego.
HN might hate the war on drugs and love people that write code and live in the valley but its embarrassing that self described smart people could fall so low as to latch on to that while ignoring the undeniable horrible things he did. He wasn't a smart guy, he wasn't a good guy, its like people didn't read the transcripts where they went through his journal detailing everything he did.
> You see he's ok because he writes code and drug laws are bad, man.
Given that there were people arguing Hans Reiser was unfairly convicted even after he confessed to murdering his wife, and suggesting that imprisonment was a waste of his talents, I am not particularly surprised by any expression of nerd supremacism any more. Saddened, but not surprised.
And even then there were people arguing he should get special treatemnt because "he's a programmer, don't lock him up with thugs, let him contribute his genius, man!"
> while trying to brush away the fact that he paid for people to be murdered
Allegedly, there's not actual evidence this actually happened... nor did the prosecution attempt to go after those charges... nor has anyone traced the actual people who were supposedly murdered (their identities don't exist -- they aren't real people), nor has anyone validated the bitcoin transactions that supposedly transferred $750,000
The evidence that he paid for murders is as damning as the rest of it, he kept the chatlogs and made diary entries about _paying to have someone murdered_, Please.
The fact that he was scammed and no one was murdered is irrelevant, completely and utterly, and only goes to show he's not as smart as he thought he was. He's still just as evil for trying and it more importantly celebrating when he was told it was successful.
Agreeing with tptacek, again, pretty sure your last statement is false.
Since I'm the first security person here I might as well just start off the anti-javascript crypto thread:
Their claim "Zero Access to User Data" is completely untrustable. There is no realistic way to be confident that this time you logged in you didn't get served backdoored javascript that sends that 'local browser only' password up to the server. This already happened in the past with Hushmail so you should keep this attack in mind.
Any system that is based on crypto code that you get in this way is inherently silly and doesn't buy you anything if the server is malicious, which is all this feature is billed as. At best you gain nothing, at worst you gain false confidence in your security.
The Swiss bit sounds interesting, but I know nothing about Swiss law and I don't see how that would stop active exploitation by an outside state actor from breaking into their service and exploiting the fact that the crypto code is sent down every time you page fetch(after a login even, how nice for targeting!). That's one of the NSA's major roles, I doubt they'd have much issue pulling it off if they wanted/needed to.
The impact of state actors trying to do MITM for the purposes of JavaScript injection won't be so bad once all major browsers support HPKP[0]. It looks like they're already using HSTS.
I agree with everything you've said though, I've ranted about it on many occasions. The underlying problem is one of making changes noticeable (which is what HSTS and HPKP do for TLS). Ideally you want a way to isolate the sensitive components of the application (anything with access to plaintext or keys), and have them open sourced, vetted, and undersigned by respectable third parties. Unfortunately you can't do this in practice today even in the traditional desktop or mobile app software models, which mostly sign only to prove authorship. In the browser it's hard to see how it would be even be possible... an in-browser app/plug-in model like Chrome Store wouldn't really help without a delayed update channel that gave any third party canary systems time to review and sign-off any changes. And ultimately you're still going to be gluing your secure box to your insecure form controls.
Perhaps what we need is a system like Moxies Convergence or the EFFs SSL Observatory but for HTML and JS, because I don't see "JavaScript and HTML pinning" really cutting it.
I don't think any of these challenges make ProtonMail a mistake though. It's certainly always going to be better than GMail, which depends on access to your message plaintext for advertising, and therefore can never provide privacy.
Sorry I wasn't clear, I wasn't talking about someone MiTM but someone actively compromising their servers.
It would be nice to have a corpus of javascript and HTML from these sorts of sites so that someone could go and look for these kinds of attacks but I doubt you can do anything proactively without destroying the ability to launch features/do experiments. Certs change rarely so pinning works, content not so much.
They don't make ProtonMail worse per se but I'm a little worried when people bill bad security ideas as core security features, it makes me cautious about anything else that could be problematic.
>I don't think any of these challenges make ProtonMail a mistake though. It's certainly always going to be better than GMail, which depends on access to your message plaintext for advertising, and therefore can never provide privacy.
No email provider whose main interface is a browser ever can provider you with those promises of privacy though, at least GMail doesn't claim it when they can't really promise it.
I quit gradschool a month after publishing this so can't comment on what Suman is currently working on, but it looks like it is still mostly my code for generation.
I didn't write the script for using polarSSL but I wrote most the other ones,the testing harness, cert generation and cert crawling, and I can say that polarSSL loved to crash on my weird certs. I almost wanted to remove them from the tested list for being so unreliable.
Case 1: You delete my message once I read it
Case 2: You simply report it as deleted once I read it(but keep it stored)
Is there any way for us to distinguish the two?
The more important part of my post was "What stops Delete.im from saving your messages?". What if you get an order from your government's legal apparatus to save my messages?
>The main thing to point out is that by uploading a message it is still possible to get access to your message in a permanent state either by screen shotting or finding the image source. The tool exists for people who have no interest in keeping the messages you send. Please don’t blame us for message leaks.
So I can't send this to people I dont trust and I have no way to guarantee that delete.im doesn't save my messages. What exactly do I gain from this over just clearing my local logs?
As as security person these 'forgetful' services really bother me because people tend to claim that they offer the world but there is no way to actually guarantee any of it. More importantly there _fundamentally_ isn't a way to prevent the other side from saving the message. Without end-to-end encryption there isn't a way to make any claims about what is stored by the service.
And before you recommend end-to-end encryption in a browser based service don't forget that we know exactly how those get MITM'd: When a warrant comes in you serve that person a different webpage with broken encryption/leaks.
This is the same rant I had about Snapchat, and the same rant I'll have about the next forgetful .* service. The only claim they have to actually being forgetful is a promise and you'll never see them stand behind any actual privacy claim because they cant and they know that.
tl;dr Please stop making 'forgetful' services or 'view only once' services.
These services deeply anger me and it is pretty hard not to launch into rants when I see them unfortunately.
I have an honest question for you HN: Do you not see these services as fundamentally broken? Would it be worth writing a long post somewhere breaking down exactly why these services are broken at best and bad in general? I'm deeply afraid that the public will start seeing these services as providing actual privacy and start using them as such.
Pencilo, I can really see your point but I that's not why we made it.
Delete.im is not supposed to keep you safe from hackers or NSA. It's only to prevent sensitive data from lying around your chat history or emails. That's pretty much it. It's a completely different concept from snapchat and the others.
This isn't about hackers or even the NSA. The NSA is like the final boss. This isn't even passing level one.
The point is that you don't actually offer me any more privacy than if I just used the 'Off The Record' feature of many chat programs or deleting my logs.
Are 'off the record' conversations deleted the second they fall off your chat history? I doubt it. Are delete.io messages deleted once the server started returning 'this message is unavailable'? I doubt that too. More importantly I can't verify if you delete them then or even at all.
Now my sensitive data is not lying around in my chat history or emails, it is lying around on your server. If my logs are only stored locally I can delete them. Likewise if I control my email server I can delete them.
How can I prevent sensitive data lying around on your server? Are you more trustworthy than my email? Why?
The comparison to Snapchat and friends comes from the 'limited number of views' or 'viewable only for a time' feature. These features are trivially broken at best and misleading to non-technical people. These are marketed as privacy features and they're a lie.
If you want to bill your service as a pastebin style service that removes files after a time then go right ahead, I will not have issues with that.
If you want to claim that those features are to protect sensitive data? Then I have a problem. Services built around working with sensitive data need to be held to a higher standard.
