ios
-
Why nine minutes, I’ve always wondered? Presumably ten is just a bit too long, and anything else would be too short. Why isn’t it configurable? Because, I assume, Apple have always been a highly opinionated company. ↩︎
Tip: How to Snooze iPhone Alarms Using Hardware Buttons
I don’t know whether people know about this iOS feature. I discovered it by accident a year or two back. Before that I used to snooze my alarms by drowsily scrabbling for my phone, prying my eyes open, then trying to tap the correct onscreen button.
Then one morning the alarm was too loud – or it might have been too quiet, I don’t recall – and I tried to change the volume. When I pressed the volume button, the alarm instantly stopped. I thought I had cancelled it by accident, until it rang again the customary nine minutes later.1
Since then I’ve always snoozed my alarms that way. But nearly every time I do, I think, “Do people know about this feature?” Because I don’t think I’ve ever seen it written down. And I’m going to post this without DuckDucking first, so that the existence of some article in The Verge or somewhere doesn’t spoil my flow.
I had thought that pressing the power button cancelled the alarm, rather than snoozing it, but I just checked, and it also snoozes it. So if you reach out, eyes closed, and press anything on the side of your iPhone, you’ll get another nine minutes.
In the interest of fully informing you, dear reader, I’ve just checked what the Home button does; and it appears that does cancel the alarm. So keep your presses to the sides.
I should note that I still have an iPhone 7. I’ve no reason to believe the behaviour is significantly different on more recent models, but obviously on the 10-series phones (X, XR, XS and the various 11s) you don’t have the Home button, so something different might happen. Let me know if you find out.
Beware of Email Apps Storing Passwords
Email apps, especially ones that offer advanced services like “send later,” may be storing our usernames and passwords on their servers.
To be clear what that means: if you use Gmail, for example, you put your Google username and password into the app when you set it up. You expect the app to store them securely on your device. But some apps may also be storing that username and password — your keys to all the Google services in this example — on computers owned by the company that makes the app. Computers over which neither you nor Google has any control.
I’m not suggesting that the company I talk about below, or any other, is doing anything nefarious. They need to be able to log in to your mail server in order to send your mail later. But I hadn’t realised until now what that means, and I’m guessing neither will a lot of people. And to my mind they don’t make what they’re doing clear enough.
Worst of all, having passwords stored on unknown servers — at the very least, that’s worrying.
Background
On episode194 of the Connected podcast, Myke Hurley and Federico Viticci were reviewing the latest version of the iOS (and Mac) app Spark. It’s a fine email app, which I was using on my iPhone and iPad. So I was alarmed when they mentioned in passing that mail handled by the app is routed through Readdle’s servers. That didn’t seem likely at first. Spark is an email client. You tell it what servers handle your mail, and it connects to them to receive and send. The servers belonging to the company that makes the app have no business getting involved in that.
I did some digging. Whether or not Myke was right™ about mail going through their servers, the reality turned out to be much worse.
Digging
I tweeted at the Spark account. Here’s what happened:
@SparkMailApp Hi, I was listening to a podcast today on which it was suggested that if I use Spark, then my email is routed through your servers. Is that true?
— Martin McCallion (@devilgate) May 25, 2018
Which podcast said that?
— Terry Blanchard (@terryblanchard) May 25, 2018
The latest episode of Connected, with Myke Hurley and Federico Viticci.
— Martin McCallion (@devilgate) May 25, 2018
The only time Spark servers access your email is to create a push notification (to create sender, subject, and message snippet) The content is cached until the notification is sent, but removed after that.
— Terry Blanchard (@terryblanchard) May 25, 2018
OK, seems fair. Thanks. Probably all a misunderstanding, either by them or me. Just out of interest, is the “send later” feature done on the client?
— Martin McCallion (@devilgate) May 25, 2018
Ah, forgot about that one! We will store it on our server until the send later time, then we send it through your email server and it is removed from our server.
— Terry Blanchard (@terryblanchard) May 25, 2018
OK. Isn’t that a problem, in that you must be storing your users’ mail server credentials on your servers? I’m pretty sure it doesn’t say that in your Ts&Cs.
— Martin McCallion (@devilgate) May 25, 2018
It’s the second item that we mention in our privacy policy. https://t.co/WpQSIDGPgx
— Terry Blanchard (@terryblanchard) May 25, 2018
I had already found their privacy policy:
OAuth login or mail server credentials: Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages and other communication. Without such access, our Product won’t be able to provide you with the necessary communication experience. In order for you to take full advantage of additional App and Service features, such as “send later”, “sync between devices” and where allowed by Apple – “push notifications” we use Spark Services. Without using these services, none of the features mentioned above will function.
The wording “Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages” suggests that Spark the app needs to log into your server, which it does. But nothing about that says that your credentials will be stored on their servers.
Further down, in point 4, “How Long Personal Data is Stored For,” in a table that includes “Type of information,” we see (emphasis mine) :
Email address, email content for Spark Services, mail server credentials
So there it is. They do store your username and password on their servers, and they do tell you; though only if you read well into the kind of document that notoriously goes unread.
Final Thoughts
For features like “send later” they need to store the fact that you want to send an email at a specific time, and log in to your server in order to send it. And to be fair, I’m sure they can’t be alone in keeping that kind of data. Lots of clients offer “send later” and similar services, and all of them will have to log in to your mail server to work. So they have to store your credentials on their servers to do it.
And consider, if you use Gmail, that means your username and password not just for Gmail, but for all Google’s services, are now stored on somebody else’s servers. Their security might be great, but how do we know?
The more I think about this, the more concerned I become. Passwords should only be stored in one place: a secure, trusted password manager. But above all, these services need to be much clearer about the fact that they’re storing our passwords.