Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
robn_fastmail
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
91.
▲
by
robn_fastmail
12y ago
Thanks for the feedback. We'll look into it for a future update.
92.
▲
by
robn_fastmail
12y ago
My point was more that this is a thread about the new apps, not about our privacy policies. If you want to start a new thread somewhere I'd be happy to comment on it.
93.
▲
by
robn_fastmail
12y ago
The main feature of the Android app is push notifications, which requires Google Play Services. A version of the app without push notifications is pretty much identical to just using the regular web app in Chrome Android, so there didn'
94.
▲
by
robn_fastmail
12y ago
Ahh yes, I can see why that would happen. I'll file an internal dev ticket, thanks.
95.
▲
by
robn_fastmail
12y ago
There are no new laws (yet). But lets not get into this discussion here. Contact privacy@fastmail.com with your questions and we'll be happy to respond to them.
96.
▲
by
robn_fastmail
12y ago
There's more in there than just the webview: all the push channel and notification stuff, a JMAP client, a Gravatar client and cache, sharing stuff, smartwatch hooks, etc. That said, none of it is particularly interesting or difficult.
97.
▲
by
robn_fastmail
12y ago
Fair enough, we love IMAP too, and there's no way its going anywhere. We've always cared about standards compliance and client choice, so use what you like and be happy! :)
98.
▲
by
robn_fastmail
12y ago
It _should_ have an unread message count on the icon. But yes, the iOS version's only significant feature over the regular web app is the addition of realtime push notifications. The Android app has a lot more right now, mostly because
99.
▲
by
robn_fastmail
12y ago
It was actually a really interesting development process. We already had the web app, and our main UI developer is an Apple guy, so he took on the iOS version. Meanwhile I'm primarily a Linux guy and work on FastMail's backend ser
100.
▲
FastMail app for iOS and Android now available
(blog.fastmail.com)
129 points
by
robn_fastmail
12y ago
|
123 comments
101.
▲
by
robn_fastmail
12y ago
> Your comment here strongly suggests the padlock was the primary reason for this change. It was the initial motivator. The privacy advantages however are still real. Ultimately it all goes to our customers being able to have confidence
102.
▲
by
robn_fastmail
12y ago
Actually the reason is that we're planning to roll out an EV cert later this year, and we hated the idea that an arbitrary email can remove the green badge. Once we decided we wanted to do this, then we looked around to see what other
103.
▲
by
robn_fastmail
12y ago
I have edited that sentence to say "where the request came from" rather than "who has actually requested it". Overall though, its still an improvement. A key in the URL does verify that the email address is deliverable,
104.
▲
by
robn_fastmail
12y ago
We're actually testing bitcoin payments at the moment. If you want to take the time to contact support, we can tell you how to use it.
105.
▲
by
robn_fastmail
12y ago
Hi, FastMail employee here. Just to clarify ahead of time, what's happening is literally all the blog post says - we're getting off of Opera hardware and networks and on to our own. For end-users, nothing changes. There will conti
106.
▲
by
robn_fastmail
12y ago
For historical reasons we still run DJabberd at FastMail so I had to add support for this myself. You might try this patch: https://github.com/fastmail/DJabberd/commit/144c4431f36e5ea3... Its been running for
107.
▲
by
robn_fastmail
13y ago
Actually exactly half an hour between when I got woken up and when I sent my report email.
108.
▲
by
robn_fastmail
13y ago
> "needing ... supporting IdPs (email providers)" Over at FastMail we seriously looked into implementing Persona across the board. We're one of the bigger "small" email providers and we figured that it would be a
109.
▲
by
robn_fastmail
13y ago
Persistent connections are tough on patchy mobile networks. Parsing latency isn't really an issue; all this stuff is IO bound anyway. CPU cycles are cheap.
110.
▲
by
robn_fastmail
13y ago
IMAP works, but not particularly well for a lot of modern tasks. Its highly stateful, requires a fair amount of knowledge on the part of the client to make things work correctly, and too many extensions are optional, requiring a lot of fall
111.
▲
by
robn_fastmail
13y ago
Yeah, this one is well known, see https://tidbits.com/article/14219 . We actually have some evidence to suggest that we've picked up a few customers leaving Gmail because of this problem. Which is nice, but now we
112.
▲
by
robn_fastmail
13y ago
A very naive estimate based on one day of logs from one server says over 75% of our incoming port 25 connections are encrypted. Although that says nothing about the quality of the cipher in use and the type of messages that come through, it
113.
▲
by
robn_fastmail
13y ago
> If they force you to disclose your customers' data in secret tomorrow, or face jail time, I have no doubts what your choice will be. We have no doubts either. The privacy policy clearly states we will give your data to the Austral
114.
▲
by
robn_fastmail
13y ago
I'm afraid that if get fit and stuff I won't want them anymore! :'(
115.
▲
by
robn_fastmail
13y ago
If you want to just send timtams, that would be fine too. We seem to have run out of them in the office...
116.
▲
by
robn_fastmail
13y ago
There's a solution for this. Its called DANE. See http://tools.ietf.org/html/draft-ietf-dane-smtp We're currently investigating it.
117.
▲
by
robn_fastmail
13y ago
Because its our advice. It was developed for us, taking our concerns into account. You need to get your own legal advice relevant to your own situation. Or put another way, I don't think "Your Honour, FastMail's lawyer said i
118.
▲
by
robn_fastmail
13y ago
We currently have a complete copy of all user data in a secondary (non-US) data centre. In the event of a loss of our US-based servers, we would get this secondary copy up and running as quick as possible (likely in a reduced capacity) whil
119.
▲
by
robn_fastmail
13y ago
We have been contacted by US authorities in the past, and have referred them to the appropriate Australian authorities. We have been contacted by Australian authorities in the past, and have worked with them in accordance with Australian la
120.
▲
by
robn_fastmail
13y ago
I just checked upstairs. The advice we have is roughly: - ACC has judicial oversight - its unclear how this interacts with the Telecommunications (Intercept and Access) Act With my boss throwing in: - law is a giant mess - until you have tw
More ›