News for hackers. Stuff that matters.
[dead]
Re:ProtonMail takes aim at Google with an encrypted calendar by techsupporter on Monday December 30, 2019 @02:29PM (#21915964)
> Can I have the creds to your Fastmail account then? I'm curious what you're up to these days.

This is just as specious of an argument as the retort of "ah so you claim you have nothing to hide but you have curtains on your windows, checkmate, I am very smart."

The issue is not one of what specific measures are or are not taken, it's about having the informed choice to make decisions based on information use. I wager that a lot of people would make the choice to pay with actual cash when shown the actual cost in data of how their personal information is being used. But, conversely, a bunch of people probably don't truly care or mind, and the loss of information control is worth less to them than the loss of money to be paid.

That doesn't then imply that a person has zero care about the information under their control, nor that their refusal to give you control of that data makes them a hypocrite.

[dead]
Re:ProtonMail takes aim at Google with an encrypted calendar by techsupporter on Monday December 30, 2019 @03:32PM (#21916437)
No, I didn't, and I think you know that but you're trying to bolster a point you know isn't on the mark.

You showed your true motivations in your reply to someone else:

> If we're talking in hyperboles, then let's go all the way, right? Or 'public' means 'eventually public'? Or what?

We're not talking in hyperbole. At least, most of us aren't. We're trying to discuss reality as it is on the ground.

The person you replied to before said to imagine the contents of my e-mail box as though it is a public record. To imagine does not make it so. I imagine myself as James Bond whenever I put on a suit coat and tie; I am not James Bond. I can imagine my e-mails as ones that, through no intent of my own, are exposed and made as part of the public record but treating them as though that possibility might happen does not implicitly make them public. It also doesn't mean I don't want them to remain my own secure property.

Re:ProtonMail takes aim at Google with an encrypted calendar by tptacek on Monday December 30, 2019 @02:25PM (#21915939)
This is not a very strong argument. Here's a specific refutation: the credentials to their primary email account are likely equivalent to the credentials of many other services that they use, because of password reset. None of those emails are encrypted, or ever will be; further, they're of little value just a day or two after they're sent. That commenter could coherently expect both that their mail spool would eventually be "public" and that it was safe to use email for password resets.

More generally: it's reasonable both to expect that your mail spool could eventually be public, and still not to want people to read it. There are things I don't want people to read, and there are things I need to be as careful as I can to ensure everyone can't read. Email works for the former and not the latter, and the latter is what encrypted messaging was invented for. Comparatively: I don't know many people who trust Twitter DMs, and "let's move this off Twitter DMs" is a constant refrain. But my answer to "can I read all your Twitter DMs" is still "no".

Re:ProtonMail takes aim at Google with an encrypted calendar by decebalus1 on Monday December 30, 2019 @03:04PM (#21916203)
No credentials is fine, I understand. As I specified, I would also settle with a dump of the emails. Public means public, right? If we're talking in hyperboles, then let's go all the way, right? Or 'public' means 'eventually public'? Or what?

The reason I'm asking is that the original comment is basically dismissing efforts to make personal productivity products more secure for the reason that they can become public at any time anyway, so why bother, right? Well fuck it, let's all pack it up and go home then, make email public and unencrypted and reallocate the development effort to something more lucrative like desktop apps in Javascript.