10 ms·

> 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 obvi

by abcd_f 10y ago

> 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.

mahyarm 10y ago
They don't 'see' the code. They run a program on the binary for some obvious checks and do a QA smoke test of the app itself.
- huhtenberg 10y ago
  You are thinking "source code". "Code" is another term for what you are referring to as "binary".
  - DaiPlusPlus 10y ago
    Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of possibility that an unscrupulous Apple team is disassembling cool apps to see how they work then re-implement them for the next release of iOS.
    - averagewall 10y ago
      Can you identify a type of app for which reverse engineering it would be easier than writing their own? Software is usually easier to write than to read. If an app has such a magic secret sauce, and it's of value, then it should be protected by patent or copyright anyway. An example that comes to mind is a high speed image compression app for taking rapid sequences of photos. Apple bought the company or the rights so they could include it themselves.
      - beobab 10y ago
        In my experience, it's always been easier for me to implement something once I've seen a working example of it. That's basically what examples are for: A "cheat sheet" for reverse engineers. Software is only easier to write than read if you have an idea what it's supposed to do. If you've ever googled "how do I do X?", then you likely have reverse engineered the answer you found to fit your particular use case. In addition, and in some countries, you can't patent software (thankfully), and so innovation comes through reverse engineering naturally.
        philwelch 10y ago
        And how many of those working code examples came from decompiled code?
    - emdowling 10y ago
      I really don't think Apple, with it's war chest, is actively disassembling code to steal it. As has been demonstrated time and time again, they will just buy companies that have awesome tech and IP. Far easier.
      - htk 10y ago
        Or they can just "sherlock" them. Happened several times.
    - st3v3r 10y ago
      No. Apple has plenty of experience doing that themselves, without that. There's a reason the term "Sherlocking" exists.
- andyjohnson0 10y ago
  They also run a static analysis on the binary to check for, amongst other things, use of private APIs. It is presumably fairly easy for them to detect the presence of third-party SDKs like rollout.io from their binary signature.
sametmax 10y ago
Unless you are Facebook or Google. Then it's fine and you get a free pass.
- threeseed 10y ago
  To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.
  - sametmax 10y ago
    It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs (http://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html http://sourcedna.com/blog/20151018/ios-apps-using-private-ap...) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mobile_uses_private_iphone_apis https://daringfireball.net/2008/11/google_mobile_uses_privat... Yet they are not rejected, because they are "big enough".
    - jamespo 10y ago
      Do you have examples more recent than 2008?
      - sametmax 10y ago
        Those are not easy to find, it's not really something they advertise and you need somebody to publicly catch them. The only reason I know they do is because some of my friends working on mobile video games regularly complain they can't get some features because they are private while google and facebook do. They analyzed some apps to try to copy said features and realized the unfairness of their situation. Those are lunch chit chats, not hard facts. But they got seldom reasons to lie.
wolfgke 10y ago
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-controlled) server if one does not want to get into a self-contradiction.
- Spivak 10y ago
  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.
  - kazinator 10y ago
    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).
    - wolfgke 10y ago
      > 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_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... https://www.gwern.net/Turing-complete https://www.gwern.net/Turing-complete
  - 10y ago
elldoubleyew 10y ago
So if I have an imbeded webpage inside of my app and that website is updated do I suddenly violate the EULA. What if its a social media app that provides users the ability to write custom HTML/CSS/JS to personalize their profiles and a user writes a game that runs in the header of that profile. What if that game suddenly allows the ability to access copyrighted material? I just don't understand how Apple is supposed to draw a line here.
- deleted 10y ago
  [deleted]
- prh8 10y ago
  Web apps are fine, I believe the issue is Apple wants to prevent apps from updating their Objective-C code. Anything run by WebKit is fine. From the Rollout page linked above: > With Rollout’s SDK you can update and modify your Objective-C methods with logic written in JavaScript so we’re good on the first condition. I think that is the problem with Rollout.

by abcd_f 10y ago

> 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.

mahyarm 10y ago

They don't 'see' the code. They run a program on the binary for some obvious checks and do a QA smoke test of the app itself.

huhtenberg 10y ago
You are thinking "source code". "Code" is another term for what you are referring to as "binary".
- DaiPlusPlus 10y ago
  Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of possibility that an unscrupulous Apple team is disassembling cool apps to see how they work then re-implement them for the next release of iOS.
  - averagewall 10y ago
    Can you identify a type of app for which reverse engineering it would be easier than writing their own? Software is usually easier to write than to read. If an app has such a magic secret sauce, and it's of value, then it should be protected by patent or copyright anyway. An example that comes to mind is a high speed image compression app for taking rapid sequences of photos. Apple bought the company or the rights so they could include it themselves.
    - beobab 10y ago
      In my experience, it's always been easier for me to implement something once I've seen a working example of it. That's basically what examples are for: A "cheat sheet" for reverse engineers. Software is only easier to write than read if you have an idea what it's supposed to do. If you've ever googled "how do I do X?", then you likely have reverse engineered the answer you found to fit your particular use case. In addition, and in some countries, you can't patent software (thankfully), and so innovation comes through reverse engineering naturally.
      - philwelch 10y ago
        And how many of those working code examples came from decompiled code?
  - emdowling 10y ago
    I really don't think Apple, with it's war chest, is actively disassembling code to steal it. As has been demonstrated time and time again, they will just buy companies that have awesome tech and IP. Far easier.
    - htk 10y ago
      Or they can just "sherlock" them. Happened several times.
  - st3v3r 10y ago
    No. Apple has plenty of experience doing that themselves, without that. There's a reason the term "Sherlocking" exists.
andyjohnson0 10y ago
They also run a static analysis on the binary to check for, amongst other things, use of private APIs. It is presumably fairly easy for them to detect the presence of third-party SDKs like rollout.io from their binary signature.

sametmax 10y ago

Unless you are Facebook or Google. Then it's fine and you get a free pass.

threeseed 10y ago
To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.
- sametmax 10y ago
  It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs (http://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html http://sourcedna.com/blog/20151018/ios-apps-using-private-ap...) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mobile_uses_private_iphone_apis https://daringfireball.net/2008/11/google_mobile_uses_privat... Yet they are not rejected, because they are "big enough".
  - jamespo 10y ago
    Do you have examples more recent than 2008?
    - sametmax 10y ago
      Those are not easy to find, it's not really something they advertise and you need somebody to publicly catch them. The only reason I know they do is because some of my friends working on mobile video games regularly complain they can't get some features because they are private while google and facebook do. They analyzed some apps to try to copy said features and realized the unfairness of their situation. Those are lunch chit chats, not hard facts. But they got seldom reasons to lie.

wolfgke 10y ago

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-controlled) server if one does not want to get into a self-contradiction.

Spivak 10y ago
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.
- kazinator 10y ago
  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).
  - wolfgke 10y ago
    > 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_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... https://www.gwern.net/Turing-complete https://www.gwern.net/Turing-complete
- 10y ago

elldoubleyew 10y ago

So if I have an imbeded webpage inside of my app and that website is updated do I suddenly violate the EULA. What if its a social media app that provides users the ability to write custom HTML/CSS/JS to personalize their profiles and a user writes a game that runs in the header of that profile. What if that game suddenly allows the ability to access copyrighted material? I just don't understand how Apple is supposed to draw a line here.

deleted 10y ago
[deleted]
prh8 10y ago
Web apps are fine, I believe the issue is Apple wants to prevent apps from updating their Objective-C code. Anything run by WebKit is fine. From the Rollout page linked above: > With Rollout’s SDK you can update and modify your Objective-C methods with logic written in JavaScript so we’re good on the first condition. I think that is the problem with Rollout.