Google restricted API scopes will require you to spend $75K yearly security assessment fees
G Suite developer program and the related Google API products at first site, might appear to open up huge frontiers for developers to create innovative add-on products. However, don’t get trapped by the size or the marketing — there are several traps waiting for you down the line.
It has become quite normal for Google to deprecate or just remove products. Along goes the associated APIs. Google Plus is the latest example. As the Product got killed, so did the Google Plus API. If you happen to develop add-ons using Apps Script, you are running a bigger risk. Entire services like fusion table, or even the popular URL Shortener can get discontinued one day leaving you scrambling for alternatives.
This makes an environment where the base is decaying faster than francium. Your codebase that depends on these APIs can become obsolete at any moment. When that happens, either you can kill your product or try to keep up and fix your product with alternatives spending more time and effort. A behemoth like Google doesn’t have to give a damn about either of the outcomes.
Add to this, is a brand new paradigm Google introduced and named as “Restricted Scope” APIs. For this set of APIs, the app/add on developer has to get their code certified by Google appointed security assessment agencies at a cost of up to $75000 per year. This security assessment comes only after Google’s own verification which itself takes a long time (8 to 9 weeks) and multiple follow ups. See my experience here.
Solution = more bureaucracy ?
In its announcement, Google says that the new steps is to elevate user trust in their API ecosystem.
Beyond Facebook’s Cambridge Analytica data privacy scandal, there is heavy panic in the tech world regarding how/what user data gets shared with third parties. Articles like “Tech’s ‘Dirty Secret’: The App Developers Sifting Through Your Gmail” amplified that panic.
The panic left all the big companies wondering where the holes were and how to patch them without hurting themselves. One easy solution, and the one that makes lawmakers happy, is to apply a heavy bureaucracy to the mix. A bureaucratic solution (“yes, we are reviewing and policing”) would be easy to explain both to the press and to governments.
On the other hand, a technical solution would allow developers to ask for the exact scope that they would use and inform in advance to the end user the access the App has. Make those scopes as atomic as possible. This would require the APIs to be designed in a more precise manner.
Remember that in the Analytica case, they were able to access more than they were allowed to.
Is a bureaucratic solution sustainable? Let’s imagine every API provider who follows the suite starts demanding a kind of “certification” from a third party. Then, every year, you’ll have to keep renewing each of these “certifications”. Imagine this in a rapidly moving tech space.
I have read that in Post-independence India, until around 1991, in order to start an industry producing anything, you had to get up to 80 or so licenses from various government departments. One had to struggle through a maze of bureaucracy before they could start making anything. How did such a system come into being? The lawmakers at that time feared that the country would fall again to its status as a colony if it didn’t make its socialist bureaucratic red tape so tight that it couldn’t move.
Let’s hope that these developments don’t lead to a utopia wherein every new product requires “certification” before even getting its first user.
Meanwhile, if you are planning to develop using the Google APIs, keep these points in mind. It might save you from misplaced efforts.
