Archive for June 29, 2022

Wednesday, June 29, 2022

M2 Display Limit

Benjamin Mayo (tweet):

The move from Intel to Apple Silicon meant Apple’s best-selling machines, the 13-inch MacBook Air and MacBook Pro, went backwards in one regard. They were no longer capable of driving two external displays.

But that was easily excused. It is only the first-generation of Apple Silicon after all. Although using two monitors at once is not really an edge case, it’s certainly not a dealbreaker for a base model laptop. As such, the sang was remarked upon and quickly excused as a footnote; a strange quirk of first-gen engineering.

Year two, here comes M2. CPU is better, GPU is better … and yet the one-display limitation remains.

Previously:

German Antitrust Probe Into App Tracking Transparency

Tim Hardwick:

Germany’s Federal Cartel Office, the Bundeskartellamt, has initiated proceedings against Apple to investigate whether its tracking rules and anti-tracking technology are anti-competitive and self-serving, according to a press release.

[…]

Apple said the feature was designed to protect users and not to advantage the company. However, the Bundeskartellamt’s preliminary findings indicate that while users can also restrict Apple from using their data for personalized advertising, Apple “is not subject to the new and additional rules of the App Tracking Transparency Framework.”

John Gruber:

Apple’s privacy and tracking rules do apply to itself. Apple’s own apps don’t show the track-you-across-other-apps permission alert not because Apple has exempted itself but because Apple’s own apps don’t track you across other apps.

[…]

Apple’s own advertising offerings — Search Ads — have indeed grown significantly post-ATT, but that’s not proof of self-serving.

[…]

In this new world where around three out of every four iOS users ask not to be tracked, non-tracking ad platforms benefit — including Apple’s own Search Ads.

This whole discussion is muddied by Apple’s self-serving definition of tracking. Search Ads does use App Transaction Data:

This includes historical information about users’ transactions on the App Store, including apps they’ve downloaded and in-app purchases they’ve made.

This is not considered tracking because Apple defined it to not be tracking. And Apple doesn’t even ask the customer to opt in. But if another company wants to target ads based on app purchases, that does count as tracking. This is because the purchase would have to be detected by a third-party app. The reason Apple doesn’t track you across other apps is because it doesn’t need to—it owns the store so it just gets the data directly from there. It even gets information about purchases that happen within the app because it requires that apps use its In-App Purchase system.

Nick Heer:

However, this advantage is difficult to replicate by any individual app or service. Only other gigantic companies, like Amazon and Facebook, can draw upon a trove of first-party data for ad targeting purposes. I have been arguing for the past year how it looks really bad for Apple to be setting privacy rules on its platform that restrict third-party advertisers while running its own ad network.

The solution here is not to empower others to more easily track users. If Apple is found to be illegally self-preferencing, I would hope it is resolved by allowing the continued operation of App Tracking Transparency while requiring Apple to reduce its first-party advantage.

For example, a hypothetical third-party app store would get all of the same information that Apple does without it counting as tracking. This is why the definition is so ridiculous. Imagine a third-party app store run by Facebook or Google or an app ad company. By Apple’s definition, that would all be cool because the information gathered from those sites stays within the same company. But the people that like ATT would not be OK with that. Obviously, it’s not more private if Facebook is processing the actual transaction rather than just being aware it.

This thought experiment shows that the ATT definition doesn’t get at the real issue, which is that people don’t like those companies having so much data. But there’s little questioning of the principles behind ATT because it seems to be targeting the right corporate victims.

(It’s also arguably hurting developers—who have more difficulty finding customers—and customers—who in theory don’t find as many apps that they’re interested in and also get the developers’ increased acquisition costs passed on to them—but it’s hard to measure these effects.)

In other marketplaces, a definition like ATT’s wouldn’t do much because any company selling both ads and apps/services would already have the necessary data without having to “track.” The reason ATT “works” is that Apple has a monopoly on app distribution, so no one else gets data by default. Apple’s privileged position means that the effects of ATT will be asymmetric—Apple will benefit and its competitors will be harmed.

Of course, you can look at this whole situation and see it as a good thing for customers, on balance. In theory, it is good for their privacy, though in practice my understanding is that Facebook really cares more about customer segments than individuals. It’s just that they need the individuals’ data in order to derive the segments data. You can also say that Apple has pure motives, and I think they largely do. They’ve created an interlocking that benefits them, but I think they would still do ATT even if for some reason they couldn’t do search ads. But is what’s in the hearts of Apple’s decision makers what determines whether the policy is self-serving? Or is it the policy’s effects, which I think it is hard to argue are not anti-competitive?

Florian Mueller:

This leads to the second unique aspect of the German FCO investigation (the first one was the gatekeeper statute): that country is known for a very strong data privacy movement.

When the French Adlc declined to order interim measures against Apple, it was too early to demonstrate Apple’s self-preferencing. That’s not an issue now, and the German FCO has raised the issue. We may see some really interesting Franco-German dynamics in this context.

Previously:

Passkeys

Meet passkeys (Hacker News):

Learn how to add support for passkeys to create a quick and easy sign in experience for people, all while offering a radical increase to account security. Passkeys are simple and strong credentials built to eliminate phishing attacks. We’ll share how passkeys are designed with security in mind, show you how people will use them, go over how to integrate passkeys in your log in flow, and explore the platform and web APIs you need to adopt this feature.

The developer documentation is here. I don’t understand the slide at the end where it says that Passkey protects against device theft but a password manager (maybe) doesn’t.

Other questions:

Kuba Suder:

If these “passkeys” are stored in a safe way protected with biometrics… how do I log in using them on my 2019 iMac with no secure enclave?

Dan Moren:

The addition of passkeys should also remove the need for multifactor authentication—no more entering codes from an app or via SMS. That was always an additional feature provided because of passwords’ inherent insecurity, but the way in which passkeys work makes it unnecessary.

[…]

One additional question that has now been answered for passkeys is what happens when you’re logging in on another device, either from Apple or another manufacturer. The FIDO Alliance that backs the passkey standard (of which companies like Apple, Microsoft, Google, and Amazon are all members) has an approved solution: a QR code that you scan with your phone, providing a secure way to log in.

The methodology behind this process is fascinating: among other things, the authenticating device (likely your iPhone) creates a Bluetooth-based relay server which, by the very nature of Bluetooth’s limited range, helps ensure that you are in fact in proximity to the device into which you’re logging in. That makes it much more difficult for phishers to trick you into giving up your passkey: sending you a QR code in an email or text message won’t work because it won’t be able to get access to the Bluetooth connection.

Dan Moren (also Bruce Schneier):

Andrew pointed me to a blog post by Terence Eden, which contains a bit of a thought experiment on what happens if you have a catastrophic accident (say, a house fire) and lose access to all your devices[…]

[…]

Well, there are recovery methods in place, as you might suspect. Apple talks broadly about them in a support article[…]

Apple:

To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.

It sounds like anyone who can get into your Apple ID account and either see your phone notifications or redirect an SMS message can delete all your passkeys.

Glenn Fleishman:

A passkey replaces two-factor authentication, and it’s worth breaking down why, as it seems counter-intuitive: how can a single code held on a device provide distinct aspects of confirmation? The rubric for multiple security factors is usually stated as at least two of “something you know, something you have, or something you are.” A passkey incorporates at least two of those:

  • Something you know: While commonly thought of as a password, the “know” part is really any fixed piece of information you possess. Think of a 20-character randomly generated password stored in your password manager. Do you “know” that? Yes, in the sense that it’s retrievable exactly as entered.
  • Something you have: Because passkeys are locked to devices, you prove your possession of a device by unlocking the passkey: no device, no passkey.
  • Something you are: Although passkeys don’t require biometric authentication using Face ID or Touch ID, it’s an option. Apple always lets you use a device passcode to backstop Face ID or Touch ID, so it’s a blurred line with “something you know” compared to a dedicated biometric device with no fallback option.

In what sense are passkeys locked to a device if they are syncing via iCloud Keychain? Is the idea that they must be on one of your devices because there is no way to export them?

Update (2022-06-30): Meek Geek:

What if something was broken with your Apple Card and Apple says you owe them money, or if you’re a developer who ran afoul of Apple’s App Store rules?

Would a suspension of your iCloud account mean that you lose access to all your passkeys?

Previously:

Copyright © 2000–2024 Michael Tsai.