- I’m glad Google is taking user privacy so seriously.
- …but I didn’t know it was so Kafka-esque for developers to comply with their requirements.
- A friend sends you email.
- Mail.app periodically checks your email account to see if you have new mail, then fetches it.
- Mail.app gives you some sort of notification that you have a new message.
- A friend sends you email.
- The Gmail mail server sends a “push notification” to your phone, waking it up and alerting it that you have new email.
- The Gmail app on your phone fetches it.
- The Gmail app on your phone notifies you that you have a new message.
- The Spark app on your phone sends your email username and password to Readdle’s server where it’s stored until you ask Readdle to delete it.
- A friend sends you email.
- Readdle’s server continually checks your account for new email, and then fetches it.
- Depending on the contents of the email, Readdle’s server may do some extra processing on your behalf, and may send the Spark app on your phone a push notification to tell it you have new mail.
- The Spark app on your phone fetches your email from your mail server.
- The Spark app on your phone notifies you that you have a new messages.
- iCloud Keychain (includes all of your saved accounts and passwords)
Google writes safer code with Rust
From “Google hails move to Rust for huge drop in memory vulnerabilities”:
In Google’s own shift towards using memory safe programming languages there has been a significant drop in the number of memory-related vulnerabilities, with memory safe vulnerabilities down to 24% in 2024 - a stark contrast from 2019 [76%] and well below the industry norm of 70%.
Memory safety is not the same as safety. You can still write bad logic in any language. It “just” gets rid of the majority of bugs so that programmers can concentrate on the more interesting parts.
Also, yes, of course you can write safe C code. No one with a large codebase ever has in practice, but it’s at least hypothetically possible. Wouldn’t rather not have to, though?
The fine folks who make iA Writer wrote about their challenges supporting Android.
My first impressions:
I hear “why would devs ever tolerate Apple’s App Store shenanigans when Android is right there?” Well, because the grass isn’t always greener.
Ideally, both Apple and Google would make it easier for devs. Nothing about this requires either’s processes to be more complicated than they inherently are. As it stands today, both shift a lot of extra effort and compliance guesswork onto developers.
The Risks of Third-Party Email Clients
There are a lot of neat third-party email applications available for Mac and iOS. From an end user perspective, many of them are amazing and useful. From an information security, privacy, or legal perspective, many are horrible.
For example, Readdle makes a popular email client, Spark. Now, to be clear, I think Readdle is a good, competent, well-meaning company and that Spark is a nice app. My problem with their product isn’t because I don’t trust them, but because I have to trust them, and unnecessarily.
Here’s why.
How first-party email apps work
When I refer to a first-party mail client, I mean Apple’s own Mail.app, or the app that an email service company made to support their own system (such as Google’s Gmail app). These are a direct link between your computer and your email service, and are widely regarded as trustworthy and safe to use. That is, if you don’t trust Mail.app with your email, you probably wouldn’t be using a Mac or iPhone in the first place. If you don’t trust the Gmail app, you shouldn’t trust the Gmail service either. A third-party app, then, is one made by someone other than the company who made your computer’s operating system or your email service.
With that out of the way, here’s how the process of receiving an email works on these clients:
Alternatively:
That’s straightforward.
How some third-party email apps work
Spark could have been written to work like Mail.app, but Readdle chose not to, for a good reason that I understand and appreciate. All that “do I have new email?” checking can eat up a phone’s battery, and if someone sends you an email right this moment, it may take several minutes before you get a notification. However, this is where a giant privacy and security issue pops up. Spark works like this:
See the problem? Readdle has your login information and uses it to check email on your behalf. From their privacy policy:
INFORMATION WE COLLECT AND HOW WE USE THIS INFORMATION
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.
By its design, you have to trust Readdle to read all your email if you want to use the Spark app, and that’s not OK. Depending on what line of work you’re in, it may not even be legal for you to allow another company to access your email if you don’t have a signed data use agreement (DUA) or HIPAA Business Associate Agreement (BAA) in place with that company. Google will sign a BAA if you ask them. Apple’s Mail.app design doesn’t require that because Apple never has access to your email account (unless you use iCloud email, which you shouldn’t be doing anyway if you’re working with HIPAA data). In fact, Apple can’t access your email usernames and passwords. From their iCloud security overview:
These features and their data are transmitted and stored in iCloud using end-to-end encryption:
And all of this to support push notifications, which are nice but that Mail.app never had in the first place. Note: Readdle’s service isn’t “push” behind the curtain, as their server has to regularly poll your email service to see if you have new mail. The difference is that it’s their server doing the polling using their electricity, not your iPhone. That’s a handy feature, but is it worth it? In my opinion, it isn’t. Further, I disagree with Readdle’s statement that the “send later” and “sync between devices” features require this arrangement. They could have been built to use an end-to-end encrypted service like iCloud, but Readdle chose not to. Again, they probably did that for decent reasons because Readdle is a good company, but they didn’t have to.
Conclusion
I’m using Readdle’s Spark as an example, but mail clients are all over the place privacy-wise.
Airmail’s privacy policy says:
If “Real-Time Mailbox Monitoring” is enabled for Gmail or Outlook, Office365, IMAP, and Exchange accounts, we store credentials solely to send push notifications.
Superhuman also stores your login information:
Authentication Tokens. When you sign in to the Service, we collect and store encrypted Gmail authentication tokens.
Postbox doesn’t collect your credentials:
We only communicate with Google’s email servers through IMAP, POP, and SMTP protocols, and never receive or store any messages or data from your Google email accounts on our servers. You can revoke Postbox’s access to Google services at any time.
That’s one of the less creepy terms in their privacy policy, though:
We may use information about your publicly available social media information, or your contacts’ publicly available social media information, in connection with our Services.
MailMate has a clear policy:
Passwords are most often required for MailMate to access the emails in your IMAP accounts and to send emails using SMTP servers. Regular passwords are stored (if you allow it) in the Keychain of macOS. Depending on your settings, this might be an iCloud-based keychain synchronized to your other devices.
Some accounts support OAuth2 authentication. In this case, a browser is used for authenticating your accounts and MailMate only gains access to so-called OAuth2 tokens. The tokens are used to access your accounts and MailMate never sees and never stores your password. The tokens are stored in your Keychain as described above.
If an app doesn’t have a privacy policy, don’t use it. If it does, read the policy. And if you work in a regulated industry like finance or healthcare, get your company’s legal team’s opinion before using a third-party app!
Google v. Oracle - victory!
This morning the US Supreme Court ruled for Google in Oracle’s case against them. This is wonderful news for American software engineering as the opposite ruling would have been disastrous for the entire industry.
Consider a comprehensive, albeit farfetched, analogy that illustrates how the API is actually used by a programmer. Imagine that you can, via certain keystrokes, instruct a robot to move to a particular file cabinet, to open a certain drawer, and to pick out a specific recipe. With the recipe in hand, the robot then moves to your kitchen and gives it to a cook to prepare the dish. This example mirrors the API’s task-related organizational system. Through your simple command, the robot locates the right recipe and hands it off to the cook. In the same way, typing in a method call prompts the API to locate the correct implementing code and hand it off to your computer. And importantly, to select the dish that you want for your meal, you do not need to know the recipe’s contents, just as a programmer using an API does not need to learn the implementing code. In both situations, learning the simple command is enough.
I think that’s a great analogy, if I do say so myself.
Google v. Oracle, by analogy
Suppose Joe opens a restaurant. He hires a waiter who is really great at following directions, but speaks no English. Over time, Joe comes up with a way of working with this waiter that’s very precise and detailed. You can ask the waiter for things like “order burger plus cheese plus ketchup no tomato no onion” or “bring check” or “bring water”. However, you have to say things exactly the right way each time. You can’t just say “order cheeseburger” instead of “order burger plus cheese”, or “bring me some water” instead of “bring water”. If you do, the waiter will only say “I don’t understand” and wait for you to say it the right way.
All of this is explained on the menu, and the waiter is otherwise good enough at his job that people are willing to learn the Joe’s Cafe way of ordering their food and asking for the check afterward.
A while later, Gina decides to open a different restaurant across town from Joe’s place. Her food is nothing like Joe’s, she uses different suppliers, her kitchen has a brand new setup she invented herself, and she uses little robot dogs instead of waiters. However, she does a little market research and finds out that a lot of people in her city are use to ordering food the Joe way. To make it easier for her customers, she programs her robot dogs to respond to requests the same way that Joe’s waiter would. Then they’ll be able to order food and enjoy her restaurant without having to learn a whole new system!
Now, at Joe’s, if you say “order burger plus cheese”, the waiter writes this down, carries the order to the kitchen, and hands it to the cook. The cook follows the instructions, hands the food to the waiter, and the waiter takes it back to the table. Gina’s restaurant doesn’t have burgers, but if you tell her robot dog to “order steak plus potato”, it transmits the order via radio to the kitchen where a 3D printer makes it and then sends it to your table via a flying drone.
In other words, you place your order at Gina’s restaurant the same way you would at Joe’s, but almost everything else about the process is completely different because Gina came up with her system from scratch. As it turns out, a few orders do happen to work the same because there are only so many ways to react to “bring water”. That’s natural, though. Gina didn’t copy Joe’s “leave the table, fill a pitcher with water, bring it back to the table, and fill the empty glasses” process; that’s just the way you do it.
This is same as the relationship between Oracle and Google. Oracle bought a company who made a programming language called Java that became popular. When Google was making their Android phones, they wanted to make it easy for developers to write apps and games for it. Since so many people were already familiar with Java, they decided to let developers use it. However, they made their own Java from scratch that looks like Oracle’s Java from a programmer’s point of view but is completely different behind the scenes. As with Joe and Gina, the way you place your order is the same, but that’s where the similarity ends.
Oracle is suing Google because they say it’s unfair that Google allowed their developers to write programs in something that looks like Java, except without it actually being Java, and that Google should pay them for the privilege.
If it’s not reasonable that Gina should have to pay Joe just because her robot dog knows how to respond to “order steak plus potato”, then it’s not reasonable that Google should have to pay Oracle since they didn’t use any of Oracle’s underlying work.
Google is asking the US Supreme Court to declare that they didn’t copy Oracle’s programming code when they created their own work-alike system. For the sake of the US software industry, I hope Google wins.
As a personal note, I don’t like eating at either Joe’s or Gina’s restaurant. The food’s awful in both places. I still don’t think that Gina (or Google) owe Joe (or Oracle) anything.