Bad news, developers: Apple Mac App Store tells cross-platform Electron apps to get lost Developers of apps built with the cross-platform Electron framework say that Apple has started rejecting their applications during its Mac App Store review process, and has threatened cancellation of Apple Developer Accounts for repeated rules violations. The issue was first raised in August and only affects Electron apps …
And therein lies the rub : consistency. Apple is well-known for wanting to control everything, but how it controls is not consistent. It is useless to lay down a rule if you only enforce it after years of ignoring it. That is how you get backlash and discontent among your user base.
Of course, it may be that Apple has decided it doesn't care, but the lapse between declaring the rule and enforcing it is just sloppiness. When a company decides to only accept Word files as job submissions, you can bet that it won't let the first 20 PDF files through anyway, just because. No, those PDF files are going straight to the round filing cabinet and those who submitted are likely never even going to hear about it.
Apple are not the only company to have 'private API's'.
I was once bitten by this. We were happily using said private API's with the PHB telling us in almost every meetiing that it was 'fine, I have permission' only to find that the API returns had all changed after one update.
Said PHB had to admit to his PHB's that he was full of Sh1t.
Three monthe of coding, testing and faffing around with release engineering we got an updated program out the door and all our customers could update their systems.
You take a risk when using private API's of any sort. If you are happy with the rug being pulled from under your feet then fine. Otherwise, they should be labelled
"Here Be Dragons!"
The problem is not in private APIs or not. The problem is the rule said do not use them, developers used them and got away with it for a while, building their base and reputation, and now boom, no more private APIs.
That is not consistent. The developers should never have been able to post those apps in the first place. That would have been consistent.
After that, if you don't like it is another matter entirely. But if you ban them then you ban them from the start, not after a few years of saying so.
"The problem is not in private APIs or not. The problem is the rule said do not use them, developers used them and got away with it for a while, building their base and reputation, and now boom, no more private APIs."
I'm not a developer and have no idea how long it can take to recode an app, so this is genuine curiosity: How long SHOULD a company wait after saying "Coding Thing X is prohibited and all apps which use it will be removed from our repository"? Because, honestly, I've seen Apple get ripped by commentards here if they say something is prohibited and ban it and remove affected apps immediately, and here they are getting it because they didn't enforce the rule "soon enough".
So, is there a time-frame between banning a thing and actively enforcing that ban that is acceptable to the general community (ignoring the knee-jerk "AppleSux!" brigade who will always fault them)?
These are Objective-C classes; since Objective-C is a fully reflective runtime, the mere fact that a class exists makes it discoverable to an actor that is specifically searching. Rather than maintain a long list of every single class name they've used anywhere and list all but the public ones as private, Apple merely says "if we haven't documented it, it's private".
So I feel Apple should shoulder some blame here for partial enforcement, as Chromium doesn't appear to have done anything to obscure its use of unpublished classes. They've reverse-engineered header-file definitions for them, which likely means they're not doing a runtime reflective lookup of the class name, but letting the linker do it at load time. So it should have been easily detectable.
Obviously Google is also at fault for its usual shoddy software engineering.
But the developers who are actually having their apps withdrawn? I vote sympathy for having been crushed between the two giants.
The dragons are stuck in so much epoxy as to be irreparable.
Apple is suspended over a sheer drop and they are reaching up and slowly cutting the only rope. Let them add more razor wire on top of their walled garden. Their billions in cash won't last forever.
Fan boys may click the down thumb now.
How about those who can count ropes also click the down "thumb"?
The slender thread of being able to deploy to the Mac App Store using cross-platform environments like Electron provided that they don't use private and undocumented APIs feels somewhat insubstantial compared to the money-printing machine that is the iPhone and its associated services.
In fact, if the whole Mac platform died tomorrow I suspect Apple would still be with us in 20 years.
Developers are being incredibly quiet about the obvious reason for the change: Apple didn't change the rule or change their enforcement of the rule, what changed was *how Apple detects violations*. Developers have been deliberately using a hack to trick Apple's private API detection system (ie. they manually link to private APIs so the APIs don't appear in the linker table), and Apple's private API detection system was just updated to catch this.
So all arguments that Apple has been "inconsistent" fall flat. The developers knew there was a rule, they wrote code to obscure the breaking of that rule, and are now complaining that Apple has figured out how to catch the people trying to hide it.
Electron has a number of drawbacks – builds tend to be large and memory-hungry, for instance – but the advantage of being able to use familiar web technology to create a single code-base that can generate builds for macOS, Linux, and Windows outweighs the downsides in many cases.
The downsides are pretty much all for the end user as their machine's RAM & disc get swallowed; the developer gets a much easier life in return.
The same could be said of any cross platform develeopment system. They all involve packaging every version of a product with redundant code in the runtime. It makes development easier (and therefore cheaper), but for the user, it can be wasteful, with them having to have a runtime installed that is potentially many times the size of the app being deployed. Used to annoy the f*k out of me to have to install hundreds of megs of Java Runtime at work, just some I could use a small (few hundred K) utility as part of my job, and don't get me started about Flash Player (which isn't large, just a bug ridden piece of crap security risk.
There's another downside - any vulnerability in the runtime could never be fixed, if there are no updates available. Those using a common run-time that can be update once for all (and is still backwards compatible) are a little better, but those bringing the whole runtime with them can become a liability.
At least native applications get OS API updates - as long as the OS doesn't break the application.
There are a few options for the user to choose Electron:
1. You like 4 cylinder engines that get 5 miles to the gallon.
2. You like wasting energy and being blatantly non-green.
3. You wish to waste as much time of your life loading form windows.
4. You want as little disk space and RAM as possible.
5. You don't give a damn, you're told it's for cool kids.
Users don't choose the framework, Users choose the application.
It is the application developers who choose the framework, development language, etc.
I don't use Electron, but for many who make their living writing code the cost savings of rapid development and cross-platform deployment are important considerations that overshadow the performance impacts of the resulting build.
If on desktop you can use Ripcord. It's a Qt-based Discord and Slack client all in one.
Mobile might be trickier. Personally I'd ultimately lay the blame at Apple's feet for not providing public APIs that meet developer needs. (This is at times a problem for Windows as well, of course. But perhaps less so due to anti-trust remedies.)
"Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store."
That's the nuclear threat option exercised blasting open rather than closing access portals. Not the smartest of available moves.
I dont program on these things but it strikes me that if user apps can actually make API calls that Apple dont want them to then the problem lies in a shit security implementation.
I dont know how Apple check this but I dare say I could think of a way of preventing MY app making those calls until long after the app is distributed and disguising the API call in some way so it is not immediately apparent to a code scan. These things should not be callable from 'USER' space full stop.
The only obvious ways on modern hardware would be to hide everything behind interprocess communication (with its inefficiency) or put the entire implementation in the kernel (insecure, panic-prone, and also often slower due to frequent kernel mode switching).
Long, long ago there was an architecture called the VAX which had 4 rings: kernel, executive, supervisor and user. The kernel had the, well, kernel. Executive mode had the filesystem: you could only call to nominated entry points via a trap, and if it crashed, it couldn't take the kernel with it. Supervisor mode had the command shell, and finally user mode the actual application.
Early Intel x86 had 4 rings too, but no-one used them so I think Intel relegated the unused 2 to an inefficient stub implementation, and have I think now deprecated or already removed them (while adding negative numbered rings for hypervisors). In any case, modern operating systems don't use them.
Now I hear you say that at least the linker symbols should have somehow been obfuscated or removed. But experience shows that even if you do that someone will figure it out and call it anyway. I recall on the aforementioned VAX/VMS systems there was a very popular third-party utility which "knew" the addresses of certain structures in the file system, and needed to be installed CMEXEC (i.e. define its *own* traps to ring 1). Of course, the operating system vendor got blamed when it broke on an operating system major version update when the magic addresses they were using changed.
I think the Electron people had it coming.
If these APIs are genuinely 'private' then why does Apple allow iOS to allow them to be called? I would have thought that it would be simple enough for Apple's own apps to identify themselves to iOS using a suitable private key to get access to anything Apple don't want to share with plebian developers those who help build the ecosystem they are completely reliant upon.
You wouldn't do it that way.
As a conceptual problem, allowing some programs to do some things and others to do others is what operating systems have been doing for longer than I've been breathing. Usually, the basis for the decision depends on some or all of "who is the user", "what has the user chosen to enable for this program", "what is this program" and "what other things is this program picking up on-the-fly". It can get quite complicated to describe, but it is not rocket science and it is not hard to come up with efficient implementations.
As an aside, the persistent failure of those who design "environments" and "virtual machines" and "sandboxes" to match the competence of those who design "operating systems" is a mystery to me. It's almost as though every time some re-invents the idea of limited access they are immediately transported back to 1959 and have to re-learn all of computer science.
"You wouldn't do it that way!"
It wasn't my suggestion; I was pointing out it was silly way to do it!
I suspect the problem here is that these are libraries which live in the process space of the app and are called by userspace libraries the app is allowed to use. It would be a bit like saying you don't want code calling printf() directly but using authorised output routines that call into it on your behalf. But printf() is there, in my process space; all the OS can do is hinder me finding it - it can't stop me calling it.
That's actually quite a hard problem to solve. Maybe the function could validate the return address is in allowed code range? But I bet that could still be exploited. The only way to block this is to move the library into a separate process. So I return to my original point: imagine printf means IPCing to a separate process which then calls back into the kernel on behalf of the first process and IPCs back the result. I'm a fan of message-passing and microkernels, but that's a step too far.
> Can you imagine every printf or SendMessage call having to validate a private key before preceding?
Who said every call would be validated? The app only needs to be be validated once by the OS as it starts running.
Thankfully ThomH does actually answer my question.
Because when iOS is updated and those APIs go away or are changed the code using those private APIs will be altered to match. That doesn't work for a third party app, which will simply break when iOS is updated.
Apple has history for this - a lot of developers used undocumented calls on the Apple II, with the result that Apple had to insert tons of JMP instructions in newer revs to account for their use by popular applications. They have had a rule against using private APIs ever since, but they have no way of "enforcing" it except in an 'app store' like setting where the binary can be checked to see what functions are being called.
Applications call Apple code that in turn calls the private APIs; since this calling code necessarily lives in the process space, it's not hard for a determined developer to locate the calls being made and start making them from the program itself, rather than via the Apple libraries. Unless you can figure out a way to only allow the authorized part of the address space(ie, the Apple code) to call the API, this isn't a problem that's going away(at least on x86 - if you were designing an architecture from scratch, this sort of permission segregation would probably be simple to implement).
ASLR and kernel/userspace checks and barriers on the calling functions.
If the Apple iOS is truly that disastrous in terms of security that you can just make up a pointer and call a random deep-OS function that should only be called by the OS, then they get everything they deserve in this day and age.
Imagine being able to "just call" deep-level OS functions that aren't exposed to you from unprivileged code... that's just a disaster waiting to happen.
It tells me exactly one thing - iOS apps are basically running as a privileged user, the APIs don't have any permissioning or ASLR-like defences, and they can't be bothered to push obsoleted functions through a shim so that they aren't exposed to the programmed libraries.
That a "determined programmer" of, say, a game, can inspect your API shim's code is a memory boundary violation in the first place... that they can then extract pointers to the underlying direct functions that aren't otherwise exposed is stupid... that they can then CALL/EXECUTE THOSE FUNCTIONS is ridiculous.
Someone teach Apple how to make a modern OS and incorporate privilege separation and memory barriers.
There's a reason that an unprivileged user on, say, Windows or Linux is unable to just jump into the kernel RAM, start probing for addresses and then jumping to those addresses to execute functions only used internally or by other processes/services.
"Why is it wrong for MS but OK for Apple?" The legal answer to that is that Apple currently have about 14% of the desktop market, whereas MS has about 80%, and that figure was probably higher when MS was being investigated for anti-trust violation.
Things that are legal when you have a small market share can stop being legal when you have a very large market share.
Of course, Apple may simply be relying on that fact that it takes a *very* long time for the relevant Federal authorities to get their act into gear, and the current administration is ... "business friendly".
No, you're reading it with a conclusion in mind. Here is an example implementation of a Dictionary, in pseudocode:
class Dictionary {
class Pair {
KeyType key;
ValueType value;
};
array[Pair] contents;
};
I now intend to maintain Dictionary::Pair for my own usage — specifically, I'm going to use it to implement Dictionary — but not to support it for third parties. Third parties are supposed to use Dictionary.
Is that anticompetitive behaviour?
Great News, Users...
Actually, this is really great news, because now Slack have a great motivation to push ahead with their Catalyst build. That means it will have a differently weird UI, but at least it won't slug the machine.
And some m$ stuff won't work, years ago I would have said yippee, but nowadays it is more of a meh.
The Apple we know simply change and kill APIs without warning.
Almost every macOS update has flipped an API from "works fine, recommended" to "deprecated, and oh yeah, we also broke it", and radically changed API behaviours without warning.
USB has been a victim of this several times.
So getting away with rulebreaking is a valid argument that the rule shouldn't exist?
So that's alright, we'll let all the serial killers out of jail on that technicality then shall we? What were we thinking? If they'd managed two or three over a couple of years without sanction then surely they should just be allowed to continue?
This post has been deleted by its author
As per replies to the previous poster, Microsoft got in trouble for reserving functionality for itself that was exposed only via private APIs that allowed its office software to do a better job of OS integration than its competitors. The fact of private API was the mechanism but not the offence.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
