Archive for September 13, 2021

Monday, September 13, 2021 [Tweets] [Favorites]

The Epic Anti-Steering Injunction Is Narrow

Nick Heer:

The nearly two hundred page order is very readable and well-written, but the injunction ordering Apple to scrap the last sentence of the first bullet in App Store rule 3.1.1 leaves plenty of ambiguity over what developers can do and what Apple must allow. This will undoubtably be clarified with time, but it is the only part of the result that creates more questions than it answers. Apple is apparently interpreting it as requiring the company to, in effect, apply its settlement with the Japan Fair Trade Commission to all apps, not just Apple’s “reader” app category. That means the anti-steering App Store policies will be removed within three months. But it may not mean that Apple must permit alternative in-app purchase options.

John Gruber:

YGR is only striking down the anti-steering rules that inform and link users to out-of-app (which effectively means web) means of sign-up and payment.

Judging by their reactions, both Apple and Epic see it that way too.

John Gruber:

I think the injunction allows, and Apple will enforce, that such links must open outside the app.

MacJournals:

The court specifically, carefully, and methodically examined whether Apple should be forced to allow IAP (in-app purchasing) systems other than the one built into iOS. The court found the arguments for such a ban lacking and declined to allow external IAP methods.

So the third-party IAP approach taken by Fortnite would still not be allowed.

Florian Mueller:

It’s one of those situations in which either side “gets something” and could claim victory, as Apple apparently does though the stock market initially disagreed (I, personally don’t think the decision should have moved the stock at all). This makes it all the more remarkable that Epic doesn’t engage in spin but concedes defeat. It’s not that Epic achieved nothing; but for the time being, all it got is a consolation prize, and that’s why Fortnite won’t return to iOS at this stage.

John Voorhees:

Building alternative storefronts or offering separate payment schemes are no more possible today than they were a week ago. In fact, the Court specifically concluded about the App Store and In-App Purchases, that Apple’s approach is valid[…]

Benedict Evans:

The more I look at this the more questions occur to me. Apps can offer their own payment now, but can Apple require them to offer IAP as well? Yes, on this text. At what price? What if Apple demands both IAP inclusion & price parity? Wouldn’t that mean Spotify was still blocked?

Michael Love:

There’s something unsettling about the fact that all the “actually much narrower” spin on Apple v. Epic has come secondhand through off-the-record “industry sources” and such; if Apple believes YGR did not comprehensively block anti-steering, they should come out and say so.

Personally, I think the injunction is unambiguous in blocking all anti-steering restrictions, and I don’t see anything in the longer opinion to suggest that that wasn’t her intent - she wants something simple to enforce, doesn’t want to get into the weeds of what a “button” is.

I don’t even think it’s particularly clear that developers have to keep offering in-app purchase at all - many of the developers this applies to weren’t offering it in before, the idea that Netflix can only offer an in-app ‘subscribe’ button if there’s an IAP option too is silly.

At the very least, certainly for ‘reader’ apps the combination of existing allowances for selling stuff outside of the app + this new requirement that all apps be allowed to redirect people to other purchase methods should fairly comprehensively end any obligation to use IAP.

Florian Mueller (Hacker News):

Let’s bear in mind that only Epic’s tenth claim succeeded at all. Not only Epic’s federal antitrust claims but also various state law claims failed. The failed state law claims include a couple that were very specifically about offering different IAP systems: Count 8 alleged unreasonable restraints of trade in the iOS IAP processing market under the California Cartwright Act, and Count 9 presented a tying claim related to IAP. Epic’s tenth and last claim--based on California UCL--broadly raised the issue of Epic being “unreasonably prevented from freely distributing mobile apps or its in-app payment processing tool, and forfeit[ing] a higher commission rate on the in-app purchases than it would pay absent Apple’s conduct.” But the court found for Epic under its tenth claim only with respect to the anti-steering provisions.

Florian Mueller:

By coincidence, that case was also an antitrust case as its caption shows. And the same appeals court--the one with which Epic filed its appeal yesterday--clarified that the standard involves “disobedience to a specific and definite court order.” (id.)

The bottom line is that any alleged ambiguity would favor Apple, not developers.

[…]

The question is not whether a developer’s interpretation of the injunction is somewhat reasonable. It’s whether Apple’s interpretation is so unreasonable as to constitute disobedience to a specific and definite court order.

[…]

Apple won’t even have to approve linking out to websites that merely sell digital items consumed in an iOS app.

Ben Thompson:

Judge Gonzales Rogers disagreed with both, defining the market as ‘mobile game transactions’.

[…]

I mentioned above that this was where the decision got a bit complicated; notice that I just used “IAP” and “in-app purchases” to represent two distinct concepts. Specifically, it seems clear that Gonzales Rogers has defined “IAP” to be Apple’s overall commerce system, while “in-app purchases” are purchases made in an app. In other words, Apple is justified in requiring IAP for in-app purchases.

Ryan Jones:

Basically, Judge ruled the same as the Japan anti-steering law, but for all apps: Apple can’t stop linking out.

  • Apple’s 30% rate is not threatened
  • Apple Pay + Stripe is not allowed
  • Apple crushed Epic

Craig Hockenberry:

While the lawyers argue about IAP, the rest of the development ecosystem is stuck with stuff that just plain doesn’t work.

Has anyone been able to get “Reset Eligibility” to work?

Previously:

Why Apple Should Compromise With Antitrust Regulators

Roger McNamee:

Recent news reports alleging mistreatment of some employees, internal policies that conflict with the company’s outward-facing stance on privacy, and efforts to prevent the passage of state laws to enable competition with the AppStore, along with a high profile lawsuit related to AppStore policies have tarnished Apple’s reputation. Despite this, the company has taken a stance towards Congress and regulators that the latter describe as ranging from arrogant to inflexible.

Unless Apple rethinks its approach, regulators will likely have no choice but to undermine its advantage in privacy and security. As a customer, that will piss me off. As an activist trying to reform the tech industry, it will leave me wondering what might have been. I would like to suggest a path to a better outcome.

[…]

It is a strategic error for Apple’s lobbyists and surrogates in Washington to argue against every new antitrust law targeting the tech industry. Apple has made itself a target by being incredibly successful and by adopting communications strategies that mimic tech giants whose anticompetitive behavior is substantially more damaging. Apple is almost certain to lose something, but there is still room to protect your most valuable assets. There may also be an opportunity to gain competitive advantage.

Via Nick Heer:

If there is some ambiguity as to what rules the permanent injunction permits Apple to create around in-app purchases, my hope is that the company uses this as an opportunity to ease off a little. I am not saying that I expect this to happen — today’s judgement indicates that Apple has little reason to stop pursuing its existing App Store strategy, with only the aforementioned exception. But a world in which Apple is not in an antagonistic role with developers is a better one for everyone, assuming that Apple can maintain or improve upon iOS’ privacy and security reputation. These fights are just noise.

M.G. Siegler (Hacker News):

My read is that Apple did win — exactly what everyone always knew they would win. But in winning that battle, they actually lost something far more important. There is no way around it: the judge’s order to stop App Store anti-steering is a big one. And seemingly one Apple did see coming given the Japanese settlement a few weeks back. But this is still a major blow because it both continues and accelerates the boulder rolling down the hill of real reforms to the App Store.

Apple may think that they’re doing enough in a piecemeal fashion to stave off major change, but they’re not. If anything, they need to make a major change to stanch the bleeding. But they won’t do that. They’re both too proud and too arrogant. They’re so sure that they’re in the right here that they don’t see that it actually doesn’t matter.

[…]

They should open things up to win these arguments on the product side of the equation — something which they’re uniquely situated to do thanks to about two dozen aspects of the iPhone. They should compete on the playing field in which they already have home field advantage.

Previously:

Update (2021-09-16): Michael Love:

At some point either Apple will allow sideloading or Safari will (foot-draggingly) reach a threshold where large numbers of apps start going web-only; I think option a is much healthier for iOS than option b, but absent legislative intervention the latter seems more likely.

Previously:

macOS 11.6

Juli Clover:

According to Apple’s release notes, macOS Big Sur improves the security of macOS and is recommended for all users. Apple has also released security update 2021-005 for macOS Catalina, and both updates address an issue that could allow a maliciously crafted PDF to execute code. Apple says that it is aware of a report that this bug may have been actively exploited.

It’s unclear why this update isn’t numbered 11.5.3. It was also weird in that the Update Now button was disabled for me in Software Update even though the text said that the update was available. I had to click the text to see the sheet with the list of updates and then click the checkbox next to it before macOS would start downloading the update.

Apple:

This document describes the security content of macOS Big Sur 11.6.

Howard Oakley:

Congratulations to Mikey @0xmachos, who has worked out that the PDF vulnerability is most probably the same as the Megalodon/FORCEDENTRY iMessage zero click exploit, involving a bug in CoreGraphics decoding JBIG2-encoded data in a PDF file.

See also: Mr. Macintosh (tweet).

Previously:

Update (2021-09-14): Howard Oakley:

Software which has changed version or build numbers between macOS 11.5.2 and 11.6 includes[…]

[…]

Although it does contain some minor fixes – that to SMB looks of potential interest – the 11.6 update is primarily a security update.

[…]

If you’re still running Mojave, this almost certainly means that your macOS is no longer supported by Apple, and may well be vulnerable to either or both of these bugs.

The standalone download is still not available.

Update (2021-09-17): Mr. Macintosh:

The macOS Big Sur 11.6 full installer is now available. 🎉

Zero-click iMessage Attacks

Lily Hay Newman (Hacker News):

These “zero-click” attacks can happen on any platform, but a string of high-profile hacks show that attackers have homed in on weaknesses in Apple’s iMessage service to execute them. Security researchers say the company’s efforts to resolve the issue haven’t been working—and that there are other steps the company could take to protect its most at-risk users.

[…]

Apple did make a major push to comprehensively address iMessage zero-clicks in iOS 14. The most prominent of those new features, BlastDoor, is a sort of quarantine ward for incoming iMessage communications that’s meant to weed out potentially malicious components before they hit the full iOS environment. But the interactionless attacks keep coming. This week’s Citizen Lab findings and research published in July by Amnesty International both specifically show that it’s possible for a zero-click attack to defeat BlastDoor.

Apple hasn’t issued a fix for this particular vulnerability and corresponding attack, dubbed “Megalodon” by Amnesty International and “ForcedEntry” by Citizen Lab. An Apple spokesperson told WIRED that it intends to harden iMessage security beyond BlastDoor, and that new defenses are coming with iOS 15, which will likely come out next month.

[…]

In fact, Citizen Lab researchers and others suggest that Apple should simply provide an option to disable iMessage entirely.

Lorenzo Franceschi-Bicchierai (tweet):

Security researchers found the vulnerability when they were investigating the potential hack of a Saudi activist’s iPhone, according to a new report by Citizen Lab, a digital rights group housed at the University of Toronto’s Munk School that has investigated NSO spyware for years.

The researchers told Motherboard that they believe the attack was carried out by a customer of NSO, the infamous Israeli company that sells spyware to dozens of governments all over the world.

Bill Marczak:

The exploit is invisible to the target, but in our forensic analysis, we found 31 files with the “.gif” extension on a target’s phone. Of course, they weren’t GIFs at all! 27 of them were the same 748-byte Adobe PSD file, and four were PDFs.

See also: Goodbye, iMessage.

Previously:

Update (2021-09-14): Juli Clover:

Today’s iOS 14.8 update addresses a critical vulnerability that Apple engineers have been working around the clock to fix, reports The New York Times.

See also: Hacker News.

Update (2021-09-17): Tom McGuire:

This blog post will analyze the integer overflow in CoreGraphics, CVE-2021-30860. After examining the modified .dylib, it appears that there were other issues that were resolved as well, related to imaging processing. We will focus in on the JBIG2 processing, specifically in the JBIG2::readTextRegionSeg.

MarsEdit 4.5.2

Daniel Jalkut (tweet):

This update brings long-awaited media syncing functionality for WordPress blogs. After you refresh your blog in MarsEdit 4.5, all the existing images and files from your blog will be available for re-insertion from the Media Manager’s “Published” tab.

Historically, this tab has included only files that are uploaded from MarsEdit itself. This limitation was based in shortcomings of the WordPress API (the interface MarsEdit communicates to the blog with), but the API has since been updated to support downloading a complete list of the published media files.

This is really cool. I ran into some issues when syncing large numbers of images, and these have been addressed in the 4.5.2 update.