Where once all roads led to Rome, it now seems as if virtually all data leads to Google, or Google compatibility at any rate.
If you create any new software today, you need to accept the likelihood that Users will already have some of their data already connected to Google services, and what you thought was going to be clean and easy, simply isn’t.
Orbit Communicator reached this point about 16 months ago and since then a number of iterations of code have jumped through the various multi-coloured hoops that allow Users to access their own Google-hosted data. This latest version is now available to download: https://orbit.madpenguin.uk/orbit-communicator.
Although it sounds like it should be relatively normal or trivial to exchange emails and calendar events with Google, if for no other reason than lots of third parties do it, there are some scary implications which may not be immediately apparent.
For example, you are using an online service which offers to integrate with your Google calendar and email. Agree to this and what is actually happening under the hood is that the service concerned is being issued a token which gives them access to your calendar and email. Now, while it is true that they have agreed not to abuse that token by reading your email, doesn’t it kind of feel like giving a stranger your front door key with the rationale that they’ll only use it for the intended purpose and not to rob you.
This model, where you essentially waive your privacy, seems to be that preferred by the tech big guys, especially those who claim to be acting in your best interests.
Orbit offers a different paradigm. The user is asked to register a project with their own Google account which yields a set of credentials. These credentials can then be entered into their Orbit installation. From these credentials Orbit can generate it’s own tokens which are not shared with any third party. It’s a little more complex, but the user’s privacy remains in-tact.
There’s a video walking through the process at the end of this article.
The remaining part of the puzzle is obtaining changes to Google calendars in real time. Although we use the oAuth2 authentication mechanism for sending and receiving email via Gmail, we’re still using the IMAP and SMTP protocols, which mean that we can use the IDLE facility to wait for new messages. Unfortunately, there is no such facility for the calendar API which requires a public endpoint to receive notifications for changes to events. One solution is to use CloudFlare’s Zero Trust framework free tier to create a virtual endpoint on their network, then use their VPN tool to create a connection to this endpoint. Anything else seems to involve a hosted solution and maybe some token sharing, which doesn’t appeal.
So, look out for (possibly) some CloudFlare integration in the next iteration, or polling, but I would really like to avoid that.
In the meantime, you can click on import anytime to grab anything that’s changed.
