Phones are tools so why is it that whenever those tools are used in a way where money changes hands, the maker of that tool gets some of the revenue?
Imagine a tool company demanding a cut of the revenue a building generates because their tools were/are used during the construction/maintenance of that building. Everyone using the tool already paid for the tool!
Without comment on specifically whether or not Apples actions are reasonable, I suspect that if tool manufacturers were expected to provide years of free upgrades to end users of their tools in order to support an ever changing security landscape and close any issues caused by the combination of their tools with 3rd party services, that tool manufacturers would be interested in getting a continual cut of revenue generated by those interactions.
That is, if I buy a paint sprayer, and combine the sprayer with paint sold at Home Depot that a 3rd party maliciously contaminated with caustic chemicals and that combination of sprayer and caustic chemicals caused a reaction in the paint that melts my walls, no one expects the sprayer manufacturer to give me a free new sprayer or even upgrade my current sprayer to be hardened against 3rd party contamination.
On the other hand if NFC protocols today are discovered in 3 years to have a flaw that 3rd parties are using to steal financial data, it’s Apple whose name will be dragged if they only make a change to NFC in newer model phones.
Your comparison doesn't make sense to me: Isn't it much more like Home Depot selling a paint sprayer that, under some circumstances, blows up the attached can of paint? That would absolutely mandate a product recall!
Apple isn't expected to fix bugs in a third party's app using their APIs, but they're totally expected to fix those APIs, should they be faulty (conceptually or in their implementation).
Obviously that costs money, which they can make either from the sales of the phone alone, or via some subscription model for ongoing updates (remember when OS updates used to be paid? A new OS X version used to cost a hundred bucks!).
To stick with the Home Depot example: Why should the manufacturers of third party paint cartridges pay for Home Depot's product safety obligations?
> Apple isn't expected to fix bugs in a third party's app using their APIs, but they're totally expected to fix those APIs, should they be faulty (conceptually or in their implementation).
The problem is what we expect to be fixed for a software product and a hardware product are two different things. If you buy a car, and the next year the car company discovers they can get even more fuel efficiency with a different piston design, or they can improve crash safety with new airbag locations, we don't expect car manufacturers to recall all the current model year cars. We only expect recalls for failure to perform the expected functions that were expected at the time of sale.
On the other hand, when a new version of SSL or TLS is released, when root CA certs expire or change, when new Wi-Fi encryption standards are released, we expect those updates to our old devices, almost always expected gratis and for many years after the initial sale. Look at the substantial amount of complaining every time some software company like Apple or Google announce the end of software support for some old hardware. We treat these devices differently from a tool you buy at the hardware store.
And yes, Apple is expected to issue fixes bugs that 3rd parties bring to the table. Which is exactly what expecting updates for things like stronger encryption cyphers and the like are. They sold you a device that can speak Protocol X, developed by a 3rd party. You use that device to speak Protocol X to another 3rd party device or service. Yet another 3rd party invents some way to exploit Protocol X to do nefarious things. And everyone who bought the Apple device last year absolutely 100% expects apple to release an update when Protocol X++ is released.
And to be clear, I'm not saying this is unreasonable, but it's worth noting as you point out that software updates used to cost money (remember the annual "why is apple charging us for a point release?" song and dance?). And we should remember that developing software for platforms used to cost money too. A lot of money. How much were Visual Studio licenses? Code Warrior? A MS developer network license? Or check out Qualcom's BREW program for the multi thousand dollar up front process to put "bejeweled" on a flip phone. When companies stopped charging for OS updates and developer kits and SDKs, the money needed to make those things didn't stop needing to be made. We talk a lot around here about the lack of funding for open source projects. Well software and software development has a value. How much is it worth, and how many new things are we allowed to demand before the price has to go up somehow?
>To stick with the Home Depot example: Why should the manufacturers of third party paint cartridges pay for Home Depot's product safety obligations?
I suspect that if a paint company wanted to use Home Depot's credit card terminals to do sales for a custom sales process of paint accessories to Home Depot customers that Home Depot would want a cut of that.
In a hypothetical world where I bought a car, and the next year the car company discovers that they can get even more fuel efficiency with a different piston, or they can improve crash safety with new airbag locations, and if these already-developed changes could somehow be implemented for no more cost than a bit of Internet bandwidth, then:
I would be ABSOLUTELY LIVID if the car company extracted a tithing every time I used my car to make a delivery or a visited drive-through (or otherwise used my car for commerce).
They already do take that tithing, in the form of the amortized cost of the car over those transactions. Admittedly the amortized cost of your car doesn't scale with your transaction volume or income (baring extra wear and tear concerns) but – as long as we're torturing analogies to death – you also can't buy your car on a "no up front costs and no costs at all to try it out for yourself and a flat $100 / year as long as you don't make money with your car and 15% on revenue if you do" lease agreement.
*I suspect that if tool manufacturers were expected to provide years of free upgrades to end users of their tools in order to support an ever changing security landscape and close any issues caused by the combination of their tools with 3rd party services, that tool manufacturers would be interested in getting a continual cut of revenue generated by those interactions.
This is an actual issue in the real world that is dealt with using "support contracts." They've only been around for a few centuries or so...
Apple's problems are those of its own making. And if it keeps trying to bait regulators like this, it may soon find itself referred to as "Ma Apple" and its former divisions as "Baby Apples."
So which of the following "support contracts" do we suppose the EU would be happy with and doesn't violate the DMA?
Paid iOS updates in the EU? I remind you that the EU argued that a paid ad free version of Facebook's services violates the DMA.
A per-install fee for services developed with Apple's SDKs? That's basically the CTF and that hasn't been met with resounding happiness.
A flat revenue sharing agreement a-la most of the major game engines? That's the core iOS platform model that the DMA is partially a response to.
I suppose we could go back to multi-thousand dollar up front per seat SDK licenses on annual contracts the way folks like Microsoft, Oracle, Qualcomm, Blackberry and Apple used to do, but that really hurts the smaller developers and is part of why the iOS model was such a huge deal when it was first announced.
Look, I'm not arguing that Apple isn't and doesn't make moves that are short sighted and seem purposefully designed to piss off the regulators. But I also don't actually see any option that isn't "free, unlimited, unrestricted access to all of Apple's SDKs and libraries indefinitely" that will ultimately satisfy. No one seems to have an answer for what model Apple can use that
A) Covers their costs
and
B) Allows them to continue to do whatever it is that makes it such that iOS does all these things that Android and Android vendors can't apparently do despite being more open and free
Apple has had no problems with providing their macOS libraries, tooling, and associated updates for free, even with a drastically smaller user base, and it appears to have been sustainable for decades.
The truth of the matter is Apple would almost certainly continue to do offer their iPhone services, updates, app store, etc; even if they were statutorily prohibited from making any money off of any of it, because in the end it makes for a better user experience and helps them differentiate and sell their phones at a premium.
What is happening, is the more financial-minded types within Apple have realized they have substantial lock-in and market power, and they can leverage it to take a % of profits from other market entities.
If you actually care about Apple products, and want them to continue to deliver great products well into the future, then the best thing that could happen would be for them to get the message and accept a loss in this battle. Otherwise you will see increased financialization continue until they are thoroughly hollowed out of great product/engineering culture, and collapse under their own weight, like so many before them.
> Look, I'm not arguing that Apple isn't and doesn't make moves that are short sighted and seem purposefully designed to piss off the regulators. But I also don't actually see any option that isn't "free, unlimited, unrestricted access to all of Apple's SDKs and libraries indefinitely" that will ultimately satisfy. No one seems to have an answer for what model Apple can use
I do, hardware sales should be more than enough. They already cover the device's (and iOS's) R&D costs with more money to spare. This whole brouhaha is due to them simply wanting more, not because they wouldn't survive/profit at all without their current measures.
> They already cover the device's (and iOS's) R&D costs with more money to spare.
So like I said, "free, unlimited, unrestricted access to all of Apple's SDKs and libraries indefinitely", just with an implied "with all costs borne by the end consumer purchasers of the hardware" tacked on to the end? Obviously all costs are eventually borne by the consumer, but given that Apple has dropped the "can't charge more on iOS then elsewhere" requirements, couldn't developers just raise their prices for their products on iOS and we could skip all of this extra rigamarole?
Edit:
And to be clear, I really don't have a huge issue with a developer saying "I don't want to pay any of the costs of supporting or developing the platform that I use to sell my goods and services. I want the provider of that platform to extract the costs of providing that platform to me from the end users on that platform that I am selling to". That's a well trod model in the computer space, and it would be hypocritical of me to argue that's somehow wrong when my entire professional career is built on platforms and services that I pay nothing to maintain or support.
I just think that we should recognize what we're doing and be honest with ourselves. Part of why major open source projects have funding issues is in part because we do this a lot in the software world, but a lot of those open source projects don't have end users to charge either because the developers are the end users. We are lucky that Apple has end users to bear our costs for us.
No one seems to have an answer for what model Apple can use
Every support contract of this nature that I've seen is a fixed, flat fee. And someone, businesses outside of tech, with their far higher costs, are able to make it work.
Apple could easily use this business model, but its profits would be far lower. Apple's grown quite large and comfortable with a business model centered around illegal profits (in this context, referring to the excess profits derived from their anti-competitive behavior) and like other businesses premised on abusive behavior, it's going to fight.
With that logic maybe banks and credit card companies should start skimming 30% off each transaction. [EDIT] They should also strong-arm you to prevent you mentioning cash as an alternative.
Credit cards do already skim a percentage off every transaction you make with them and, until very recently and an act of congress, actually did restrict vendors from offering a separate price for cash transactions. They were perhaps not so bold as to try and claim 15-30% of the gross. Notably stores accept (or refuse) various credit cards in part due to their percentage of the take, with AmEx being notoriously higher than others.
Apple makes famously insane margins off each iPhone sold. I don't think they can legitimately fall back on the "but we can't support it otherwise", since they already do. The cost of developing new iOS builds is amortized by the hardware they sell and the profit they rake in. Even when service revenue was a shadow of what it is today and Apple was far less liquid, they had no problem supporting their hardware.
In professional industries like avionics, automation and fabrication, open tooling and security maintenance is the baseline expectation. It's only in captive consumer markets that businesses can convince their customers that they don't want the freedom to use what they paid for.
>I don't think they can legitimately fall back on the "but we can't support it otherwise", since they already do. The cost of developing new iOS builds is amortized by the hardware they sell and the profit they rake in.
Those costs are amortized over the hardware sales specifically based on the current revenue model of the iOS platform. If you force a change in the model, or force them to produce new APIs and SDKs they had no intention of making and therefor no need to amortize, then I think yes they can fall back on "we can't support it otherwise".
The real simple question that has been never been answered in this entire discussion over and over again is what is the fair market value of Apple's SDKs, access to their platform and the support that provide for that platform if its not amortized over hardware sales and current revenue split agreements? Forget even trying to answer that for the entire iOS platform. If Apple puts NFC chips in their phones, and then:
1) Has to write an entire public SDK they weren't intending to write
2) That allows access to those chips outside their specific sanctioned and envisions use case
3) That requires providing ongoing support for that SDK and the uses of it outside their specific sanctioned use case
4) Expands their security threat surface for the underlying secure hardware that SDK will interact with and requires more development to secure it
How much money is that worth in cold hard cash up front per developer per update per hardware revision?
Apple is selling a platform to end users and they hold durable market power with that platform, due to high switching costs and minimal alternatives. End users consume services by various third parties on the platform. In addition Apple is also offering services on the platform that compete with those third parties.
It's entirely fair to say to Apple (and companies in similar oligopoly positions) that if you want to compete with third parties on your platform then you need to do so on a level playing field.
It's not then about forcing Apple to build a feature at no cost, but rather declaring that Apple built their NFC feature improperly, by building it in a way that prevented competitor use, illegally privileging their own competing services. They can either remove the feature or build it properly, according to relevant law.
I think the problem from Apple's perspective is the assumption they're building this platform to compete with 3rd parties. NFC payments is a perfect example of this, where I think from their perspective it wasn't "built improperly" because it was never built with the intention of 3rd parties accessing it directly, any more than Amazon storage provisioning tools are built incorrectly because AWS users can't build their own S3 competitor on top of those tools.
Edit:
I've talked about this in a previous discussion, but we have a sort of arbitrary line we draw on what should or shouldn't be a service / integral part of an OS / Platform and what should be, for lack of a better term, hot swappable by the end users.
On the one hand, you have the sort of "GNU Maximalist / Microkernel" approach, where everything is replaceable. On the other you have the "iOS / Video Game Console" approach, where the system is largely a black box and you get an API and can do things with that API but you can't swap out anything not controllable by the API. There's no objective place to draw that line though, it's all dependent on the experience your platform is designed to provide. Why is "displaying text to the screen" a service we delegate to the OS? Why does Linux consider window management an "application" to be swapped out, but Windows and macOS consider it an integral part of the OS platform? Why do we expect an OS to provide a TCP/IP stack these days, and no one complains that they can't implement their own TCP/IP stack in their mobile app? Clocks are widgets in linux, and an integral part of the OS in windows and macOS. Heck even down to the programming language level we don't have consistency. Is C necessarily better or worse than say Python or Javascript because it doesn't have a native String type and you can pick your String library?
As far as I understand, yes. It's kind of astounding to me that the world has self-inflicted what is essentially a cyber attack trying to protect a poorly architected OS from actual cyber attacks when a much better architected OS is known and running on nearly all the servers in the world.
On Windows, software regularly mucks around in the kernel (device drivers, system level tools like wireshark, etc), therefore it is also necessary for security software like CrowdStrike to also muck in the kernel so it can monitor what all the other kernel level software is doing. As demonstrated today, anything that mucks in the kernel runs the risk of crashing the kernel.
In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access. The kernel still decides what root is able to do. Drivers that require that access are built into the kernel. Software that requires deeper access like Wireshark tells the kernel what to do (through system calls as root) and the kernel does it on that programs behalf. Therefore, the kernel knows everything that any program does on the system. With a trustworthy kernel, all that security software must do is instruct the kernel to monitor activity on it's behalf.
worth noting Microsoft had a solution a few years ago that would of prevented this issue from happening, Windows 10X, due to atomic updates.
> In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access.
root has kernel access, even if the kernel restricted it, it can write to the disk and change the boot process.
also worth nothing that a popular form of software distribution on Linux is curl http://randomscript.sh | sudo sh which is arguably worse than anything on Windows.
Yeah that's true. Microsoft really needs to push forward with a new architecture at the core of windows. Stuff like what has happened today is inevitable under the current model where so much stuff has kernel level access. I just expected it to happen with something like anti cheat that doesn't have quite the oversight that I would assume CrowdStrike has in comparison.
Root has access to the kernel but the kernel knows everything that happens and that's my point. The kernel won't stop you from compiling a new kernel and setting it to run at the next boot. However, CrowdStrike running on Linux with eBPF for example would be able to identify and prevent such tampering without truly being in the kernel itself.
The most common way to install software on Linux is from your trusted distro repositories and from Flathub or the Snap store. Grabbing a script from the internet and piping it to a root shell is bad and something I'm sure we've all done. But take the most installed program on Windows which is likely Chrome, it really doesn't do anything differently. You download a small executable which requests admin, then it proceeds to download Chrome and install it. I'd argue grabbing a script might be the safer option because unlike installer executables from the internet, you at least have the option to read the script before running it if you choose.
I was gonna say this.
They need to allow third party browsers the ability to create PWAs, but they can't (or don't want to).
So instead they just disabled it, saying that it was not possible, and wait for the backlash to restore it for them only.
Now we are at the beginning, PWAs are locked to Apple...but apparently that's good? I don't understand...
If this was their plan it’s not a good one. There’s no indication that the EU was interested in PWAs before this, but now Apple have made it a cause célèbre and brought the issue to the attention of the EU.
OWA says the plan was maliciously neglecting to mention the "killing" of PWAs. Hanlon's razor would require us to assume there was no malice and that there was mention because there was no such plan.
Maybe, maybe not. It can also be explained by Apple wanting to do the minimum required. First choice: no PWA support at all, Second choice: PWA support independent of custom browser support, and final choice (most work): PWA support on top of the custom browser support.
The only thing we know for certain is Apple has shown no interest in making the best user experience given the rules vs complying with the rules only where required to.
That said, I doubt it here. they thought a feature was barely used and got enough flack to realize it may get them in deep wanted with DMA. But we don't know how strict they are with PWAs specifically. They probably backed off to prevent anymore of the various issues they caused themselves over this whole thing.
If so, it’s working. Now all the commenters who assume that Apple is doing the worst thing possible at all times are praising the EU for forcing Apple to save PWAs.
Otherwise they’d be complaining about how Apple was intentionally crippling PWA support by not letting you pick the rendering engine used.
I make a free mac utility and would be fine with notarizing it if it wasn't $100 a year. I don't want to pay $100 a year to give away something for free. And the message that pops up telling users to "contact the developer" because "the app needs to be updated" is just infuriating. To me it feels like Apple asking users of unnotarized apps to bug developers into paying Apple that $100 a year.
It's completely unrelated to M1 and also affecting Mojave and Catalina, apparently. It's a security signature check service problem. Some might argue that it should be easy to disable security signature checks, system wide (which is what the provided instruction achieve). Many more would probably argue that disabling these checks would be bad for security, especially for the average user.
I'm curious what security researchers think of this. Further evidence that security is a doomed endeavor, since it's necessarily at odds with convenience?
I know it's unrelated. I have a Mac and was unable to do any work for around an hour, had no idea why. Windows has smart screen, but if the service is unreachable you get a popup. This is just completely unacceptable, if it's possible that a server issue could cause all apps to fail locally, there should at least be a popup explaining that's why nothing is working. I'm fed up with far more than just this. I'm saying any temptation I had for an M1 Mac is now gone.
Lets say theoretically PC gaming didn't exist. If the only way to play games was with a console from Sony, Microsoft, or Nintendo do you really think they would be selling consoles at a loss[1]? PC gaming is what keeps consoles priced competitively. If smartphones are like consoles, then currently you can only buy consoles. Sure Android is a little bit more open than iOS but not by much. There's not a problem with the existence of walled gardens / console-like devices, but there needs to be options available that aren't so restricted. Currently 99% of the smartphone market is controlled by Apple and Google, neither of which are willing to give up their control so I think this is a case where some kind of intervention is required to introduce competition.
I made a Mac app a few weeks ago that got to the front page here on HN[1]. It isn't notarized by Apple since I don't want to pay Apple just so I can give my work away for free that fixes something that shouldn't be an issue in their OS in the first place. When users run the app for the first time, they get a warning[2]. For that kind of popup to happen when anyone tries to use anything by Epic would almost certainly dissuade new users a bit. Currently you can run unsigned code on macOS if you disable some security options in preferences but soon that won't be possible[3]. It's already the case that unsigned code can't run on iOS, so for Epic to develop an engine on iOS they must be able to sign their IPA files so they can actually be installed on a testing iOS device which can only be done through Apple.
Thanks for sharing your experience. I also work on a free utility for macOS that I'm not paying $100 each year to release. As a result, macOS treats that app like it's radioactive.
It's a disservice to users who intentionally download the app to improve their experiences, only to find out that the program is a second-class citizen on macOS, and they need to perform a security ritual to use it. If the users don't know what the ritual is, to them, the app is just broken.
I recognize the writing on the wall, though. macOS isn't a platform to hack around on anymore, it's Apple's platform to extract rents from its developers and users. If your app or use case doesn't fit into that ecosystem, that's just too bad.
Yes exactly. From the perspective of the user, macOS treats you fairly. Apple carefully words everything to shift the blame to developers for things like notarization. The message that appears when apps aren't notarized puts the blame on the developer by saying "This software needs to be updated. Contact the developer for more information". To the user who doesn't know any better it's the developer's fault. Apple takes great care to ensure users never blame something that has gone wrong on Apple themselves.
Users get a good experience on macOS and iOS so they will continue buying Apple devices which also leads to more people switching to Apple devices due to pressures of things like iMessage. Meanwhile developers are essentially forced to agree to Apple's terms to access an extremely significant portion of the market (especially when it comes to smart phones). Those terms effectively censor developer criticism by preventing developers from explaining their situation to users. If developers don't comply, their apps will be removed and their development certificates revoked on all Apple platforms. As a user Apple feels fair, as a developer it's painfully obvious that Apple is abusing their market position. Look at what's happening with Floatplane: https://www.youtube.com/watch?v=1QzHu-sjdB8
Unless things change, I don't think I will choose to purchase an Apple device ever again. But if their market share continues to increase it will be impossible to survive as a developer without releasing for Apple devices and to develop for Apple devices I will be forced to buy their devices. The App Store and everything Apple offers is certainly worth something. Is it worth 30%? Who knows. The market isn't what decided that fee, Apple and all other software storefronts have somehow arrived at that number themselves. With no realistic way for competitors to offer alternative software storefronts on iOS and Android at their own price to compete and bring fees to their true value, we will never know.
How is this any different from Windows? If your code is not signed with an EV code signing certificate, a similar warning will be shown on Windows. The difference is that, that certificate will set you back 500-600 USD a year. Though I believe you can obtain "trusted" status without a cert through people using your software and not reporting it as malware.
Microsoft isn't the only provider of certificates. It's more like the web where there are many authorities, not just one. If Epic were getting their cert from Microsoft and Microsoft retaliated to something Epic did with Fortnite on Xbox by revoking their certificate on Windows, Epic could just switch to a different provider for their EV cert.
The other difference is the message itself. Windows just displays a warning that the software couldn't be checked by smartscreen.[1] Once the app is used by enough people for the app to be in the smartscreen system the warning will disappear. Users will still see that the publisher is "unknown" though.[2] MacOS directs users to contact the developer that the app must be "updated" even if the only issue with the app is that it isn't notarized. A more fair message would be along the lines of "This app has not been notarized by Apple. Only run the application if you trust the source."
Code signing is intended to verify that the app actually came from who you think it came from. If the certificate for MS Word is unknown or something other than Microsoft you know something's not right and it's either been modified by a third party or not MS Word at all. Apple is using code signing to exert control over Epic Games rather than it's intended purpose to verify to MacOS users that their Unreal Engine in fact came from Epic.
Imagine a tool company demanding a cut of the revenue a building generates because their tools were/are used during the construction/maintenance of that building. Everyone using the tool already paid for the tool!