Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

Post reply on HN
Print view View original

361–370 of 498 posts

Re: Apple starts rejecting apps with “hot code push” features

#361

Post by rayvd »

stinkytaco wrote: post #312
libertymcateer wrote: post #308

Earlier quoted context omitted.

> You blog sounds like the PR spin that came out of Aereo, a company that spent an inordinate amount of effort to stay within the absolute letter of a law. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

Um, no. Please no. That's a terrifying thought.

Re: Apple starts rejecting apps with “hot code push” features

#362

Post by AdmiralAsshat »

JulianMorrison wrote: post #328
AdmiralAsshat wrote: post #315

Earlier quoted context omitted.

f.lux strikes me as a good example. f.lux came to the market first with its idea to control screen temperature. Apple decides "No, you're not allowed to do that...but that's a great idea!", kicks f.lux out of the app store, and then adds their own Night Mode into later versions of iOS, using API's only they are allowed to access.

I'm guessing, from Apple's perspective, things that overlay the whole screen and alter the appearance of other people's apps (such as applying a colour cast), are essentially "white hat phishing". It makes security sense to hide this capability in the OS and not in apps.

You can see, I trust, how this could lead down a monopolistic slippery slope. For instance, virus-scanning is a dangerous enterprise, given that it exposes a greater attack surface if the antivirus program is poorly written. Should Apple and Microsoft remove the ability for third-party antivirus apps to exist? How about third-party firewalls?

Re: Apple starts rejecting apps with “hot code push” features

#363

Post by 794CD01 »

tdhz77 wrote: post #348
unethical_ban wrote: post #325

Earlier quoted context omitted.

Then the letter of the law means nothing.

The law is a living breathing organic document. Anybody who says otherwise is living in 1776 with slaves.

Bad example. Slavery was made illegal the proper way, by changing the letter of the law. See the 13th amendment.

Re: Apple starts rejecting apps with “hot code push” features

#364

Post by sdenton4 »

ballenf wrote: post #336
AdmiralAsshat wrote: post #315

Earlier quoted context omitted.

f.lux strikes me as a good example. f.lux came to the market first with its idea to control screen temperature. Apple decides "No, you're not allowed to do that...but that's a great idea!", kicks f.lux out of the app store, and then adds their own Night Mode into later versions of iOS, using API's only they are allowed to access.

I love f.lux and have a soft spot for the very nice developer couple behind the app. That being said, it's hard to argue that Apple (or Android) shouldn't be able to set boundaries on behaviors which are only allowed to be done by the OS as a opposed to an app. Apple's tight control of device screen characteristics makes it pretty understandable that they don't want one app able to control how another app looks on th…

The delicate balance between throwing a user a rope, and throwing them enough rope to hang themselves...

Re: Apple starts rejecting apps with “hot code push” features

#365

Post by Spivak »

wolfgke wrote: post #269
abcd_f wrote: post #151

Earlier quoted context omitted.

> Oh man. You were surprised? Really? Exactly! Apple has always been adamant that they see _all_ code that goes onto devices. Live patching is so bloody obvious against their EULA.

What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-co…

Which is why you're not allowed to use a Lisp interpreter or use any method of evaluating data as code. In this model the only thing that data can do is change which code paths run, not what they do.

Re: Apple starts rejecting apps with “hot code push” features

#366

Post by JulianMorrison »

AdmiralAsshat wrote: post #362
JulianMorrison wrote: post #328

Earlier quoted context omitted.

I'm guessing, from Apple's perspective, things that overlay the whole screen and alter the appearance of other people's apps (such as applying a colour cast), are essentially "white hat phishing". It makes security sense to hide this capability in the OS and not in apps.

You can see, I trust, how this could lead down a monopolistic slippery slope. For instance, virus-scanning is a dangerous enterprise, given that it exposes a greater attack surface if the antivirus program is poorly written. Should Apple and Microsoft remove the ability for third-party antivirus apps to exist? How about third-party firewalls?

I don't see that, actually, I think that's a false equivalence.

Security premise: when you are looking at Facebook, you are looking at Facebook. You are not looking at a third party app drawing over Facebook and pretending to be Facebook.

I do not see the above as a slippery slope. Phishing is a capability apps should not have. Even if they have the best of intentions.

Re: Apple starts rejecting apps with “hot code push” features

#367

Post by mgamache »

recursive wrote: post #50
cynix wrote: post #22

Earlier quoted context omitted.

> Rollout lets you push code-level changes to native iOS apps, without waiting on the App Store. What did they expect when their entire business model is based on something that's literally the opposite of what the review guideline allows?

Uber is still doing kind of ok.

Uber may be good at skirting local laws, but as a company it's a ticking bomb.

Re: Apple starts rejecting apps with “hot code push” features

#368

Post by digerata »

macspoofing wrote: post #144
adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

Oh man. You were surprised? Really? You blog sounds like the PR spin that came out of Aereo, a company that spent an inordinate amount of effort to stay within the absolute letter of a law. Predictably they got killed by lawsuits because judges aren't idiots and the law isn't inflexible to the point where the intent and context isn't considered. Your case is even worse because you engineered a solution to adhere to t…

Yeah, this seems crazy that anyone would build a business on this.

For those curious about their justification:

https://rollout.io/blog/updating-apps-without-app-store/

Re: Apple starts rejecting apps with “hot code push” features

#370

Post by a_t48 »

menckenjr wrote: post #303
woah wrote: post #277

Earlier quoted context omitted.

Huh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?

Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but... http://www.wikihow.com/Bypass-iPhone-Passcode

At that point your phone is fucked, anyhow. If you've lost physical control of the device and an attacker has broken the lock, you're compromised in much bigger ways.
Post reply on HN