12 ms·

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 a

by adjunct 10y ago

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 of live patching, not just apps using Rollout. Rollout has always been compliant with Apple's guidelines as we've detailed in the past here: https://rollout.io/blog/updating-apps-without-app-store/ https://rollout.io/blog/updating-apps-without-app-store/ Our SDK is installed in hundreds of live apps and our customers have fixed thousands of live bugs in their apps. We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. I'll post updates as I have them. Erez Rusovsky CEO Rollout.io

aristidesfl 10y ago
https://rollout.io/blog/rollout-statement-on-apple-guidelines/ https://rollout.io/blog/rollout-statement-on-apple-guideline...
nickm12 10y ago
I think the part that you're running afoul of is where it says: "new apps presenting new questions may result in new rules at any time." Good luck to you, but it's Apple's sandbox and your product appears to thwart the principles that the Apple App Store has been run on for nearly a decade.
ma2rten 10y ago
You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.
- mahyarm 10y ago
  An objc swizzle is not native code injection, it's a function pointer swap. They swizzle the method to their general objc message handler which then executes a piece of javascript code. For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead. No binary code being injected.
  - wrasee 10y ago
    > No binary code being injected. A number of other posts talk explicitly of dynamic delivery of native code. If you're sure, it's a genuine question: I'm interested to know how this works. Function pointer swaps are one thing, but how would this allow you to patch bugs in the app? I can see how this could let you change the app's behaviour, even including calling private API's, but surely this would be constrained to calling pre-existing behaviour? Or by adding new behaviour is this to mean new javascript behaviour.
    - mahyarm 10y ago
      I think they are confused by the downloading of JavaScript files and executing that inside a 'native context'. I looked at how rollout did their stuff in detail a while back, so i can see how its easy to confuse the two.
  - burntrelish1273 10y ago
    Swizzling is incredibly useful. AFNetworking, MagicalRecord and GPGMail use it, just to name a few.
- artursapek 10y ago
  That sounds like a huge hack. They built a company around that?
  - vlunkr 10y ago
    Built a company with 3 million in funding https://www.crunchbase.com/organization/rollout-io-2#/entity https://www.crunchbase.com/organization/rollout-io-2#/entity.
    - artursapek 10y ago
      lol
ChuckMcM 10y ago
My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.
- malandrew 10y ago
  I'm wondering if one route to preventing this being an issue is to prevent any hot code fixes to specific devices. If you have to hot code push to all devices running a specific version, I reckon that would put a damper on the actions of an institution trying to target a specific person. It's a lot harder to try and be sneaky when a change has such a large impact. That said, I'm not sure this restriction alone would be enough.
- matthewbauer 10y ago
  An interesting theory but I kind of doubt the time between the release and this is enough for them to have identified these exploits.
  - ChuckMcM 10y ago
    I agree its a long shot. But perhaps they were on the fence about it and the CIA dump pushed them over the edge. Sadly there is no actual way to know for sure.
- pvg 10y ago
  They don't like you changing the stated functionality of the app. You're making it sound like an iPhone RCE automatically means jailbreak.
- bigiain 10y ago
  I suspect unless they got advance notice from Wikileaks this reaction is too soon. I'm wondering which of the current top-downloaded FlappyCrush Of Titans clone got caught exfiltrating all their players contact lists or something...
HappyTypist 10y ago
If only. You are using a technical hack to modify _native_ apps. The Apple Guidelines aren't strictly set in stone; the intent is clear: you can't remotely modify how native apps work, even if you do it through a JS delivery mechanism. Sorry for your loss, but in glad Apple is doing this and apps will be safer.
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 ago
  Completely. 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 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".
eeeeeeeeeeeee 10y ago
No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so you only have yourself to blame for this. Apple's rules can be harsh but I would rarely call them arbitrary. There is a very good security reason for Apple's stance here. And ultimately it's their store and their rules.
- deleted 10y ago
  [deleted]
- jonathanstrange 10y ago
  now we have to trust you to deliver that code safely to the user without being manipulated in transit. You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the Sandboxing features. For me personally, the red line is when unsigned executables can no longer run on MacOS. If Apple ever disallows unsigned executables, I will immediately discontinue my application on MacOS and redirect customers who rely on it to Apple's customer support.
  - rickycook 10y ago
    especially with relation to iOS you can't really say they're closing the platform further when at the most recent developer conference they opened a ton of APIs (siri, maps, imessage to name a few)
  - ballenf 10y ago
    MS is ahead of Apple in this race to security via taking back control from the end user. I'm with you in theory, but really doubt that on either platform there won't be at least a dev-only way of running arbitrary unsigned apps. Time will tell. I think it will really come down to the severity of malware problems of the future. But I really think we'll just move 100% into bifurcated systems (we're already there with Intel's ME to a large extent) where the place that arbitrary code can run is completely segmented off from trusted code.
richardwhiuk 10y ago
Your live patching allows you to call arbitrary native methods - this is even demonstrated in your video - of course this was going to get banned!
lloeki 10y ago
> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary through coercion or hacking and gets wiretapped by a malicious dynamic payload.
- Nexxxeh 10y ago
  Nothing guarantees that. There have been RCE exploits on iOS. One could argue that live patching allowed companies to fix or mitigate security problems faster than Apples (awful) app store policy (and timescale) would otherwise allow.
  - nothrabannosir 10y ago
    Nothing guarantees nothing. Life is ephemeral and we're all going to die. Yet, we can say that code review by a third party is better for trust of that code, than no code review by a third party. "Nothing guarantees" may have been strong. but "the set of attack vectors and their relative efficacy increases " doesn't roll off the tongue quite as nicely.
    - test1235 10y ago
      > we're all going to die That's guaranteed, at least ...
      - glenneroo 10y ago
        Unless "The Singularity" (and subsequent mind-uploading) actually pans out.
        misnome 10y ago
        That only delays the inevitable.
scarface74 10y ago
I'm not an iOS developer, but even I know enough about Apple's rules to know that they would frown on any code that has the ability to patch itself without going through app review unless it used the builtin Javascript engine and or was a web view. I can't imagine any iOS developer who knows the guidelines and how your product works wouldn't have been worried.
Brotkrumen 10y ago
"We are in full compliance. Everything is fine. The house is not on fire. The heat you are feeling is coincidential." Man, do I dislike marketing speak. A "We knew we were non-compliant, but think the security benefits of quick bugfixes outweigh the disadvantages. We will work with apple to return to compliance." would've been honest, better and not bs.
- Slartie 10y ago
  True, but in this case "return to compliance" means "scrapping the company", because its key product depends on the non-compliant behavior and is impossible to implement otherwise.
  - eddieroger 10y ago
    It more meant "don't build a company on shaky ground," which Rollout clearly did. The only reason to be so specific about not breaking the rules is when you know you are breaking the spirit of the rules. The blog post he linked to is a year old - they're lucky to have survived this long.
- digler999 10y ago
  > Man, do I dislike marketing speak Did you see the article on HN last weekend about Wifi routers? "I have a 1.3gbps wireless ac router...but only at the PHY layer, but only in an RF test lab, but only if the client is MU-MIMO enabled, but only if they talk on all 4 channels, but only if the signal connects at 100%, but only if your data is 10:1 compressible, but only if you have one client, " even after like 5 "but only if"'s , there was still this unexplained 20% discrepancy between the advertised "speed" and what the device was physically capable of. I'd love to hear their lawyer explain how thats not false advertising.
  - AstralStorm 10y ago
    Don't worry, they actually wrote "up to 1.3gbps" on the box. You just haven't read it closely enough.
- 10y ago
gattilorenz 10y ago
Sorry to be OT, but since you're the CEO I do hope you found out if Rollout supports swift as well :^) https://news.ycombinator.com/item?id=8158046 https://news.ycombinator.com/item?id=8158046
- kochthesecond 10y ago
  Hah, neat
- whatever_dude 10y ago
  Ouch. This post deserves more attention.
- tgragnato 10y ago
  bewildered ๏_๏
- brilliantcode 10y ago
  I'm confused. Did he forget to post that under another account or was he one of us, a lowly HN lurker that applied and go the CEO position (by self selection).
  - gattilorenz 10y ago
    Well, considering he's the co-founder and he's been working there for more than 3 years, and the comment was left less than three years ago... https://www.linkedin.com/in/erez-rusovsky-3a458850 https://www.linkedin.com/in/erez-rusovsky-3a458850
- rad_gruchalski 10y ago
  Yep, and this one: "Great stuff man, I wonder how many apps would suffer from problems when trying to access directly Amazon s3, also how many app updates would get pushed just to update plist" https://news.ycombinator.com/item?id=10151755 https://news.ycombinator.com/item?id=10151755
kminehart 10y ago
It sucks that the success of your business sounds dependent on the policies of the company in charge of the app store. Other than contacting Apple what can you do to combat this? That being said, I agree with most of the people here; live patching in my opinion is kind of infringing on the users' freedoms and security.
FXHAF8IfjB 10y ago
Making a business the wholly depends on the decisions of another business is not a business you want to be business of operating. Because situations like this arise and can immediately shut you down.
brilliantcode 10y ago
Builds a business around a 3rd party marketplace, get surprised when they cut you off without a warning. We've seen this over and over. The platform risk should be seriously considered. Even AWS has demonstrated recently how dependence can be catastrophic.
Hydraulix989 10y ago
I learned this lesson the hard way a long time ago when I built a service that uses ML (I was doing GPU powered ML in 2011) and social graph clustering to recommend "better" Facebook friends to invite in apps that use the FB SDK. They would send our API their users' FB access tokens (only required the default FB user permissions, too, for mutual friends), we'd issue calls to the FB SDK to get their social graph (completely on the issuing app's behalf), crunch it on our GPUs, and send back a sorted list of recommended friends to suggest to invite for improving virality. Back in 2012, it wasn't prohibited by the ToS at all; we read and re-read the ToS over and over again to make sure so that we wouldn't waste our time building something "illegal." Once I had the third largest social gaming company as a customer, Facebook's lawyers pulled the plug on it right away. Turns out (according to Archive.org Wayback Machine), they added a new clause to their ToS two days before emailing us about our ToS violation: "You must not give your secret key and access tokens to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers." Moral of the story: If they want to nuke you, they WILL nuke you (I'm sure Facebook wasn't too happy about my database storing millions of users' social graphs on it, and that was the REAL reason for the shutdown). Even during our YC interview, a couple of the most legit original partners told us on our way (permanently) out the door "yeah, you guys are going to get shut down..."

by adjunct 10y ago

aristidesfl 10y ago

https://rollout.io/blog/rollout-statement-on-apple-guidelines/ https://rollout.io/blog/rollout-statement-on-apple-guideline...

nickm12 10y ago

I think the part that you're running afoul of is where it says: "new apps presenting new questions may result in new rules at any time." Good luck to you, but it's Apple's sandbox and your product appears to thwart the principles that the Apple App Store has been run on for nearly a decade.

ma2rten 10y ago

You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.

mahyarm 10y ago
An objc swizzle is not native code injection, it's a function pointer swap. They swizzle the method to their general objc message handler which then executes a piece of javascript code. For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead. No binary code being injected.
- wrasee 10y ago
  > No binary code being injected. A number of other posts talk explicitly of dynamic delivery of native code. If you're sure, it's a genuine question: I'm interested to know how this works. Function pointer swaps are one thing, but how would this allow you to patch bugs in the app? I can see how this could let you change the app's behaviour, even including calling private API's, but surely this would be constrained to calling pre-existing behaviour? Or by adding new behaviour is this to mean new javascript behaviour.
  - mahyarm 10y ago
    I think they are confused by the downloading of JavaScript files and executing that inside a 'native context'. I looked at how rollout did their stuff in detail a while back, so i can see how its easy to confuse the two.
- burntrelish1273 10y ago
  Swizzling is incredibly useful. AFNetworking, MagicalRecord and GPGMail use it, just to name a few.
artursapek 10y ago
That sounds like a huge hack. They built a company around that?
- vlunkr 10y ago
  Built a company with 3 million in funding https://www.crunchbase.com/organization/rollout-io-2#/entity https://www.crunchbase.com/organization/rollout-io-2#/entity.
  - artursapek 10y ago
    lol

ChuckMcM 10y ago

My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.

malandrew 10y ago
I'm wondering if one route to preventing this being an issue is to prevent any hot code fixes to specific devices. If you have to hot code push to all devices running a specific version, I reckon that would put a damper on the actions of an institution trying to target a specific person. It's a lot harder to try and be sneaky when a change has such a large impact. That said, I'm not sure this restriction alone would be enough.
matthewbauer 10y ago
An interesting theory but I kind of doubt the time between the release and this is enough for them to have identified these exploits.
- ChuckMcM 10y ago
  I agree its a long shot. But perhaps they were on the fence about it and the CIA dump pushed them over the edge. Sadly there is no actual way to know for sure.
pvg 10y ago
They don't like you changing the stated functionality of the app. You're making it sound like an iPhone RCE automatically means jailbreak.
bigiain 10y ago
I suspect unless they got advance notice from Wikileaks this reaction is too soon. I'm wondering which of the current top-downloaded FlappyCrush Of Titans clone got caught exfiltrating all their players contact lists or something...

HappyTypist 10y ago

If only. You are using a technical hack to modify _native_ apps. The Apple Guidelines aren't strictly set in stone; the intent is clear: you can't remotely modify how native apps work, even if you do it through a JS delivery mechanism. Sorry for your loss, but in glad Apple is doing this and apps will be safer.

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 ago
Completely. 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 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".

eeeeeeeeeeeee 10y ago

No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so you only have yourself to blame for this. Apple's rules can be harsh but I would rarely call them arbitrary. There is a very good security reason for Apple's stance here. And ultimately it's their store and their rules.

deleted 10y ago
[deleted]
jonathanstrange 10y ago
now we have to trust you to deliver that code safely to the user without being manipulated in transit. You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the Sandboxing features. For me personally, the red line is when unsigned executables can no longer run on MacOS. If Apple ever disallows unsigned executables, I will immediately discontinue my application on MacOS and redirect customers who rely on it to Apple's customer support.
- rickycook 10y ago
  especially with relation to iOS you can't really say they're closing the platform further when at the most recent developer conference they opened a ton of APIs (siri, maps, imessage to name a few)
- ballenf 10y ago
  MS is ahead of Apple in this race to security via taking back control from the end user. I'm with you in theory, but really doubt that on either platform there won't be at least a dev-only way of running arbitrary unsigned apps. Time will tell. I think it will really come down to the severity of malware problems of the future. But I really think we'll just move 100% into bifurcated systems (we're already there with Intel's ME to a large extent) where the place that arbitrary code can run is completely segmented off from trusted code.

richardwhiuk 10y ago

Your live patching allows you to call arbitrary native methods - this is even demonstrated in your video - of course this was going to get banned!

lloeki 10y ago

> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary through coercion or hacking and gets wiretapped by a malicious dynamic payload.

Nexxxeh 10y ago
Nothing guarantees that. There have been RCE exploits on iOS. One could argue that live patching allowed companies to fix or mitigate security problems faster than Apples (awful) app store policy (and timescale) would otherwise allow.
- nothrabannosir 10y ago
  Nothing guarantees nothing. Life is ephemeral and we're all going to die. Yet, we can say that code review by a third party is better for trust of that code, than no code review by a third party. "Nothing guarantees" may have been strong. but "the set of attack vectors and their relative efficacy increases " doesn't roll off the tongue quite as nicely.
  - test1235 10y ago
    > we're all going to die That's guaranteed, at least ...
    - glenneroo 10y ago
      Unless "The Singularity" (and subsequent mind-uploading) actually pans out.
      - misnome 10y ago
        That only delays the inevitable.

scarface74 10y ago

I'm not an iOS developer, but even I know enough about Apple's rules to know that they would frown on any code that has the ability to patch itself without going through app review unless it used the builtin Javascript engine and or was a web view. I can't imagine any iOS developer who knows the guidelines and how your product works wouldn't have been worried.

Brotkrumen 10y ago

"We are in full compliance. Everything is fine. The house is not on fire. The heat you are feeling is coincidential." Man, do I dislike marketing speak. A "We knew we were non-compliant, but think the security benefits of quick bugfixes outweigh the disadvantages. We will work with apple to return to compliance." would've been honest, better and not bs.

Slartie 10y ago
True, but in this case "return to compliance" means "scrapping the company", because its key product depends on the non-compliant behavior and is impossible to implement otherwise.
- eddieroger 10y ago
  It more meant "don't build a company on shaky ground," which Rollout clearly did. The only reason to be so specific about not breaking the rules is when you know you are breaking the spirit of the rules. The blog post he linked to is a year old - they're lucky to have survived this long.
digler999 10y ago
> Man, do I dislike marketing speak Did you see the article on HN last weekend about Wifi routers? "I have a 1.3gbps wireless ac router...but only at the PHY layer, but only in an RF test lab, but only if the client is MU-MIMO enabled, but only if they talk on all 4 channels, but only if the signal connects at 100%, but only if your data is 10:1 compressible, but only if you have one client, " even after like 5 "but only if"'s , there was still this unexplained 20% discrepancy between the advertised "speed" and what the device was physically capable of. I'd love to hear their lawyer explain how thats not false advertising.
- AstralStorm 10y ago
  Don't worry, they actually wrote "up to 1.3gbps" on the box. You just haven't read it closely enough.
10y ago

gattilorenz 10y ago

Sorry to be OT, but since you're the CEO I do hope you found out if Rollout supports swift as well :^) https://news.ycombinator.com/item?id=8158046 https://news.ycombinator.com/item?id=8158046

kochthesecond 10y ago
Hah, neat
whatever_dude 10y ago
Ouch. This post deserves more attention.
tgragnato 10y ago
bewildered ๏_๏
brilliantcode 10y ago
I'm confused. Did he forget to post that under another account or was he one of us, a lowly HN lurker that applied and go the CEO position (by self selection).
- gattilorenz 10y ago
  Well, considering he's the co-founder and he's been working there for more than 3 years, and the comment was left less than three years ago... https://www.linkedin.com/in/erez-rusovsky-3a458850 https://www.linkedin.com/in/erez-rusovsky-3a458850
rad_gruchalski 10y ago
Yep, and this one: "Great stuff man, I wonder how many apps would suffer from problems when trying to access directly Amazon s3, also how many app updates would get pushed just to update plist" https://news.ycombinator.com/item?id=10151755 https://news.ycombinator.com/item?id=10151755

kminehart 10y ago

It sucks that the success of your business sounds dependent on the policies of the company in charge of the app store. Other than contacting Apple what can you do to combat this? That being said, I agree with most of the people here; live patching in my opinion is kind of infringing on the users' freedoms and security.

FXHAF8IfjB 10y ago

Making a business the wholly depends on the decisions of another business is not a business you want to be business of operating. Because situations like this arise and can immediately shut you down.

brilliantcode 10y ago

Builds a business around a 3rd party marketplace, get surprised when they cut you off without a warning. We've seen this over and over. The platform risk should be seriously considered. Even AWS has demonstrated recently how dependence can be catastrophic.

Hydraulix989 10y ago

I learned this lesson the hard way a long time ago when I built a service that uses ML (I was doing GPU powered ML in 2011) and social graph clustering to recommend "better" Facebook friends to invite in apps that use the FB SDK. They would send our API their users' FB access tokens (only required the default FB user permissions, too, for mutual friends), we'd issue calls to the FB SDK to get their social graph (completely on the issuing app's behalf), crunch it on our GPUs, and send back a sorted list of recommended friends to suggest to invite for improving virality. Back in 2012, it wasn't prohibited by the ToS at all; we read and re-read the ToS over and over again to make sure so that we wouldn't waste our time building something "illegal." Once I had the third largest social gaming company as a customer, Facebook's lawyers pulled the plug on it right away. Turns out (according to Archive.org Wayback Machine), they added a new clause to their ToS two days before emailing us about our ToS violation: "You must not give your secret key and access tokens to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers." Moral of the story: If they want to nuke you, they WILL nuke you (I'm sure Facebook wasn't too happy about my database storing millions of users' social graphs on it, and that was the REAL reason for the shutdown). Even during our YC interview, a couple of the most legit original partners told us on our way (permanently) out the door "yeah, you guys are going to get shut down..."