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

491–498 of 498 posts

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

#491

Post by wolfgke »

kazinator wrote: post #490
Spivak wrote: post #365

Earlier quoted context omitted.

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.

That characterization isn't enough to distinguish a Turing complete interpreter from something that trivially manipulates an input datum. An interpreter is just a program containing code paths, which are activated in response to the input (the interpreted code).

> That characterization isn't enough to distinguish a Turing complete interpreter from something that trivially manipulates an input datum. An interpreter is just a program containing code paths, which are activated in response to the input (the interpreted code).

It is surprisingly simple to make an interpreter that is "accidentally" Turing complete (this IMHO so often happens by accident that I love to say that if an interpreter is not "obviously" more restricted than a Turing machine, it probably is Turing complete).

This is not just my opinion - there lots of pages in the internet of things that are "accidentally" Turing complete, for example:

http://beza1e1.tuxen.de/articles/accidentally_turing_complet...

https://www.gwern.net/Turing-complete

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

#492

Post by John23832 »

giobox wrote: post #456
John23832 wrote: post #428

Earlier quoted context omitted.

In the United States, creation of law is the responsibility of the Legislative branch. There is no avenue for the Judicial branch to create law.

There's one unifying feature of all common law legal systems - judges will publicly almost always proclaim they do not create law, largely because simple prima facie interpretations of most western constitutions say "the legislature makes the laws, the court enforces them", and the existence of judge made law has always had an uneasy relationship with this. The reality in Common Law legal systems is nothing like this…

I'm not trying to be condescending, but you should probably include a US centric example when asserting how the US works. The Scottish example is irrelevant, as it applies to Scotland, not the US. Also, if you try to relate Scotland and the US under the umbrella of the term "Common Law", but then say that that term has it's own interpretive meaning, you've loosened the association to the point where you can't strictly say that the Scottish and US systems are the same...

Also, as I've seen in other comments, we're going to get on the merry-go-round of defining "create law".

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

#493

Post by John23832 »

stinkytaco wrote: post #460
John23832 wrote: post #451

Earlier quoted context omitted.

My original comment said that courts could interpret law... I'm not sure what you're getting at. Yes, including intention. US courts do it all the time. It's called the Constitution.

I guess I would look at this: > evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking) And argue that electronic privacy vis-a-vis wiretapping laws is creating a new portion of the law to cover previously created portions which are considered lacking. We can quibble about definitions, but that strikes me as very much in the area of "evo…

I think defining "evolution" and "create" are the real sticking points in this argument. That get's down to splitting hairs. Though I will say that I do believe that everyone in this thread does have sound arguments given their definition of those two words.

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

#494

Post by st3v3r »

zodiac wrote: post #472
st3v3r wrote: post #390

Earlier quoted context omitted.

"What is "code"?" Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.

So what is Apple's decision about what code is?

When it comes to what's run on their platform, yes.

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

#495

Post by iOSGuy »

mikeash wrote: post #299
Jonnax wrote: post #293

Earlier quoted context omitted.

Because a private API could give out details about you that you don't want shared to a random application or 3rd party advertising/analytics platform. For example serial numbers, user ids, lists of installed applications, etc.

If a private API is a privacy or security concern then the sandbox needs to block it. Apple blocks private APIs because they don't want to maintain their compatibility across OS releases and don't want third party apps to break when those APIs change. Edit: I'm starting to suspect that people don't know what "private API" means, so I want to lay it out real quick. Apple ships a bunch of dynamic libraries with the OS…

Mike, this line is completely and 100% inaccurate:

"Private APIs do nothing that a third-party developer couldn't do in their own code, if they knew how to write it."

There are a million things under the sun that private APIs have access to that wouldn't be possible with the use of public APIs alone, good developer or not. Prime example: "UIGetScreenImage()". That function allows you to take a screenshot of the device's entire screen, your app, someone else's app, the home screen of iOS. That's a pretty big security hole, is it not?

There are countless examples just like that one hidden inside the private API bubble. Things the OS needs to function, (although the OS may not need that particular example anymore) but could cause massive security issues.

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

#496

Post by euyyn »

Dylan16807 wrote: post #439
euyyn wrote: post #392

Earlier quoted context omitted.

They "own" a compiler, but not all of them. Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents…

> Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job. Put privileged code into a…

I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage.

And well, in any case they need to maintain compatibility with current apps for who knows how many years.

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

#498

Post by Dylan16807 »

euyyn wrote: post #496
Dylan16807 wrote: post #439

Earlier quoted context omitted.

> Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region. Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job. Put privileged code into a…

I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage. And well, in any case they need to maintain compatibility with current apps for who knows how many years.

> I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage.

Such a scheme wouldn't stop ASLR. The loader just needs to tell the verification code where it put the privileged libraries.

> And well, in any case they need to maintain compatibility with current apps for who knows how many years.

Do they? I think Apple could easily order everyone to switch over to a more secure compiler with a one year deadline.

Post reply on HN