top | item 6083812

Ask HN: Take down my reverse-engineered Snapchat lib because they asked?

194 points| tlack | 12 years ago | reply

A few months ago, I spent a couple days reverse engineering the Snapchat protocol and wrote a quick and dirty library to use it in your own PHP apps:

https://github.com/tlack/snaphax

Today Snapchat has written me requesting that I take it offline:

    Hi Thomas,
    I'm writing to ask that you remove Snaphax from github
    and no longer publish or distribute it. Snapchat does
    not permit third party software to access our API and
    we consider Snaphax to be an unlawful circumvention 
    device under 17 U.S.C. § 1201(a)(1).

    Please confirm that it has been removed by end of day
    Monday, July 22nd.

    Thank you,

    Micah Schaffer
    Snapchat, Inc.
I haven't had much time to really finish Snaphax (and I doubt I ever will) but I strongly support the idea that third party software should be able to interact with the services I use every day.

I am under the impression that reverse engineering is still protected under fair use doctrines. Is this the case? How should I respond, if at all?

133 comments

order
[+] peterkelly|12 years ago|reply
One important distinction that I see missed here is that of an API vs. a service.

Snapchat provide a service, which I mentioned in another comment here that they have every right to enforce terms of service on, and restrict or allow usage as they see fit.

Snapchat also provide an API (which, in this scenario can also be considered a network protocol). This API can be used to access this service.

Now that I've had a look at the code, I've noticed that it includes the API keys which grant programs using this library the appropriate access permissions for the service. I think this is wrong, and that these keys should not be included in an open source library. The rest of the code however, is fine, as it simply implements a protocol.

If I were to develop something like this, I would leave out the API keys and have the user of the library fill them in. In principle, and as someone else has mentioned here, it would be possible to develop and operate your own service which uses this protocol/API. And I see nothing wrong with that.

Well, except of course that the whole notion of an app which presents information for a set period of time after which the user can no longer view it is inherently flawed, since eventually someone's going to figure out how to not erase/hide the information.

[+] peterkelly|12 years ago|reply
I've just forked it on Github, as have 25 others (as I write this).

As with file formats, the notion that network protocols & APIs should ever be granted any type of protection and that no-one other than the creators should be able to write software that conforms to these protocols is ridiculous.

Snapchat, in my view, have every right to restrict who uses their service and in what manner - via standard mechanisms like API keys and login credentials. But preventing third-party implementations of protocols or APIs is so 90s. Oracle had a bit of trouble with this recently.

One problem I'm personally trying to remedy is the proliferation of various APIs and protocols for accessing various online storage services (Dropbox, Google Drive, Box etc) by developing an SDK that supports all of them. We need more of this kind of these kinds of projects, not less.

Micah Schaffer, if you're reading this, you're welcome to send me a takedown request and discuss the issue with me. My email address is in my profile.

EDIT: It's at 62 now. I wouldn't be surprised if even Barbra Streisand has forked it.

[+] peterkelly|12 years ago|reply
I've actually amended my fork now to remove the API keys, adding the following instructions:

  /* Instructions for usage:
     1. Replace YOUR_SECRET_KEY and YOUR_STATIC_TOKEN in the code below with
        the values you have to access the service.
     2. Fill in SERVICE_URL with the appropriate endpoint. */
Not that it's going to stop anyone from going to any of the other forks or retrieving the previous revision of the file, but at least I've now only got up what I believe to be genuinely acceptable.
[+] ultimoo|12 years ago|reply
"But preventing third-party implementations of protocols or APIs is so 90s."

I think the impending 3Taps (padmapper.com) v/s Craigslist case[1] will shed more light on this. padmapper were using Craigslist data that is 'freely available' and Craigslist didn't like it.

[1] http://www.dmlp.org/threats/craigslist-v-3taps

[+] bas|12 years ago|reply
forked. 80+
[+] untog|12 years ago|reply
Ignore 99% of the responses in this thread, particularly any that say "I think...", "It seems fair...", and so on. You're in a legal situation here, if you are worried, contact a lawyer.
[+] guelo|12 years ago|reply
Bunk. He spent 2 days on a hobby project with no hopes of ever making any money off of it. It makes no sense to spend time and money consulting a lawyer over this.
[+] jessaustin|12 years ago|reply
I'm writing to ask... we consider....

Assuming the posted letter is complete, a lawyer can't really do anything at this point. The letter (or is it actually an email?) doesn't invoke any requirements one is bound by law to obey. One might even say that it's careful not to do so, so I suspect that even though the "Director of Operations" signed it, it was originally written by a lawyer. This would actually be a useful form letter for people who have their underpants on a bit too tight: even if they send it five times a month, it doesn't create any sort of SLAPP liability or anything else that will damage Snapchat in a legal sense. Of course, giving someone 12 hours to comply with anything looks like amateur hour. tlack isn't the only party reluctant to run up billable hours.

IANAL. If I were, I would recommend you start paying me or one of my colleagues to talk with you immediately.

[+] simias|12 years ago|reply
I think he's asking for moral, not legal advice.
[+] tehwebguy|12 years ago|reply
Agreed, talk to an attorney.
[+] DannyBee|12 years ago|reply
Can't give you legal advice, since you aren't my client and i can't ethically represent you.

In general, though, not taking it down will be a tough path for you.

If you really want to go down that path, get a lawyer (i'm happy to make recommendations for you), say nothing else here (or anywhere) about your motivations/goals/whatever, and go that way.

If you don't want to spend the time or the money, take it down .

[+] cjbprime|12 years ago|reply
There's no "fair use" defense because they aren't asserting a plain copyright violation -- they're asserting that using their API is a DMCA violation. I'm not a lawyer, but this seems laugh-out-loud crazy of them, and I'm not aware of anyone trying that claim before.

So if you want to resist, you could start there: by finding out (possibly by asking a lawyer to talk to them) how they think your tool is acting to "descramble a scrambled work, decrypt an encrypted work, (or equivalent actions)". If you want to do this, you might consider reaching out to the EFF for help.

Morally, I think you're in the clear for the reason you already gave.

[+] laumars|12 years ago|reply
If you're using their API (which they host) without consent then you may well find yourself on the wrong side of computer misuse acts.

So this is definitely one of those occasions that legal advice is required, not moral advice.

[+] tptacek|12 years ago|reply
I would take it down, not because of ethics or legalisms, but because you'll lose technically. They're making it clear that they don't want interoperable implementations. All you're doing is poking them in the eye with a stick. You probably don't have the resources (especially given your lack of interest) to keep your implementation working; they certainly have the resources to break your implementation. Why bother?
[+] evv|12 years ago|reply
Snapchat probably does not want to break all of their deployed-and-delivered apps.

If they shipped the app/service without a "force the user to update" feature, they would risk leaving thousands of users in the dark.

And if they did modify their protocol, it would probably get reverse-engineered again, either by the OP or somebody else.

[+] late2part|12 years ago|reply
A lot of times when you use a product, you're required to agree to an EULA wherein you promise/commit to not reverse engineer a product or its protocols. If you did use snapchat as a registered user, this issue could affect you negatively.

Another alternative is to mail them back and ask them for clarification. Why do they consider it an infringement?

The law clearly states the following:

  (2) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that—
  (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title;
  (B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or
  (C) is marketed by that person or another acting in concert with that person with that person’s knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title.
The way I interpret this is that if one is overcoming some encryption or authentication scheme, it may be disallowed under the law. If one is simply observing a protocol online, then one may be doing something bad as this says.
[+] PeterisP|12 years ago|reply
It depends on your location - in sane jurisdictions, EULAs aren't worth the paper they're not written on. But it looks like that USA is not one of them.

At least for me any EULAs that aren't signed before purchase (i.e., all shrinkwrap or clickthrough "agreements") aren't binding unless I choose to - B2B sales with explicit signed contracts would be binding; or if I want to do something that by law requires permission (i.e., redistribution instead of just using the software) then I might accept an 'EULA' such as GPL.

[+] nathanb|12 years ago|reply
Yeah, isn't that one of the things that ended up getting geohot in trouble with the PS3? They found an account where he had agreed to the TOS, thus putting him in violation of the same?
[+] milesokeefe|12 years ago|reply
A few weeks ago I was halfway through the process of reverse engineering the Snapchat API myself, when I found your library. I just wanted to say thanks for saving me so much trouble.
[+] dragonwriter|12 years ago|reply
> I am under the impression that reverse engineering is still protected under fair use doctrines. Is this the case?

Not insofar as the reverse engineering is used to produce an anti-circumvention device under the DMCA (that is, the reverse engineering itself is still just as protected as it used to be, but that protection does not extend to making the anti-circumvention device available.)

Note that there is still the issue of whether what you've actually is an anti-circumvention device.

> How should I respond, if at all?

If the project is worth the cost of consulting a lawyer, you very likely should do that so you understand better what your exposure here is and can make a more informed decision than you would be able to make based on lay advice you might get from HN. If its not, you should probably take it down.

[+] simonster|12 years ago|reply
At this point, I would just remove it. Since this is on the front page of HN, there's no way Snapchat can make the code disappear anyway.

If you need legal advice, I recommend seeing if SFLC (http://www.softwarefreedom.org/) will help you. In the past, I worked on a free software project where we willfully ignored a cease and desist notice and got sued by a large multinational corporation, and they were awesome.

[+] jwcrux|12 years ago|reply
Like many others have said, it would be best to consult an attorney if you're concerned.

However, while you may not be able to distribute software which uses the API, I think many people would enjoy/benefit from a post describing how you reversed it and what steps you took to create the library.

[+] ams6110|12 years ago|reply
"Written" as in sent you a registered letter? Or was this an email?

I don't know anything about the Snapchat API but if it's simply undocumented I don't see how that would be a "technological measure" of "effective control."

If you had to sniff or crack an API key of some sort, maybe that does.

In any event, it seems like a friendly enough request, maybe take it down as a courtesy pending their clarifying exactly what "technological measure" of "effective control" they think it "circumvents." Depending on their response and how much you think you want to push it, you can then decide what to do.

[+] stevekemp|12 years ago|reply
I'd consider it good-faith reverse engineering for the purposes of interoperability.

I'd ignore it. If they want to go hard-ball they'll threaten to sue/actually sue. Until then keep silent.

[+] kposehn|12 years ago|reply
Morally, I would take it down.

It is all well and good to write these sorts of things as a demo, but distribution is something where I would defer to the actual owner of the API in question.

After all, how many of us would want someone creating an unauthorized library to a private API that we don't wish to have public?

[+] icebraining|12 years ago|reply
Personally, I think the idea of purposely trying to maintain private an API designed to be used by code running on others' computers to be morally dubious.

I would agree with your position if this was some internal service of theirs.

[+] mattmaroon|12 years ago|reply
Here's what I'd do if I were you.

First, I'd ask myself how much I care about this. Do I care enough to pay legal fees to defend myself if Snapchat decides to come after me? If yes, consult an attorney and find out what you're looking at. Ignore any legal advice you get here. Unless it's from an actual attorney on your payroll (and attorneys you aren't paying won't give you much beyond an initial consultation)

If no, you've got an easy choice: take it down.

[+] Shank|12 years ago|reply
If they really had any standing, wouldn't they have sent the DMCA takedown request to github instead? Or are they just afraid it would be negative on their part to be permanently in https://github.com/github/dmca?
[+] jrochkind1|12 years ago|reply
If you want to keep it up, you should contact a lawyer.

It _may_ indeed be illegal under the DMCA to distribute. Or it may be legal, as there are some exceptions for reverse engineering etc.

Nobody here knows. Heck, even a lawyer might not know, but a laywer will know your level of legal risk and possible expense.

[+] Splendor|12 years ago|reply
Whatever you decide to do, don't make posts like this that could potentially be used against you.
[+] K0nserv|12 years ago|reply
Just how can this post be used against him?
[+] kevincrane|12 years ago|reply
This is completely off-topic, but I'm curious. How does one go about "reverse engineering" a protocol like what Snapchat uses? Do you just listen in on the bits that the phone sends (say, with Wireshark) and kind of guess and poke at it to see what each part does?

Edit: after some research (like reading TFRepo), I found some links mentioned that give some info in case anyone else is curious too.

http://adamcaudill.com/2012/06/16/snapchat-api-and-security/

https://github.com/tlack/snaphax#motivation-and-development-...

[+] bsilvereagle|12 years ago|reply
I suspect packet sniffing to see what is being sent and when.