51–60 of 154 posts
Earlier quoted context omitted.
Did you try this? https://protonmail.com/bridge/ Or did it not work for you?
Well, snap! Does Tutanota have something akin to this? I also have stopped using Tuta/Proton due to the IMAP incompatibility.
Is there an API for this calendar? I looked, but didn't notice anything. That's one of the G features that I like.
I'm a bit confused it took Protonmail more than a year yo develop ProtonCalendar. Is it really that difficult to develop?
Calendars are software so directly related to time, I'm not surprised. There are so many edge cases. Timezones, daylight savings time. The fact that so many regions don't use the same standards. We alter year length with leap years and doing things like adding leap seconds. Time is a nightmare to program around.
I moved over to Fastmail from ProtonMail a few weeks ago. I think if you value the encryption and privacy and don’t mind the lack of basic stuff like threading in the mobile app or IMAP integration, ProtonMail is fully worth it. That said, for me I just want a well featured email/calendar service that can replace gmail once Gewgle fucked us over with Inbox. Fastmail does that for me and provides a lot less friction w…
Earlier quoted context omitted.
Calendars are software so directly related to time, I'm not surprised. There are so many edge cases. Timezones, daylight savings time. The fact that so many regions don't use the same standards. We alter year length with leap years and doing things like adding leap seconds. Time is a nightmare to program around.
I somewhat believe our society would be easier if we had a better, simpler standard for time.
On a more serious note, a sibling comment asked if there's an API. And, really, for an API to work, we'd need to agree on some kind of data structures. Reading that spec, and having mucked with LDAP, IMAP and related specs, it really feels like we're still banging rocks together in how we define the semantics of data exchange.
This is a welcome development. ProtonMail has worked well for me. Now if I could only find a way to make a Pixel phone accept that email address instead of one of my several one-off fake name gmail addresses that I use for such things.
Don't integrate privacy-focused email service (hushmail/proton etc) into a non-private phone. Access it via the webmail interface. I've been asked several times to decrypt my phone at international boarders. If you leave things to webmail, unlocking your phone doesn't give them access to your email account, or even tell them where it is. All the TSA/Cops get is my "gmail-for-phone-2018@gmail.com" address that I haven…
I recently left ProtonMail and went back to Fastmail. My reason was that they will never be able to fully support IMAP and now CalDAV because of the encryption they use. I grew to accept that email is not for secure messaging and my paranoia of "I'm being watched" just went away. If you need secure messaging, use something other than email.
I came to a similar conclusion. You should write every email as if it were public, because it's entirely likely that it will be. They can be forwarded, made public through legal discovery, or exposed in a data breach (eg. Sony/North Korea). Forget security for a second, imagining every email as public record will make you more considerate and less biased writer. And from a business perspective, email should be viewed…
I'm forced to send proof of identity as well as proof of address via email. I'm receiving bank statements and countless other sensitive documents via email. And I have absolutely no other choice.
Whoever gets a hold of my email can impersonate me in almost every context.
So no, I do not consider the contents of my email public. Absolutely not!
I'm not willing to consider a service completely insecure just because it can never be completely secure.
The iCalendar spec[1] already features "encryption by committee" by being thoroughly obfuscated through its innate unreadability and undocumented vendor extensions. On a more serious note, a sibling comment asked if there's an API. And, really, for an API to work, we'd need to agree on some kind of data structures. Reading that spec, and having mucked with LDAP, IMAP and related specs, it really feels like we're stil…
Earlier quoted context omitted.
I came to a similar conclusion. You should write every email as if it were public, because it's entirely likely that it will be. They can be forwarded, made public through legal discovery, or exposed in a data breach (eg. Sony/North Korea). Forget security for a second, imagining every email as public record will make you more considerate and less biased writer. And from a business perspective, email should be viewed…
If that is so then "public" and "private" are insufficient categories to describe messaging options. I'm forced to send proof of identity as well as proof of address via email. I'm receiving bank statements and countless other sensitive documents via email. And I have absolutely no other choice. Whoever gets a hold of my email can impersonate me in almost every context. So no, I do not consider the contents of my ema…