Hacker News Reader

Comment by dleslie | Hacker News Reader

Many folks on here might be too young to remember, but there was an era where cable companies served premium channels with a scrambled signal to all customers, and sold access by way of attaching the appropriate filter. In fact, all channels were protected in this way, with your cable box holding the necessary filters. Albeit, some were merely hidden by a band pass filter and not scrambled.

Anyhow, those arguing that third party clients ought to have access to the API are making a similar argument to those who wanted to use third party filters to access channels they hadn't paid for. Why, it would go, if the cable company didn't serve the signal then it wouldn't be available to be used.

Which is not unlike claiming that the data provided by a private API is free for the taking. It's not, and it's certainly not with the consent of those endeavoring to keep the API private, even if it's accessible.

View on HN

They aren't making the api private, they are making it tricky.

They have no intention (that I know of) of banning new browser technology. They don't say you must use Firefox/Chrome. Which means I can make my own browser and render it however I like.

If the data was meant to be secret, it would be encrypted. At the moment, if I do

> curl -L instagram.com

I get a mix of HTML, JS and CSS. In plain old text.

What am I allowed to do with this data?

Do I have to render it according to what WHATWG says? Obviously not.

If they were trying to limit access to their data, they would, like cable companies do, provide a secret to me so that I could decrypt the response.

Why don't they do that?

Because they want the data *public*.

They could make instagram available only via its own app with its own transport layer.

If they did that you would be violating anti-circumvention in the DMCA by reversing and publishing the protocol.

They want the data open and available to everyone to lower the barrier to entry to make more money. The tradeoff is that they don't control how that data gets presented.

Entirely their choice.

> What am I allowed to do with this data?

Their ToS disallows the use of unauthorized clients; if one were to accept the ToS, create an account, and use the unauthorized client then they would have violated the agreement and circumvented the legal protections around the private portion of their API.

> If they were trying to limit access to their data, they would, like cable companies do, provide a secret to me so that I could decrypt the response.

They do. That's the effect of having portions of the API and data accessible only to those who are logged in, and have agreed to the terms of service.

Doesn't seem like a valid analogy to me. Access to an API isn't the same thing as intentionally accessing a paid service for free.

If someone writes an app that somehow bypasses needing a Netflix account and lets you stream video from them without paying them. That would be analogous. The intent would be to illegitimately access a paid service.

Using a third party client with a valid account to access API endpoints that respond to that account. I don't see a problem with that. I don't care what the ToS says. It should not be legal to disallow that in a ToS. It also shouldn't be legal to intentionally obfuscate your APIs.

Third party clients are okay and attempting to block them is morally wrong and should not be legal.

By ignoring the agreed upon terms of service and violating those terms you would be violating the consent of the service provider.

If you don't find those terms favorable the correct action is to not use their service; violating their consent is not morally sound.

Well on the contrary, I'm saying that I find those particular terms immoral, that those terms should be disallowed by law, and that I think it is either morally neutral or possibly even virtuous to intentionally and knowingly violate them.

It's similar to civil disobedience I suppose, except in this case not a law but rather a civil "contract" inasmuch as an impenetrable ToS that a user is forced to click through can be viewed as a proper contract as opposed to a written notification from the vendor that they intend to terminate your service if they discover you doing any of the following things.

>Many folks on here might be too young to remember, but there was an era where cable companies served premium channels with a scrambled signal to all customers

Even more esoteric, there was an over-the-air company, IIRC called Vu, that broadcast an analog encrypted signal that required a box to decode properly. Tuning in without it resulted in a signal that was not in-sync so the h&v blanking floated across the screen. In my area, it was a UHF channel that would switch to the premium encrypted signal at 7pm. The decoder was about the size of an Atari 2600 console.

If a third party can build a box to decrypt your encryption without you providing a key, then instead of suing the third party out of existence, you should pick a new encryption algorithm that's actually secure. Consider this analogy: should Master Lock be able to sue companies that make padlock shims, since several of their locks are vulnerable to shimming attacks?

Building and owning circumvention devices is generally legal; using those devices to access things protected by locks, which you are not authorized access, is generally not legal.

If people use weak locks on their house I should be able to pick them and let myself in, right?

No. My point is if you do that, only you should get in trouble, not the company that made the lockpicks you used.

The companies that made the lockpicks have the argument that they're only to be used by professional locksmiths in the process of opening a lock that the owner has authorized them to, which is legal. Selling a tool that only has illegal uses would quickly lead to trouble.

The third party clients can only be used in a way that violates the ToS.

Reply on news.ycombinator.com