1. 6

  2. 3

    I don’t know Heroku at all, so these may not actually be a problem. Some easy to identify potential issues:

    • if you host it yourself (not using Heroku), you must always keep the service up for as long as the application lives (i.e. is available through the App Store) to avoid new/reinstalling app users from experiencing crashes;
    • It assume Heroku sends a 404 if your application is not available (anymore), not sure if this will always be the case, but maybe this is documented;
    • The app will keeping making the requests every time when a 404 is returned to retry?
    • What if someone (over time) takes over your exact URL and starts sending other HTTP responses?
    • Heroku costs money, it adds up to quite a bill over time;

    It seems quite risky to implement this kind of “backdoor”, even if you take care, makes me wonder if this whole thing was a joke to begin with?

    1. 1

      Well the expectation is that any application using this would do so on a temporary basis. The linked Quora answer deals with a situation of the author making a mobile app on contract and not getting paid. Once the kill switch was thrown, they got paid, and delivered the source code, minus the kill switch. In that scenario, this is totally worthwhile.

      To use it long term for your own personal app, that would be another situation entirely. Which would probably mean that you’d need to host the responding web server yourself. Though, since it’s just HTTP codes, it’s very simple to configure any HTTP-speaking server.

      1. 1

        Heroku’s lowest tier is free. That ought to be good enough for the size of deployment this seems to be meant for, and considering that it just sends back status codes.

      2. 2

        The scope for misuse here is huge, I’m not sure I’d really want an app with such a killswitch inside