Architecture and Security for Google Calendars


DayBack shows you your Google events using the Google Calendar API: it doesn't store your events in its own database, though some of the application settings also stored on DayBack's servers. This document describes the division of labor between DayBack and Google and which information is stored where. 

The structure is essentially the same for DayBack's connections to Office365 and Basecamp.


Security review

DayBack passed the thorough security review required of all AppExchange apps. In the case of Canvas Apps, this review also includes testing DayBack's servers, probing DayBack's configuration for injection vulnerabilities, and examining all traffic between and Salesforce.

Where is my event data stored?

In everything that follows, we'll use the word "event" to mean any Google Calendar record showing on DayBack calendar: like an appointment. This could be a record from any of your Google Calendars or from any calendars shared with you that you can see when you log into Google.

Events are only stored in Google and don't pass through DayBack's servers on the way to being displayed on the calendar. DayBack uses the Google Calendar API to query Google. DayBack doesn't have an event database of its own or a shadow table of events on DayBack's servers. 

Does DayBack respect sharing rules from Google?

Yes. The API runs under the authentication of your Google credentials. So a DayBack user has no more and no less access to their Google calendars than when they're on Google's own calendar site. Users can see their own calendars and any calendars that have been shared with them. 

What is stored on DayBack's servers?

DayBack records your calendar settings on its own servers. This includes all the information in the "admin" side of DayBack:

This includes the "Calendar Sources" shown above as well as any settings changes in the "Admin Settings & Defaults" section: things like the default view, time increment, the start time of your view, etc.

DayBack also stores the names of your statuses and resources, your resource folder names, and your status colors

If you've created custom actions as part of customizing DayBack, the code for those actions is stored on DayBack's servers.

Finally, DayBack records the email address of each user who is authorized to use DayBack and actually uses the app. You may also have designated some users as  DayBack admins, and those email addresses are recorded as well. Note that only identifying aspects of the user are their name and email address. No passwords or other identification about the user is stored. Here is an example of the actual data recorded:

  "group" : {
    "id" : "sf-org-00D36000000ojIYEAY17381-23517tk"
  "members" : {
    "1459229742595-1900723854" : {
      "account" : "[email protected]",
      "admin" : true,
      "id" : "1459229742595-1900723854",
      "userID" : "sf-005360000015SOJAA221107-29573tk"
    "1459305409187-0976614575" : {
      "account" : "[email protected]",
      "admin" : false,
      "id" : "1459305409187-0976614575",
      "userID" : "sf-005360000015SOUAA2-1931-93222tk"
    "1468520557325-2375843162" : {
      "account" : "[email protected]",
      "admin" : false,
      "id" : "1468520557325-2375843162",
      "userID" : "sf-005360000015SQZAA261098-2231tk"

What about sharing?

The sharing feature in DayBack is explicitly designed to publish calendar data to folks outside Google Calendar. You can turn this capability off or restrict it to certain users. When you manually create a share is the only time event data can leave Google. Details on how this works and what data is actually published can be found here: sharing. Sharing is like exporting your event data: a share recipient has no access to your G Suite organization or calendars outside the events shared. Bookmarks that are "shared" with "just me" or with "my group" are not available outside G Suite in this manner: only bookmarks set to "public" see their data leave G Suite.


Where are DayBack's servers?

The storage for is on a  Firebase Cloud Firestore server in the United States (learn more about Firebase locations). During DayBack's security review with Salesforce, the review team looked closely at all traffic between DayBack and the server to ensure all traffic was over wss (secured web sockets).

Our application is hosted on Digital Ocean's servers in their SFO2 location in San Francisco.


Data is encrypted at rest and in transit. At rest, data is encrypted with server-side encryption: Firebase manages the cryptographic keys on our behalf using the same hardened key management systems that Google uses for their own encrypted data, including strict key access controls and auditing. Each Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys. 

In transit, we use Transport Layer Security (TLS).

Datacenter certifications

The Firebase Cloud Firestore services have successfully completed the ISO 27001, ISO 27017 and ISO 27018 evaluation process, along with SOC 1, SOC 2, and SOC 3. Details here.