Hacker News Reader

Comment by freehunter | Hacker News Reader

Because Electron developers might say "we fixed it" and the app developer might resubmit based on that and now they're banned due to a mistake made by an upstream dependency.

It's not like this app developer is intentionally using private APIs. "Resubmitting the same thing and hoping that it doesn't get caught" seems to be a strawman.

View on HN

That resubmit approach ways used by at least one camera app years ago who masked their private API usage to secretly include a volume button “take photo” feature. They were told to knock it off (and Apple also added that option to the API at a later date).

Between that and the folks who hid MAME in an app or whatever, I think Apple is not simply constructing straw men when they warn that attempts to circumvent the spirit of their request - and the letter of it - will result in a lifetime ban.

Camera+ didn't use a hidden API - they just used a standard system volume control but placed it offscreen and monitored if the volume changed (and then lower it imperceptibly if you hit 100%). And Apple has still not added an API to do this officially, last I checked all third party camera apps use a similar hack.

What changed was just the interpretation of the app store rules - the rules said something like "you're not allowed to use hardware buttons in a non-standard way". Once they added the volume shutter feature to the system camera, now it's not a non-standard way and it's not against the rules.

Hence why you should audit your third-party dependencies in cases like these.

I suspect that most devs don't do that. I can't imagine finding the time fir that.

Who do you imagine is responsible for making sure your app doesn’t contain malware?

The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.

you simply notarized the app and you know that there is no malware. Also we are talking about ElectronJS and Chromium -- not exactly untreatable sources. Note that apple does check for malware and quality on the upload stage itself (now done via transporter) so it wouldn't even make it to then review state if something is dodgy.

Apple can’t magically tell that there’s no malware in an app you upload. There is no automated scan which can detect all security vulnerabilities or back doors in code. And we’re talking about electron plus hundreds to thousands of npm modules - which contain who knows what.

If you pull in some bad modules, directly or transitively, and as a result your app steals my data or worse, that’s on you for shipping malicious code to my computer. There is no one else who can be responsible for that. Not Apple. Not the user. You.

I've done that over my entire career. It's always been a requirement. To say you can't find time for it is the same as saying that you can't find time to complete development.

How exactly?

I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.

what if the function calls are generated with macros or something?

grep the generated binary.

Isn't it literally the responsibility of the developer to figure it out, instead of just ignoring it because it's potentially hard?

it would but it wouldn't solve the problem. This would require the developer to modify electron and basically run his own branch. It would then make your package possibly acceptable (but attention here: as Apple clearly stated keeping too use private APIs can get you banned so if you miss something you can lose your access to the apple store) leaving however everyone else using electron with the same problem. So the solution has to come from Electron.

> So the solution has to come from Electron.

And until it does, developers should not use Electron.

There's a number of reasons why I refuse to use Electon-based apps, and this is one of them.

Reply on news.ycombinator.com