We’ve all been there. You’re signing up for a new service or creating an account for a new app, and you’re asked to pick a password. You know you should use a strong, random password, but in a rush to get started, you take the easy path and choose a weak, memorable password instead because it’s the path of least resistance.
Apple has been pushing back against those bad habits with new iOS features designed to combat password reuse by flipping the calculus on its head. In an excellent presentation given at PasswordsCon 2018 in Stockholm, Sweden last week, Apple engineer Ricky Mondello explains the iCloud Keychain features implemented in iOS since iOS 11 and the thinking behind them. He also provides tips and resources for web and app developers who want to integrate better with those features.
What I especially like about Mondello’s talk is the insight into the thought and effort that’s gone into making good passwords easy to create. It’s not something I’ve thought about much before, which I take as a sign that Apple’s Safari and iCloud Keychain engineers are succeeding.
The presentation is also fascinating from a design and user experience standpoint. As Mondello explains, people are ill-suited to create and remember random passwords. It’s a problem that’s right in a computer’s wheelhouse, but one that also requires users’ trust and an understanding of their habits to solve.
I recommend watching Mondello’s talk. There are a lot of interesting implementation details throughout the talk and insights into the thinking behind them, which are approachable whether you have a background in the topics covered or not.
For the past couple of years, I (and the rest of the MacStories team) have used Working Copy to store and collaborate on Markdown drafts for our articles. As I explained in a story from late 2016, even though Working Copy is a Git client primarily designed for programmers, it is possible to leverage the app's capabilities to perform version control for plain text too. Each MacStories team member has a private GitHub repository where we store Markdown files of our articles; in the same repository, other writers can make edits to drafts and commit them to GitHub; this way, the author can then pull back the edited file and use Working Copy's built-in diff tool to see what's changed from the last version of the file and read comments left by whoever edited the draft.
As I mentioned two years ago, this system takes a while to get used to: GitHub has a bit of overhead in terms of understanding the correct terminology for different aspects of its file management workflow, but Working Copy makes it easier by abstracting much of the complexity involved with committing files, pushing them, and comparing them. This system has never failed us in over two years, and it has saved us dozens of hours we would have otherwise spent exchanging revised versions of our drafts and finding changes in them. With Working Copy, we can use the text editors we each prefer and, as long as we overwrite the original copies of our drafts and keep track of commits, the app will take care of merging everything and displaying differences between versions. From a collaboration standpoint, using Working Copy and GitHub for file storage and version control has been one of the best decisions I made in recent years.
Dan Moren, writing for Six Colors on today's announcement of 200 GB of free iCloud storage for schools:
Look, it’s lovely that Apple has decided to give 200GB of free iCloud storage to any Apple ID associated with a teacher or student. It’s a nice gesture, and one that probably makes things a lot easier for those in school environments.
But, come on, Apple—you’re really going to leave the rest of us at 5GB?
The standard 5GB of free iCloud storage has been in place for years now, and, frankly, it’s starting to wear thin. When most iOS devices come in 32GB configurations at the smallest, and many start at 64GB, 5GB feels pretty paltry. Especially when the next step in the upgrade tier is to pay $0.99 for 50GB of storage space. I realize Services has become a moneymaker for Apple, but it just feels cheap.
I hope that increasing free storage for education is the first step towards more free iCloud for everyone this year. I wouldn't expect non-education customers to get 200 GB for free, but the measly 5 GB of free storage have become just as user-hostile as 16 GB iPhones used to be. There has to be a better solution in between.
There’s been quite a stir over the last week regarding an area of the Apple cloud ecosystem where syncing has remained unreliable for years. Brian Stucki wrote a detailed post on the matter, which John Gruber linked to with echoing sentiments. Today, however, Gruber followed up on his post with an exciting update:
Good news related to yesterday’s item regarding the fact that text replacement shortcuts have never synced reliably between Macs or iOS devices: an Apple spokesperson emailed me to say they checked with the team, and an update that moves text replacement syncing to CloudKit should be rolling out to iOS 11 and MacOS 10.13 High Sierra users in the “next month or so”.
I use text replacement every day across my iOS devices, and haven’t dealt with syncing issues myself, but it’s great to hear that this long-standing problem should soon be put to rest for everyone else. Recent history shows that once a cloud product moves to CloudKit, syncing issues disappear almost entirely – hopefully that will be the case here as well.
Mitchel Broussard of MacRumors shares an announcement from Amazon about a new Alexa skill for iCloud Calendar:
Starting today, you can now link your Apple iCloud Calendar to Alexa. To do this, iCloud Calendar customers can simply link their account in the settings tab in the Alexa app. Once linked, just say, “Alexa, what’s on my calendar today?” or “Alexa, add lunch with Sarah at noon to my calendar.”
iCloud Calendar support has been a top requested feature from Alexa customers, and we’re thrilled to bring this to Alexa devices in US, UK and Germany today.
It's nice to start seeing some of Apple's cloud offerings integrate with third-party services. Today's Alexa integration follows IFTTT's integrations earlier this year with iCloud Calendar and the App Store. Services as basic as iCloud Calendar shouldn't be restricted to Apple-made devices, so I'm thankful to see Apple opening up – even if it's just a little bit.
Last month a rash of spam calendar invitations began showing up in iCloud users’ calendars from unknown senders. Benjamin Mayo at 9to5Mac reports that Apple has begun rolling out a ‘Report Junk’ link on iCloud.com to address the situation:
This lets users remove spammy invites from their calendar and reports the sender to Apple for further investigation.
At the moment the fix is available through iCloud.com only. Presumably the feature will be added to a future update to iOS, though it has not made an appearance in the iOS 10.2 betas to date.
If you receive a spam calendar invitation, log into iCloud.com, navigate to the spam invitation, open it, and look for the ‘Report Junk’ link. Clicking that link and confirming that the invitation is junk will remove the event from your calendar and report the sender to Apple. Calendar spam can be reported as junk whether or not you have accepted the invitation first, although it is best to avoid accepting spam invitations because it alerts the senders that the invitation was sent to an active iCloud account.
A notable addition to CloudKit announced by Apple today – an API for server-to-server requests:
In addition to providing a web interface for users to access the same data as your app, you can now easily read and write to the CloudKit public database from a server-side process or script with a server-to-server key.
Benjamin Mayo explains what this means in practice:
Until now, interaction with CloudKit has been limited to the APIs Apple provided in apps. Although this was useful, it lacked the options for more advanced use — most modern apps rely on servers to perform tasks whilst users are away. With the addition of the web API, developers can create many more types of applications using CloudKit as the backend. For instance, an RSS reader app can now add new feed items to the CloudKit stack from the server. Before, this action could only occur when a user opened a CloudKit-powered app, which was essentially impractical and meant developers had to use other tools.
Somewhat coincidentally, the announcement follows the news of Facebook shutting down Parse, the popular backend-as-a-service tool for developers. I've tried a few CloudKit apps over the past year that would have benefitted from a web counterpart checking for changes in the background – hopefully this change will enable more functionality for those types of apps. A feed reader built entirely off CloudKit with timely updates would be interesting.