Changes to the Google APIs Terms of Service


Google Developers

New Terms of Service

Two days ago on the Google developers blog they notified us of a change to the Terms of Service.    If you haven’t read it I encourage you to go read it now.

Google Developer blog:  Changes to the Google APIs Terms of Service

Welcome back.    The reason I am writing this post is this effects me and the sample projects you will find on this site.    Most of my sample projects have the Client id and secret embed in the project.   I have done this for several reasons you will read about them below.    The problem I am having is with this one line in the new Terms of service.

Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.

Using your contacts to your advantage

I am am in violation of the new terms of service by placing the client id and secret in my projects for you to play with.    Being that I am a GDE I decided to see if I could get some kind of dispensation. I used some of my contacts to get in touch with Dan Ciruli.    Dan Ciruli is a project manager at Google and the author of the above offending blog post.    You can imagine my surprise when he mailed me back to  “offer some clarification”.

Hi Dan,
Wow I really need to get used to people at Google emailing me.    I really didn’t think i would hear from you personally, I appreciate your willingness to hear me out.
Here is the problem.   I write tutorials using the Google .net client lib.  I have been writing them for a while now.   Recently i decided that since Google doesn’t want to create sample projects for all of the different APIs i would do it.    I had Alex check with legal and they agreed there wasn’t a problem with what i was doing.      Basically I had her check that my naming it “Google-Dotnet-Samples” wasn’t against some rule, I made sure to note that it was my own baby and not approved or created by Google.
https://www.daimto.com/googleanalytics-authentication-csharp/ <– Tutorial to go along with the Google Analytics API.
Its not done its a work in progress,  Google+, Google drive, Google Analytics, and the authentication projects are what i would call stable.   The others i am still working on and haven’t created tutorials for yet.   To many APIs to little time.
So now you have the background.
My motto for my website is “simple tutorials that work”  they are designed for beginners.   People with little or no .net experience can use my tutorials and get it to work.   I walk them though creating their own project on the developer console but I have a dummy project that is all set up.   I have the client id and secret in the project on GitHub.
There are several reasons for doing this.
1.  The project works out of the box.  They can download it and it will run.
2.  I have everything set up on Developer console.   If they are having trouble getting their code to work they can test with mine and verify if the problem is with there developer console set up or with there code.
      I have had experience with one guy that emailed me he couldn’t get it to work in the end he gave me access to the project and i set it up for him.
3.  Google Analytics Real-time API and Management write are currently in beta.   It takes about 24 hours to get access to test the real-time API, Management write takes almost 3 weeks to get access.   My project is white listed to be able to use both.
4.  Fine i spy on them.  I can see when someone runs the project.   My plan has always been if i can detect that someone is using the project to much and has released it then i will just delete the client id and make a new one.   So far that hasn’t been a problem.
I am not sure if you have access to check it.   project id is <Removed> ,    Oauth pops up with “Daimto Tutorial Test”
I can see that there have been 151 requests against it today.   I cant tell what they are doing but I hope they have learned something.
I understand Google wanting us to keep our Client id private.    But really I think they mean keep the client id and the refresh tokens private.   Just having access to the projects client id and client secret really posses a limited amount of risk if any to a users data.  Its the Refresh token paired with the client id and client secrete that pose a security risk.   In this case they are using my client id but just for testing and don’t have access to anything of mine.   I also have know way of knowing their refresh token so can not access their data.
In this instance is it really that much of a security risk for me to be allowing the client id and secret to remain in the project?     I have yet figured out how I could safely give them a Service account to test with.    I have an idea but i need to test it and run it by the Google Analytics team before i make it public.
Sorry for the wall of text.   I really enjoy working with the Google APIs and helping people learn.   I don’t want to do anything to jeopardize my relationship with Google.     If you feel that what i am doing goes against this new terms of service I will remove it,  but I think you understand in the interest of education it would be easier to for people to understand with it working.
Thanks again
Linda

And he responded

Hi, Linda —

(first: disclaimer. I’m a product manager, not a lawyer. I am not authorized or competent to offer legal advice, nor do I represent Google in legal matters)

Thanks for the writeup. You’re surprised that people at Google return emails? I’m surprised that people actually read Terms of Service!
I definitely understand your use case and the desire to make the getting started experience great for you adopters (and one thing to note: we want to make getting started experiences great, too!).
However, there are some reasons we have the restrictions in place. Yes, you are not making your personal data available to them. You are, however, allowing them to “impersonate” you in Google’s eyes. If our abuse systems detect abuse (say, should someone try to DoS one of our services using your key), you run the risk that they would terminate your account because of it (and please note — they wouldn’t just cut access to the key, they would shut down your console account).
Moreover, you’ve been granted whitelisted access to APIs that are not available to the general public (and, in all likelihood required agreeing to a separate Terms of Service) and are sharing access to anyone who wants it. There is no doubt that is a violation of those terms.
Sorry to not have the answer you are looking for, but keys are the one way we have to tell who is calling our services.
With 151 queries per day, I don’t think our abuse algorithms will detect anything amiss. But you should be aware that you are violating those terms and access could be terminated at any time.
Let me know if you have any further questions –
Dan

 

As you can see Dan made some very good points.   The reason for the client id is so that Google knows who is making the requests.   By allowing others to use my client id Google thinks that you are me.  So as of now I am deleting all of the client ids for my test project and generating new ones that I can use personally to test the tutorials as I create them.     From now on you will have to create your own and wait for access to any beta APIs.     If will create an extensive tutorial this weekend on how to create the different client IDs.   This I hope will help you create your own as painlessly as possible.

Conclusion

Terms of service are a pain but if we want to use something for free I guess we need to follow the rules.

 


About Linda Lawton

My name is Linda Lawton I have more than 20 years experience working as an application developer and a database expert. I have also been working with Google APIs since 2012 and I have been contributing to the Google .Net client library since 2013. In 2013 I became a a Google Developer Experts for Google Analytics.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.