xiphmont

It turns out forwarding posts to Google+ is a royal pain in the patookas, mainly because it's intended to be.

One small omission in all the Google documentation about programmatic access to Google+ streams is that, although there appear to APIs for doing this, eg, through plusDomains, none of them will work because write access to Google+ accounts tied to a Gmail address is 403 forbidden. The main Plus API is read-only.

And this probably isn't going to change. Google development is on record stating that they want to keep 'low quality' posts to a minimum on Plus, so there is no programmatic way to interact with it. Paraphrasing Google, 'even if a user only has to click on a Javascript 'Share' button, that level of interaction raises the bar.'

More about that Share button in a bit.

It's easy to say 'I don't believe that rationale' given that access is protected by OAuth2, and every third-party interaction must be explicitly approved by the user (as an aside, this is also algorithmically annoying, since all the approved ways of doing so are effectively browser-based interactions. It is difficult to ask for pre-authorization or authorization on the command line. There's no 'here's a pair of keys with secrets, have fun' like in Oauth1). In any case, if you wanted to access Google+ with your own app, there's a laborious multi-step web setup with 'enable this and click that and provide all your personal details' to make it work. It's locked down so tight, it's a wonder anyone bothers to use it.

Or is it? It looks hard from the developer and administrator standpoint, but if I maliciously targeted a user, all they'd see is e.g. 'Google Docs wants permission to access your contacts', and surely no one would fall for that. So I'm actually willing to grant Google their point here.

But there's another consideration. I'm of the technical priesthood, and it really annoys me when developers try to apply rules meant to keep the rabble in line to me.

Anyway, there's that share button.

It's run by several pages of densely packed and obfuscated javascript. It's always possible to pick that sort of thing apart slowly, but the easy chink in the obfuscation is that it has to communicate with the outside world somehow, and we can watch the requests and responses. We know it probably uses either Oauth2 or session cookies, and it's likely using unsigned and unobfuscated data within the TLS stream. It might even still be XHR-based like it was a few years ago, the last time someone decided to write a third-party Google+ API with write access.

Any success will be relatively temporary; there is no published API, so Google can change the internals whenever they want, and they do. There are a couple old third-party Google+ API libs, and they no longer work. But I think I'm going to play with it anyway. I mean, I already have this lovely little OpenGraph card generator...