Apple Archive

Way back in 2021, in the Epic v. Apple court case, judge US District Judge Yvonne Gonzalez Rogers ordered Apple to allow third-party developers to tell users how to make payments inside iOS applications without going through Apple’s App Store. As we have come to expect from Apple, the company maliciously complied, lowering the commission on purchases outside of its ecosystem from 30% to 27%, while also adding a whole bunch of hoops and hurdles, like scare screens with doom-and-gloom language to, well, scare consumers into staying within Apple’s ecosystem for in-app payments. Well, it turns out Judge Yvonne Gonzalez Rogers is furious, giving Apple, Tim Cook, and its other executives what can only be described as a beatdown – even highlighting how one of Apple’s executives, under orders from Tim Cook, lied under oath several times. Gonzalez is referring this to the District Attorney for Northern California “to investigate whether criminal contempt proceedings are appropriate.” In stark contrast to Apple’s initial in-court testimony, contemporaneous business documents reveal that Apple knew exactly what it was doing and at every turn chose the most anticompetitive option. To hide the truth, Vice-President of Finance, Alex Roman, outright lied under oath. Internally, Phillip Schiller had advocated that Apple comply with the Injunction, but Tim Cook ignored Schiller and instead allowed Chief Financial Officer Luca Maestri and his finance team to convince him otherwise. Cook chose poorly. The real evidence, detailed herein, more than meets the clear and convincing standard to find a violation. The Court refers the matter to the United States Attorney for the Northern District of California to investigate whether criminal contempt proceedings are appropriate. ↫ US District Judge Judge Yvonne Gonzalez Rogers Gonzalez’ entire ruling is scathing, seething with rage, and will probably do more reputational damage to Apple, Tim Cook, and his executive team than any bendgate or antennagate could ever do. Judge Gonzalez: This is an injunction, not a negotiation. There are no do-overs once a party willfully disregards a court order. Time is of the essence. The Court will not tolerate further delays. As previously ordered, Apple will not impede competition. The Court enjoins Apple from implementing its new anticompetitive acts to avoid compliance with the Injunction. Effective immediately Apple will no longer impede developers’ ability to communicate with users nor will they levy or impose a new commission on off-app purchases. Apple willfully chose not to comply with this Court’s Injunction. It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple. ↫ US District Judge Judge Yvonne Gonzalez Rogers Gonzalez effectively destroyed any ability for Apple to charge commissions on purchases made inside iOS applications but outside Apple’s App Store, and this order will definitely find its way to the European Union as well, where it will serve as further evidence of Tim Cook’s and Apple’s continuous, never-ending contempt for the law and courts that uphold it. For its part, Apple has stated they’re going to appeal. Good luck with that.

The fines weren’t the only Digital Markets Act news coming from this fine continent today. The European Commission also closed its investigation into Apple’s user choice obligations under the DMA, and while Apple has made good progress in a few areas, the EC states Apple is still acting illegally in a variety of others. First, the good news for Apple: the European Commission is happy with Apple’s changes regarding browser choice, the ability to remove preinstalled iOS applications, and the ability to change a whole bunch of default settings that are all locked outside of the EU. These are valuable and welcome changes, and I’m glad the European Union, the European Parliament, and the Commission have forced Apple to become less hostile to European consumers. Second, there’s the bad news for Apple. Under the DMA, Apple is obligated to allow for third-party application stores, and the ability for users to download and install applications directly from the internet. In this area, Apple is still breaking European Union law. The Commission takes the preliminary view that Apple failed to comply with this obligation in view of the conditions it imposes on app (and app store) developers. Developers wanting to use alternative app distribution channels on iOS are disincentivised from doing so as this requires them to opt for business terms which include a new fee (Apple’s Core Technology Fee). Apple also introduced overly strict eligibility requirements, hampering developers’ ability to distribute their apps through alternative channels. Finally, Apple makes it overly burdensome and confusing for end users to install apps when using such alternative app distribution channels. ↫ European Commission press release This outcome was entirely expected, and pretty much everyone – except Apple’s PR attack dogs – knew Apple’s malicious compliance, fees, and onerous hurdles were going to be a hard sell. I’m glad the European Commission seems unimpressed with Trump’s sabre-rattling about the EU’s consumer protection laws, and is continuing to whip US tech companies in line, making sure they stop violating our consumer protection laws. Since these are the outcomes of a preliminary investigation, Apple now has the chance to argue its case.

I’ve saved the worst for last. For some reason, Xcode phones home to appstoreconnect.apple.com every time I open an Xcode project. This also appears to be unnecessary, and I experience no problems after denying the connections in Little Snitch, so I do! I assume that the connections send identifying information about the Xcode project to Apple, otherwise why even make the connections when opening a project? And all of these connections from Xcode, to every domain, require login to your Apple Developer account, so Apple is definitely receiving identifying information about you in any case. In effect, Xcode is a developer analytics collection mechanism, whether you like it or not, which I don’t. ↫ Jeff Johnson If, at this point in time, you’re still surprised Apple doesn’t practice what it preaches, the fault lies pretty much entirely with you. Anyway, it seems Xcode phones home to Apple quite a bit, which I doubt is all that unique in the world of commercial development environments. I honestly don’t think Apple itself doing anything particularly nefarious with this data, but the fact it’s collecting it in the first place should still make you think twice about using Xcode, especially if you’re developing anything even remotely sensitive. What should really worry you is the fact Tim Cook and Apple are close allies of Trump and his regime. Xcode is required for iOS/iPadOS/etc. development, because the App Store requires applications be built and submitted with it. As such, every iOS developer is sending substantial amounts of data to Apple during development, which should be especially concerning for people outside of the US and people who aren’t straight white males; using Xcode requires an Apple Account, so Apple knows quite a bit about who is using it. With the breakdown of the rule of law in the US, all of this data is basically freely accessible to US authorities, and we’ve seen by now that people like self-styled genius Elon Musk don’t worry too much about pesky things like the rule of law. If Musk wants this data, Apple will hand it over. If you’re an Apple developer, you should stop and think every time you open Xcode. You’re sending your data straight to a hostile entity. If you’re claiming to use Apple products because of Apple’s privacy “promises”, Xcode’s data collection should be a huge worry for you.

A bug in the ROM for the Macintosh II was recently discovered that causes a crash when booting in 32-bit mode. Doug Brown discovered and documented the bug while playing with the MAME debugger. Why did it never show up before? It seems a quirk in Motorola’s 68030 CPU inadvertently fixes it when executing an illegal instruction that shouldn’t have been executed in the first place. What follows is his process for investigating the room on emulated hardware, and then testing it on actual hardware.

What’s the European Commission to do when one of the largest corporations in the world has not only been breaking its laws continually, but also absolutely refuses to comply, uses poison pills in its malicious compliance, badmouths you in the press through both official – and unofficial – employees? Well, you start telling that corporation exactly what it needs to do to comply, down to the most minute implementation details, and in the process take away any form of wiggle room. Steven Troughton-Smith, an absolute wizard when it comes to the inner workings of Apple’s various platforms and allround awesome person, dove into the European Commission’s proposed next steps when it comes to dealing with Apple’s refusal to comply with EU law – the Digital Markets Act, in particular – and it’s crystal-clear that the EC is taking absolutely no prisoners. They’re not only telling Apple exactly what kind of interoperability measures it must take, down to the API level, but they’re also explicitly prohibiting Apple from playing games through complex contracts and nebulous terms to try and make interoperability a massive burden. As an example of just how detailed the EC is getting with Apple, here’s what the company needs to do to make AirDrop interoperable: Apple shall provide a protocol specification that gives third parties all information required to integrate, access, and control the AirDrop protocol within an application or service (including as part of the operating system) running on a third-party connected physical device in order to allow these applications and services to send files to, and receive files from, an iOS device. ↫ European Commission In addition, Apple must make any new features or changes to AirDrop available to third parties at the same time as it releases them: For future functionalities of or updates to the AirDrop feature, Apple shall make them available to third parties no later than at the time they are made available to any Apple connected physical device. ↫ European Commission These specific quotes only cover AirDrop, but similar demands are made about things like AirPlay, the easy pairing process currently reserved for Apple’s own accessories, and so on. I highly suggest reading the source document, or at the very least the excellent summary thread by Steven, to get an even better idea of what the EC is demanding here. The changes must be made in the next major version of iOS, or at the very latest before the end of 2025. The EC really goes into excruciating detail about how Apple is supposed to implement these interoperability features, and leaves very little to no wiggle room for Apple shenanigans. The EC is also clearly fed up with Apple’s malicious compliance and other tactics to violate the spirit of the DMA: Apple shall not impose any restrictions on the type or use case of the software application and connected physical device that can access or makeuse of the features listed in this Document. Apple shall not undermine effective interoperability with the 11 features set out in this Document by behaviour of a technical nature. In particular, Apple shall actively take all the necessary actions to allow effective interoperability with these features. Apple shall not impose any contractual or commercial restrictions that would be opaque, unfair, unreasonable, or discriminatory towards third parties or otherwise defeat the purpose of enabling effective interoperability. In particular, Apple shall not restrict business users, directly or indirectly, to make use of any interoperability solution in their existing apps via an automatic update. ↫ European Commission What I find most interesting about all of this is that it could have been so easily avoided by Apple. Had Apple approached the EU and the DMA with the same kind of respect, grace, and love Apple and Tim Cook clearly reserve for totalitarian dictatorships like China, Apple could’ve enabled interoperability in such a way that it would still align with most of Apple’s interests. They would’ve avoided the endless stream of negative press this fruitless “fight” with the EU is generating, and it would’ve barely impacted Apple’s bottom line. Put it on one of those Apple microsites that capture your scrolling, boast about how amazing Apple is and how much they love interoperability, and it most likely would’ve been a massive PR win. Instead, under the mistaken impression that this is a business negotiation, Apple tried to cry, whine, throw tamper tantrums, and just generally act like horrible spoiled brats just because someone far, far more powerful than they are told them “no” for once. Now they’ve effectively been placed under guardianship, and have to do exactly as the European Commission tells them to, down to the API level, without any freedom to make their own choices. The good thing is that the EC’s journey to make iOS a better and more capable operating system continues. We all benefit. Well, us EU citizens, anyway.

Although there’s little evidence of them today, Apple made a long succession of Mac servers and servers for Macs from 1988 to 2014, and only discontinued support for the last release of macOS Server in April 2022. Its first entry into the market was a special version of the Macintosh II running Apple’s own port of Unix way back in 1988. ↫ Howard Oakley These days, you can nab Xserves for pretty cheap on eBay, but since Apple doesn’t properly support them anymore, they’re mostly a curiosity for people who are into retro homelab stuff and the odd Apple enthusiast who doesn’t know what to do with it. It always felt like Apple’s head was never really in the game when it came to its servers, despite the fact that both its hardware and software were quite interesting and user friendly compared to the competition. Regardless, if my wife and I ever manage to buy our own house, the basement’s definitely getting a nice homelab rack with old – mostly non-x86 Sun and HP – servers, and I think an Xserve would be a fun addition, too. Living in the Arctic means any heat they generate is useful for like 9 or so months of the year to help warm the house, and since our electricity is generated from hydropower they wouldn’t be generating a massive excess of pollution, either. I have to figure out what to do with the excess heat during the few months of the year where it’s warm outside, though.

In recent weeks, law enforcement in the United States discovered, to their dismay, that iPhones were automatically rebooting themselves after a few days of inactivity, thereby denying them access to the contents of these phones. After a lot of speculation online, Jiska Classen dove into this story to find out what was going on, and through reverse-engineering they discovered that this was a new security feature built by Apple as part of iOS 18.1, to further make stolen iPhones useless for both thieves as well as law enforcement officers. It’s a rather clever feature. The Secure Enclave Processor inside the iPhone keeps track of when the phone was last unlocked, and if that period exceeds 72 hours, the SEP will inform a kernel module. This kernel module will then, in turn, tell the phone to gracefully reboot, meaning no data is lost in this process. If the phone for whatever reason does not reboot and remains powered on, the module will assume the phone’s been tampered with somehow and kernel-panic. Interestingly, if the reboot takes place properly, an analytics report stating how long the phone was not unlocked will be sent to Apple. The reason this is such a powerful feature is that a locked iPhone is entirely useless to anyone who doesn’t have the right code or biometrics to unlock it. Everything on the device is encrypted, and only properly unlocking it will decrypt the phone’s contents; in fact, a locked phone can’t even join a Wi-Fi network, because the stored passwords are encrypted (and I’m assuming that a locked phone does not provide access to any methods of joining an open network either). When you have a SIM card without any pincode, the iPhone will connect to the cellular network, but any notifications or calls coming in will effectively be empty, since incoming phone numbers can’t be linked to any of the still-encrypted contacts, and while the phone can tell it’s received notifications, it can’t show you any of their contents. A thief who’s now holding this phone can’t do much with it if it locks itself like this after a few days, and law enforcement won’t be able to access the phone either. This is a big deal in places where arrests based purely on skin colour or ethnicity or whatever are common, like in the United States (and in Europe too, just to a far lesser degree), or in places where people have to fear the authorities for other reasons, like in totalitarian dictatorships like Russia, China or Iran, where any hint of dissent can end you in harsh prisons. Apple is always at the forefront with features such as these, with Google and Android drunkenly stumbling into the open door a year later with copies that take ages to propagate through the Android user base. I’m legitimately thankful for Apple raising awareness of the need of features such as these – even if they’re too cowardly to enable them in places like China – as it’s quite clear a lot more people need to start caring about these things, with recent developments and all.

Old-school Apple fans probably remember a time, just before the iPhone became a massive gaming platform in its own right, when Apple released a wide range of games designed for late-model clickwheel iPods. While those clickwheel-controlled titles didn’t exactly set the gaming world on fire, they represent an important historical stepping stone in Apple’s long journey through the game industry. Today, though, these clickwheel iPod games are on the verge of becoming lost media—impossible to buy or redownload from iTunes and protected on existing devices by incredibly strong Apple DRM. Now, the classic iPod community is engaged in a quest to preserve these games in a way that will let enthusiasts enjoy these titles on real hardware for years to come. ↫ Kyle Orland at Ars Technica A nice effort, of course, and I’m glad someone is putting time and energy into preserving these games and making them accessible to a wider audience. As is usual with Apple, these small games were heavily encumbered with DRM, being locked to both the the original iTunes account that bought them, but also to the specific hardware identifier of the iPod they were initially synchronised to using iTunes. A clever way around this DRM exists, and it involves collectors and enthusiasts creating reauthorising their iTunes accounts to the same iTunes installation, and thus adding their respective iPod games to that single iTunes installation. Any other iPods can then be synced to that master account. The iPod Clickwheel Games Preservation Project takes this approach to the next level, by setting up a Windows virtual machine with iTunes installed in it, which can then be shared freely around the web for people to the games to their collection. This is a rather remarkably clever method of ensuring these games remain accessible, but obviously does require knowledge of setting up Qemu and USB passthrough. I personally never owned an iPod – I was a MiniDisc fanatic until my Android phone took over the role of music player – so I also had no clue these games even existed. I assume most of them weren’t exactly great to control with the limited input method of the iPod, but that doesn’t mean there won’t be huge numbers of people who have fond memories of playing these games when they were younger – and thus, they are worth preserving. We can only hope that one day, someone will create a virtual machine that can run the actual iPod operating system, called Pixo OS.

The iPhone 16 family has arrived and includes many new features, some of which Apple has played very close to its vest. One such improvement is the inclusion of JPEG XL file types, which promise improved image quality compared to standard JPEG files while delivering relatively smaller file sizes. Overall, JPEG XL addresses many of JPEG’s shortcomings. The 30-year-old format is not very efficient, only offers eight-bit color depth, doesn’t support HDR, doesn’t do alpha transparency, doesn’t support animations, doesn’t support multiple layers, includes compression artifacts, and exhibits banding and visual noise. JPEG XL tackles these issues, and unlike WebP and AVIF formats, which each have some noteworthy benefits too, JPEG XL has been built from the ground up with still images in mind. ↫ Jeremy Gray at PetaPixel Excellent news, and it will hopefully mean others will follow – something that tends to happen when Apple finally supports to the new thing.

The European Commission has taken the next step in forcing Apple to comply with the Digital Markets Act. The EC has started two so-called specification proceedings, in which they can more or less order Apple exactly what it needs to do to comply with the DMA – in this case covering the interoperability obligation set out in Article 6(7) of the DMA. The two proceedings entail the following: The first proceeding focuses on several iOS connectivity features and functionalities, predominantly used for and by connected devices. Connected devices are a varied, large and commercially important group of products, including smartwatches, headphones and virtual reality headsets. Companies offering these products depend on effective interoperability with smartphones and their operating systems, such as iOS. The Commission intends to specify how Apple will provide effective interoperability with functionalities such as notifications, device pairing and connectivity. The second proceeding focuses on the process Apple has set up to address interoperability requests submitted by developers and third parties for iOS and IPadOS. It is crucial that the request process is transparent, timely, and fair so that all developers have an effective and predictable path to interoperability and are enabled to innovate. ↫ European Commission press release It seems the European Commission is running out of patience, and in lieu of waiting on Apple to comply with the DMA on its own, is going to tell Apple exactly what it must do to comply with the interoperability obligation. This means that, once again, Apple’s childish, whiny approach to DMA compliance is backfiring spectacularly, with the company no longer having the opportunity to influence and control its own interoperability measures – the EC is simply going to tell them what they must do. The EC will complete these proceedings within six months, and will provide Apple with its preliminary findings which will explain what is expected of Apple. These findings will also be made public to invite comments from third parties. The proceedings are unrelated to any fines for non-compliance, which are separate.

Apple is making additional changes to its app ecosystem in the European Union to comply with the terms of the Digital Markets Act. The default browser selection experience that’s already in place will be updated, Apple will allow EU users to set defaults for more types of apps, and core iOS apps like Messages and the App Store will also be deletable. iPhone owners in the EU can already set different defaults for the browser, mail app, app marketplace, and contactless payments, but Apple is going to allow users to select new defaults for phone calls, messaging, password managers, keyboards, call spam filters, navigation, and translation. That means, for example, that EU users will be able to choose an app like WhatsApp instead of Messages to be their default texting app, or a mapping app like Waze to be the default instead of Apple Maps. ↫ Juli Clover at MacRumors It’s clear by now that Apple’s malicious DMA compliance attempts have proven to be an abject failure. Apple continuously needs to backtrack and give in more and more to the European Commission, without the Commission even having to really do anything at all. Slowly but surely, Apple is complying with the DMA, all while its toddler tantrums have done serious damage to the company’s standing and reputation without having any of the desired effects for Apple. Whoever set out this toddler DMA strategy at Apple should probably be fired for incompetence. This latest round of additional changes to comply with the DMA are very welcome ones, and further solidify the EU version of iOS as the best version. Not only do iOS users in the European Union get different browser engines, they can also remove larger numbers of default applications, set more default applications, replace more Apple-services with third-party ones, and so on. Thanks to the DMA, iOS is finally becoming more of a real operating system, instead of a set of shackles designed primarily to lock users in. It’s only a matter of time before laws similar to the DMA spread to the rest of the world, and I honestly don’t think the United States is going to stay behind. Corruption in the US is widespread, but there’s only so much money can do, even in US politics.

A story you hear all the time about the Apple IIGS is that Apple purposefully underclocked or limited its processor in some way to protect the nascent Macintosh, and ensure the IIGS, which could build upon the vast installed base of Apple II computers, would not outcompete the Macintosh. I, too, have always assumed this was a real story – or at least, a story with a solid kernel of truth – but Dan Vincent decided to actually properly research this claim, and his findings tell an entirely different story. His research is excellent – and must have been incredibly time-consuming – and his findings paint a much different story than Apple intentionally holding the IIGS back. The actual issue lied with the production of the 65816 processor that formed the beating heart of the IIGS. It turns out that the 65816 had serious problems with yields, was incredibly difficult to scale, and had a ton of bugs and issues when running at higher speeds. What a ride, huh? Thanks for making it this far down a fifty-plus minute rabbit hole. I can’t claim that this is the final take on the subject—so many of the players aren’t on the record, but I’m pretty confident in saying that Apple did not artificially limit the IIGS’ clock speed during its development for marketing purposes. Now, I’m not a fool—I know Apple didn’t push the IIGS as hard as it could, and it was very much neglected towards the end of its run. If the REP/SEP flaws hadn’t existed and GTE could’ve shipped stable 4MHz chips in volume, I’m sure Apple would’ve clocked them as fast as possible in 1986. ↫ Dan Vincent Promise me you’ll read this article before the weekend’s over. It’s a long one, but it’s well-written and a joy to read. You’ll also run into Tony Fadell – the creator of the iPod – somewhere in the story, as well as a public shouting match, and an almost fistfight, between the creator of the 65816 and Jean-Louis Gassée during San Francisco AppleFest in September 1989, right after Gassée placed the blame for the lack of a faster IIGS on the 65816’s design. This is an evergreen article.

We’ve been talking a lot about sleazy ways in which the online advertising industry is conspiring with browser makers – who also happen to be in the online advertising industry – to weaken privacy features so they can still track you and the ads they serve you, but with “privacy”. They’re trying really hard to make it seem as if they’re doing us a huge favour by making tracking slightly more private, and browser makers are falling over themselves to convince us that allowing some user and ad tracking is the only way to stop the kind of total everything, everywhere, all at once tracking we have now. We’ve got Google and Chrome pushing something called “Privacy Sandbox“, and we’ve got Mozilla and Facebook pushing something called “Privacy-Preserving Attribution“, both of which are designed to give the advertising industry slightly more private tracking in the desperate hope they won’t still be doing a lot more tracking on the side. Safari users, meanwhile, have been feeling pretty good about all of this in the knowledge Apple cares about privacy, so surely Safari won’t be doing any of this. You know where this is going, right? Today, the WebKit project published a lengthy blog post detailing all the various additional measures it’s taking to make its Private Browsing mode more, well, private, and a lot of them are great moves, very welcome, and ensure that private browsing on Safari is a little bit more private than it is on Chrome, as the blog post gleefully points out. However, not long into the blog post, the shoe drops. We also expanded Web AdAttributionKit (formerly Private Click Measurement) as a replacement for tracking parameters in URL to help developers understand the performance of their marketing campaigns even under Private Browsing. ↫ John Wilander, Charlie Wolfe, Matthew Finkel, Wenson Hsieh, and Keith Holleman A little further down, they go into more detail: Web AdAttributionKit (formerly Private Click Measurement) is a way for advertisers, websites, and apps to implement ad attribution and click measurement in a privacy-preserving way. You can read more about it here. Alongside the new suite of enhanced privacy protections in Private Browsing, Safari also brings a version of Web AdAttributionKit to Private Browsing. This allows click measurement and attribution to continue working in a privacy-preserving manner. ↫ John Wilander, Charlie Wolfe, Matthew Finkel, Wenson Hsieh, and Keith Holleman So not only does Safari already include the kind of tracking technology everyone is – rightfully – attacking Mozilla over for adding it to Firefox, Apple and the Safari team are actually taking it a step further and making this ad tracking technology available in private browsing mode. The technology is limited a bit more in Private Browsing mode, but its intent is preserved: to track you and the ads you see online. I would hazard a guess that when you enable a browser’s private browsing or incognito mode, you assume that means zero tracking. We already know that Chrome’s Incognito mode leaks data like a sieve with bullet holes in it, and now it seems Safari’s Private Browsing mode, too, is going to allow advertisers to track you and the ads you see – blog post full of fancy privacy features be damned. Do you know those “Around the web” chumboxes? Even if you’re unfamiliar with the term, you’ve most definitely seen these things all over the web, and really hate them. A major player in the chumbox business is a company called Taboola, a name that’s quite despised and reviled online. Popular Apple blogger John Gruber called Taboola a “slumlord” and the “lowest common denominator clickbait property“. Do you want to know which major technology company just signed a massive deal with Taboola? Ad tech giant Taboola has struck a deal with Apple to power native advertising within the Apple News and Apple Stocks apps, Taboola founder and CEO Adam Singolda told Axios. ↫ Sara Fischer at Axios Apple needs to find new markets to keep growing, and clearly, pestering its users with upsells and subscriptions to its services isn’t enough. The online advertising industry is massive – just look at Google’s and Facebook’s financial disclosures – and Apple seems to be interested in taking a bigger slice of that fat pie. And as Google and now Mozilla are finding out, a browser that blocks ads and ad tracking kind of gets in the way of that. Anyone who can make and sell plug-and-play Pi-Hole devices even normal people can use is going to make a killing.

A few weeks ago, I broke the news that Mozilla had removed several anti-censorship Firefox extensions from its store in Russia, and a few days later I also broke the news they reversed course on their decision and reinstated the extensions. Perhaps not worthy of a beauty prize, as a Dutch saying goes, but at least the turnaround time was short, and they did the right thing in the end. Well, let’s see how Apple is going to deal with the exact same situation. Novaya Gazeta Europe reports that bowing under pressure from the same Russian censors that targeted Mozilla, the company has removed a whole slew of VPN applications used by Russians to evade the stringent totalitarian censorship laws in the warmongering nation. Apple has removed several apps offering virtual private network (VPN) services from the Russian AppStore, following a request from Roskomnadzor, Russia’s media regulator, independent news outlet Mediazona reported on Thursday. The VPN services removed by Apple include leading services such as ProtonVPN, Red Shield VPN, NordVPN and Le VPN. Those living in Russia will no longer be able to download the services, while users who already have them on their phones can continue using them, but will be unable to update them. ↫ Novaya Gazeta Europe Apple has a long history of falling in line with the demands from dictators and totalitarian regimes, and Russia is no stranger to telling Apple what to do. Earlier this year, Apple was ordered to remove an application developed by the team of the murdered opposition figure Alexey Navalny, and of course, Apple rolled over and complied. Much like Apple’s grotesque suck-up behaviour in China, This stands in stark contrast to Apple’s whining, complaining, and tantrums in the European Union. It seems Apple finds it more comfortable to operating under dictators than in democracies.