Confused about API key policy

[gorpo]

I've been reading on the new API and was a bit confused by the need for an API key.

 

Normally API keys are used as a gatekeeper  to enforce a contract and/or to block abusive clients without affecting the service to other clients.

 

In this case however, I'm a bit confused since the servers are being run either by the users themselves or third parties, so why would Bittorrent Inc. act as a gatekeeper for that access?

 

I can understand this being used for accessing a server provided by Bittorrent Inc., but for my local server it strikes me as a bit odd that an external party is granting or refusing a client access to my system.

I feel that if there would be a gatekeeper to my servers at all, it should be fully under my control.

 

Please understand I'm not criticising. This is genuine curiosity:

Is there a technical reason for this policy?

Is it a temporary solution during development, or is it intended for the long-term?

[kos13]

Key is needed to block abusive clients. So if there will be a product based on Sync that abuse our API policy, we need to control that. 

[gorpo]

Thanks for the reply, but I'm still confused.

 

What's the API policy? I didn't see it in the documentation. I'm using this url: http://www.bittorrent.com/sync/developers/api

 

I'm also unclear on why Bittorrent Inc. is enforcing the policy for clients accessing my servers. I agree that API keys are useful, but I argue that if it's my server, then the assigning and blocking of keys should be under my control.

 

Mainly I think the API key policy as it's currently implemented goes against the original idea of btsync being decentralized and independent of third parties.

[capi]

Can you also elaborate a little bit on how the API key is verified? Is an Internet connection required when starting up? How would I distribute an Application that uses your API, as I suppose I'm not allowed to ship my API key (as it would be visible to the end-user, who could then use it to do something on his own with my key, etc.)

 

Any input on this would be very appreciated!

[delegatevoid]

I have to agree with capi.

Since the API key has to be stored in a config file that means you can't actually redistribute your application

if you don't want your API key to fall into the hands of the public.

[LazyWolf]

I do not see the current method of having Bittorrent deciding if a client is able to talk to someone's private server working out very well.

 

What would be the point of developing something for BTSync using the API if at any moment someone from Bittorrent could decide to remove your access to the product and end hours, days, months of work.

 

The only real use I can see for a project like this is for the api beta, once the api is out of beta I think Bittorrent as the gatekeeper should be removed.

I would love to still have api keys but I think it should be up to every individual server running BTSync to generate api keys for clients to connect to it...

 

Having Bittorrent have to approve any api use by clients or users in the future make the project useless in my mind. I see it like having strong encryption but every time you want to use it you have to ask for permission from twenty people, fill out a form, and wait 30+ days for possible approval.

 

One posible abuse I could see steaming from Bittorrent control over the api keys would be something like charging developers per Gig of data transfered because of the use of their program, if one does not pay up they could just disable your access.

 

I am hoping that the current situation is temporary.

 

In the future I am looking forward to our own api key generation with acls for every key we create with no intervention or interaction with Bittorrent.

[capi]

I can completely understand that the guys at Bittorrent want to get money out of the project, so I see how they came up with the API key. Maybe it would also really help if they published how they want to monetize the app (which I can completely understand, we are all developers ourselves and want to make money from our work).

[kos13]

Can you also elaborate a little bit on how the API key is verified? Is an Internet connection required when starting up? How would I distribute an Application that uses your API, as I suppose I'm not allowed to ship my API key (as it would be visible to the end-user, who could then use it to do something on his own with my key, etc.)

 

Any input on this would be very appreciated!

 

 

API key is verified inside a client, so client decides if the key is valid or not. We use the server to check if the particular key is in black list or not. If we see that particular key abuses something, then we contact developer to resolve the issue. If, for some reason, it won't help, then we put the key to black list.

 

I would like to elaborate further, if you don't mind. In p2p world we don't have users, accounts and this is completely new. However we want to make sure that Sync is used for good and developers understand that. True p2p world is completely different from any server based solution, we have to find a right answer on how Sync API should work.  And this will change internet and make it truly free. 

 

We are here to find a right solution with your help. 

[gorpo]

It's great that you're engaging your users to improve the product. I'm interested in using btsync, which is why I'm giving my feedback. Please don't misunderstand it as anything other than constitutive criticism.

The api key will be used, as you said, to verify that the software is used for good

What's worrying me is that "good" is subjective: what's good for the company may not be the same as for the user.

I agree with having an api key for accessing bittorrent's servers and services (e.g. your central tracker), but I don't think it's your position to dictate how the software is used otherwise.

As a developer interested in using the btsync API this makes me wary of investing my time. I understand that you seem to be reasonable, but I'd rather not depend on that if at all possible.

[voz]

"If we see that particular key abuses something"

 

@kos13 Could you please elaborate on things that you would consider as an abuse? I seem not to be able to find it anywhere.

[febox]

Yeah, i'm trying to understand too what would be an abusive use of the API.

[caj]

I would like to elaborate further, if you don't mind. In p2p world we don't have users, accounts and this is completely new. However we want to make sure that Sync is used for good and developers understand that. True p2p world is completely different from any server based solution, we have to find a right answer on how Sync API should work.  And this will change internet and make it truly free. 

 

We are here to find a right solution with your help. 

 

I respectfully suggest that if you want developers to use the Sync API to reinvent "the internet" in a fully P2P way, they will only do so if you let them - which means no central control mechanisms such as API keys.

 

I suspect that the very last thing you would want is legal responsibility for how the API is used, which you would probably have if you were able to shut down "reported as infringing" clients via their API keys. 

 

Imagine for a minute that you could be held responsible for each Bittorrent client in use. You would be forced to accept and process take-down notices for each reported abuse, the RIAA would have (had) some fun, the Bittorrent protocol would not be used by anyone anymore today (or rather, nobody would use your client), and the MLDHT would not have the strength needed to reinvent the p2p internet on top of it.

 

In a nutshell: if you go truly P2P by fully relinquishing any technical means of asserting central control, I strongly believe that you could end up as the underlying plumbing for a lot of exciting stuff. But if you artificially recentralize your (by its nature) true p2p plumbing via api keys... nope, then there will be something else used instead (see redecentralize.org) (possibly/probably using the bittorrent protocol and the MLDHT, at least to bootstrap, and who knows, maybe a reverse-engineered BT Sync protocol... but surely not your centralized client).

 

So... there is so much exciting potential here, please let us use it to its full delightful extent! And thank you for providing it. 

[tuxpoldo]

In a nutshell: if you go truly P2P by fully relinquishing any technical means of asserting central control, I strongly believe that you could end up as the underlying plumbing for a lot of exciting stuff. But if you artificially recentralize your (by its nature) true p2p plumbing via api keys... nope, then there will be something else used instead (see redecentralize.org) (possibly/probably using the bittorrent protocol and the MLDHT, at least to bootstrap, and who knows, maybe a reverse-engineered BT Sync protocol... but surely not your centralized client).

I fully agree with this! Both marxjohnson and me are currently waiting for answers regarding use and conditions of the API and have suspended any development that could base on the API since it is totally unclear if external open source developments using the API are wanted... The Terms and Conditions together with the API key are currently an obstacle for many new developments....

[LazyWolf]

Personaly I see no reason to develop anything with the BTSync API until this issue is resolved. I think the API key creation should be on each btsync, to allow the users to make their own keys and allow access to their btsync instances. At any point in time my hours/weeks of work could just be shut off by a Bittorrent employee which is completly against the idea of P2P. It would be like trying to build a house of cards in a vehical traveling down a dirt road -- you never know when the whole thing will be taken away from you.

[vladr]

Thanks for the reply, but I'm still confused.

 

What's the API policy? I didn't see it in the documentation. I'm using this url: http://www.bittorrent.com/sync/developers/api

 

I would also like to know that and postponing any development until more information is provided.

[StormEc]

I initially thought the API key was to unlock the api functionality for advanced use only, not that it was a kill switch operated by a 3rd party .

 

Working with "cloud storage" alternative solution one would have no control over what the application is used for and just one "bad apple" can mess up everything for everyone.

 

Got my API key a few days ago, came here to see whats up, saw this thread, and pretty much agree, a kill switch kills the use of the system.

 

I would like to elaborate further, if you don't mind. In p2p world we don't have users, accounts and this is completely new. However we want to make sure that Sync is used for good and developers understand that. True p2p world is completely different from any server based solution, we have to find a right answer on how Sync API should work.  And this will change internet and make it truly free. 

 

We are here to find a right solution with your help. 

 

Reg your answer, can it change the internet, yes, make it truly free, no. Not in the current incarnation.

 

Once its open without restrictions, and we can generate our own keys/kill switches, then yes, will use the system, for now, haven't even started development so nothing to suspend ....

Edited December 5, 2013 by StormEc

[dch]

The solution is to consider something like  the draft IETF standard, and develop towards that http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol/ instead using a public, open, protocol, at the core. Contact me offline if interested in discussing this further, its not really appropriate for the sync forum. twitter:@dch__

[stanha]

Well, the way it looks right now, the very idea of a controllable key by the 3rd party could be easily used by the NWO puppeteers, the NSA, HLS and similar outfits for the evil purposes of controlling and dominating the information flows on the net.

Furthermore, at some point, if not already, BT may be totally taken over and/or simply bought out and/or its funding may be withdrawn if they do not follow the instructions of the puppet masters, who are trying really hard currently to block access to "dangerous" information, which they bluntly classify as "terrorism" and so on.

If I recall, BT has about 1000 employees. Would be interesting to learn what is their source(s) of income and/or funding to pay this many employees, unless they are working for free.

In that context, P2P becomes nothing more than grand illusion, totally controlled by the same powers of evil and your freedom becomes a myth. How can there be freedom if some invisible hand pulls the strings on YOUR servers and controls YOUR clients? Is this a joke of some sort?

Also, can anyone tell me if BT Sync communications can be interfered and/or controlled be the 3rd party even if it does not utilize the API? It seems that the tracker may simply not inform any node of hash code for some collection.

Can hash key be controlled to block and/or interfere in transfers by the outside party? It seems unless you have some other trackers besides BT's, you have no idea that some nodes can not communicate with each other simply because the BT tracker does not propagate the hashes?

How much BT controls the transfers? Is it solvable by merely using the DHT and your own tracker?

It seems that since the hash codes pass the BT, from then on it should represent not much problem to simply directly access the nodes by the 3rd party. Because this is a central point of control in this setup, isn't it?

[stanha]

Question arises:

How can a developer develop an app which he does not control?

[delegatevoid]

Aside from whether or not the API key should be removed completely,

until that day comes it's still not clear to me:

 

1) Do we as developer distribute the key with our software, essentially making it very easy for users to 'fetch' and abuse them

or

2) Will every user have to request their own API key... which will be a disaster...

[stanha]

Question arises:How can a developer develop an app which he does not control?

I am not even beginning to contemplate to use the API in current context.

Actually, if I decided to develop something, I'd consider the open source projects, like Hive2Hive, for example, and, considering that it is written in Java, it makes it portable across a number of platforms.

http://hive2hive.org/

Actually, in the context of FSF community making the BTSync clone a priority item for Open Source development, which means that BT has no more than 3 to 6 months "to stay ahead of the pack" until others catch up with them, it seems a little strange that there are no public statements forthcoming from BT.

There are already projects and/or products that can do essentially the same thing as BTSync, regardless of who "looks better" and whose version is more stable or closer to the door.

But the clock is ticking...

[ryan29]

I really dislike the idea of a global blacklist for API keys.  If I'm running a sync network that's exclusive to my LAN, I should be able to do it with the internet disconnected and I should be able to allow any clients I want, even the ones that BitTorrent Inc. might consider abusive.

 

I also think there are some large technical challenges that need to be overcome to make developer API keys useful.  See this SO answer for a very brief explanation.  Since technically anyone can steal a developer's API key and abuse it, I think it only becomes useful if you're also providing a system that detects abusive behavior.

 

As a developer, I should be notified automatically if my API key is doing something considered detrimental to the system.  This should include things that may be the result of a stolen API key.  In a centralized system this could be something as simple having an API call using my key, but calling an API function that my client doesn't use.

 

In a decentralized system, I don't understand how you can do any of that though.  How do you determine if a client is being abusive?  Do you trust reports from peers in the network?  Do you test each client and observe behavior?  Do you just assume API keys never get leaked or stolen since there's no centralized system that can analytically detect changes in behavior?

 

How does BitTorrent deal with abusive clients (I actually don't know - I don't follow much P2P stuff)?  Shouldn't the BitTorrent protocol be the model for dealing with abuse in BitTorrent Sync?

 

And, the most important question, will the API key policy ever change?  I'll never buy into a platform where someone else gets to be the sole arbitror of what behavior is acceptable and what isn't.