14 ms·
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
by macspoofing 10y ago
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 the letter of a EULA of a tightly controlled ecosystem run by a very capricious company.
I hate the app store review process and a lot of apple policies around the app store and I feel for you and I totally think there should be a less onerous update/review process ... but ... you clearly and blatantly circumvented a core policy, and what happened to you was absolutely predictable.
Get your money back from the lawyer that told you Apple wouldn't shut you down. You got bad advice.
- richie5um 10y agoCompletely. Disappointed is fine, but surprised. Given this seems explicitly designed to avoid the need for AppStore reviews, this was inevitable. I don't want anyone pushing code updates to the apps that have been reviewed. Whilst that isn't foolproof, compromising the deployment mechanism with this approach is very scary.
- 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 agoThey 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 agoYou are thinking "source code". "Code" is another term for what you are referring to as "binary".
- DaiPlusPlus 10y agoRecently 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 agoCan 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 agoIn 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
- andyjohnson0 10y agoThey 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 agoUnless you are Facebook or Google. Then it's fine and you get a free pass.
- threeseed 10y agoTo 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 agoIt'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 agoDo you have examples more recent than 2008?
- sametmax 10y agoThose 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 agoWhat 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 agoWhich 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 agoThat 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 agoSo 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 agoWeb 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.
- libertymcateer 10y ago> 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 Antonin Scalia said that the service had nevertheless identified a loophole in the law. “It is not the role of this court to identify and plug loopholes,” he wrote. “It is the role of good lawyers to identify and exploit them, and the role of Congress to eliminate them if it wishes.” https://www.nytimes.com/2014/06/26/business/media/supreme-court-rules-against-aereo-in-broadcasters-challenge.html https://www.nytimes.com/2014/06/26/business/media/supreme-co...
- stinkytaco 10y agoThis 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.
- John23832 10y agoTo some extent I agree with you, but at the same time it is not the purpose of the court to create law. It is their job to interpret. Lawyers read and understand. Evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking), is the responsibility of the legislative branch (in that case, Congress).
- stinkytaco 10y agoBut the common law is evolving. That's why we review previous cases and cite precedent. Because we assume the interpretation of the law will change as soon as it comes into contact with facts. There is a point where Congress needs to get involved, but until they choose to do so, the court system is where the law happens. Sometimes that includes evolution, but I suppose it's up to the appeals system to draw that line.
- digerata 10y agoYeah, 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/ https://rollout.io/blog/updating-apps-without-app-store/
- skwirl 10y agoMy impression of the Aereo decision was that it was based on the letter of the law. Contrary to opinions often expressed here, the law wording does not specifically apply to cable companies and specific wording was not creatively interpreted to apply to Aereo. The wording of the law referred not to antennas and cables but to a more abstract notion of "public performances" of copyrighted works, and Aereo fell squarely into what Congress (and legal precedent) meant by public performances of copyrighted works. The law was actually fairly well written to cover evolving technology.
- Dylan16807 10y agoExcept that it's been established that 'cloud DVR' is legal. That's 90% of what Aereo did. But somehow attaching an individual antenna to each person's DVR makes it 'public performance'? That specific argument is nonsensical. And then they got double screwed because the US copyright office declared that no matter what the supreme court said they were not a cable company and couldn't get compulsory licensing either. As far as I can tell it's legal to run one antenna for one person, and I have absolutely no idea where the line is that you start violating copyright. I don't think the guidelines are well written.