Privacy Policy

MyRoster — Google User Data

This section specifically addresses how MyRoster accesses, uses, stores, and shares Google user data across both platforms, in full compliance with the Google API Services User Data Policy and the Google APIs Terms of Service.

Data Accessed

MyRoster for iOS accesses the following Google user data via OAuth with your explicit consent through the Google Sign-In consent screen:

• Google Sign-In (OAuth scopes: openid, userinfo.profile, userinfo.email) — your Google account name, profile picture, and email address. This data is used to identify your account within the app and personalise your experience.
• Google Calendar (OAuth scope: auth/calendar) — read and write access to your Google Calendar, used to sync your shifts as calendar events. This includes event titles, dates, times, and descriptions that you have authorised the app to create.

MyRoster for Android accesses the following device-level permissions and Google services:

• Device Calendar (android.permission.READ_CALENDAR, android.permission.WRITE_CALENDAR) — read and write access to the device's local calendar, used to sync your shifts as calendar events. This accesses the on-device calendar database (which may be synced by Google Calendar on your device) and includes event titles, dates, times, and descriptions.
• Firebase Cloud Messaging — a Google service used to deliver push notifications (e.g., shift reminders) to your device. This uses an anonymous device registration token and does not access any personally identifiable information.
• Firebase Remote Config — a Google service used to deliver app configuration and feature flags. No personal user data is accessed or transmitted.
• Firebase App Check — a Google service used to verify that requests to backend services originate from genuine instances of the app. No personal user data is accessed.
• Firebase Cloud Functions — used to proxy AI-assisted features (e.g., roster interpretation). Requests may include shift-related text you submit within the app. No Google account data is included in these requests.

No other Google account data (such as Gmail, Contacts, Google Drive, or location data) is accessed on either platform.

How Google User Data Is Used

Google user data and Google services are used exclusively to provide the app's core features:

• Identifying your account and personalising your in-app experience using your Google name, profile picture, and email address (iOS)
• Writing your shifts to your Google Calendar so they appear across your devices (iOS via Google Calendar API; Android via device calendar)
• Reading existing calendar events to avoid duplicates when syncing
• Delivering timely shift reminders via push notifications (Android via Firebase Cloud Messaging)
• Applying app updates and feature configuration remotely (Android via Firebase Remote Config)
• Securing backend AI features against unauthorised access (Android via Firebase App Check)

Google user data is not used for advertising, profiling, analytics, or any purpose unrelated to the app's core rostering and wage calculation functionality.

AI Features & Google Data

MyRoster's optional AI-assisted features (on both iOS and Android) send user-submitted content to my Firebase Cloud Functions backend for processing. No Google account data is included in these requests — your Google name, email, profile picture, and calendar contents are not sent to the AI features. This data is not used to train, improve, or develop any AI or machine learning models. For the full description of what these features send, see the AI Features section below.

How Google User Data Is Stored

All Google user data is stored locally on your device only. Specifically:

• Your Google account name, profile picture, and email address are stored locally on your device for in-app display and are not transmitted to any external server (iOS)
• Shift events are written to your Google Calendar (iOS) or device calendar (Android) and are subject to your device's own sync settings
• No calendar data is transmitted to or stored on servers owned or operated by me
• Firebase device tokens and configuration data are managed by Google's Firebase infrastructure and are not stored by me beyond what Firebase requires to operate (Android)
• Uninstalling the app removes locally stored app data; calendar events previously written to your calendar will remain unless deleted manually

How Google User Data Is Shared

I do not share Google user data with any third parties beyond what is required to operate the Google/Firebase services described above. Specifically:

• Your Google account name, email address, and profile picture are not shared with any third party
• Calendar data is not shared with advertisers, analytics providers, or data brokers
• Calendar data is not transferred to any external service or server operated by me
• Firebase device tokens are used only to deliver notifications to your device and are not shared with third parties
• No Google user data is sold, rented, or monetised in any way

Minimum Necessary Data

MyRoster requests only the minimum permissions necessary to deliver its features. On iOS, Google Sign-In and Calendar access is requested only when you choose to sign in with Google. On Android, calendar read/write access is requested only when you enable calendar sync in Settings. Permissions can be revoked at any time.

Revoking Access

You can revoke MyRoster's access to your Google data at any time:

• Google Sign-In & Calendar API (iOS): Visit your Google Account permissions page and remove the MyRoster app. This revokes access to your profile information and Google Calendar.
• Device calendar & notifications (Android): Go to Android Settings → Apps → MyRoster → Permissions to revoke calendar or notification access.

Previously written calendar events will remain in your calendar unless deleted manually. Locally stored profile data is removed when you sign out or uninstall the app.

MyRoster — Friends & Shift Sharing (Optional)

MyRoster offers an optional, opt-in feature called Friends / Shift Sharing that lets you connect with colleagues and share when you are rostered to work. This feature introduces user accounts and limited online data sharing. If you do not create a Friends account, none of the data described in this section is collected or shared, and nothing else about your experience changes. Everything below applies only if you choose to create an account and use Friends / Shift Sharing.

Your financial information is never shared with friends. Wages, pay, grades, allowances, overtime and penalty calculations, your days off and availability, and your personal notes are never uploaded as part of Friends / Shift Sharing and are never visible to anyone you connect with. Friends see only the roster information described below.

Please note that this statement is specific to the Friends feature. Two other separate opt-in features can transmit financial data off your device for your own use: the AI features (which send wage context with your questions) and Cloud Sync on Android (which backs up your employment profile). Neither of those makes anything visible to your friends.

Information Collected When You Use Friends / Shift Sharing

• Account identifier — a unique user ID created for your account.
• Email address — provided via Sign in with Apple (which may be an Apple private-relay @privaterelay.appleid.com address if you choose to hide your email), Google Sign-In, or email/password registration.
• Display name — the name or nickname you choose to show to your friends.
• Profile photo — optional, only if you upload one.
• Your friends list / connections — the people you connect with, and invitations you send or receive.
• Device notification token — so I can notify you when a friend updates their roster.
• Shared roster information — the dates and times you are rostered to work and a general shift category (for example day, afternoon, or night). The shift location/ward label you entered (the default is "My Ward") is shared only if, and only with, a specific friend for whom you have explicitly turned on location sharing.

What this feature does NOT collect or share: your wages and all financial/pay information, your days off or availability, and your personal notes. These never leave your device.

How This Information Is Used

• To create and manage your account and sign you in.
• To let the friends you authorise see when you are rostered to work.
• To send you notifications when a friend updates their roster.
• To operate the friend invitation and connection system.

This information is not sold, and is not used for advertising or cross-app tracking.

How This Information Is Shared

• Your shared roster information is disclosed only to friends you have accepted and granted permission to. You control this per friend, and you can turn sharing off or remove a friend at any time — which immediately revokes their access. Revocation is enforced on the server against the live permission record, so it takes effect on their very next refresh rather than relying on their app to respect it.
• I use Google Firebase (Authentication, Cloud Firestore, Cloud Storage, Cloud Functions, and Cloud Messaging) as my service provider to operate this feature, and Apple (Sign in with Apple) for account sign-in. These providers process data on my behalf to deliver the service.
• I do not sell personal information or share it with advertisers.

Storage, Security & Overseas Handling

• Account and shared data are stored using Google Cloud / Firebase in an Australian (Sydney) data region — the database, file storage, and the server functions that process it are all hosted in Australia.
• Some Google services used for sign-in and notifications operate globally, so limited information (such as login identifiers and device notification tokens) may be processed outside Australia — in the United States and other countries where Google operates. This cross-border disclosure is relevant to Australian Privacy Principle 8.
• Data is encrypted in transit and at rest. Access to shared roster data is enforced by server-side security rules so that only friends you have authorised can see it. Financial data is never transmitted, and uploaded profile photos have their location metadata removed.

Data Retention & Deletion

You can delete your Friends account at any time from within the app. Deleting your account removes your account, your profile and photo, your shared roster information, your friend connections (removed from both sides), any pending invitations, and your notification tokens. You may also contact me to request access to, correction of, or deletion of your personal information (the right to erasure under the Australian Privacy Principles).

Your Consent & Control

Friends / Shift Sharing is entirely optional and opt-in. Sharing is controlled per friend, friends can be removed at any time, and turning off sharing or removing a friend immediately revokes their access. Sharing of your shift location/ward label is off by default and must be enabled explicitly for each individual friend. This feature is intended for users aged 18 and over.

AI Features (Optional)

MyRoster includes optional AI-assisted features on both iOS and Android: Roster Scan, which reads a photo of your printed or on-screen roster and turns it into shifts, and AI Chat, which answers questions about your roster, award, and pay. These features only run when you choose to use them. If you never use them, none of the data below leaves your device.

What Is Sent When You Use Them

• Roster Scan — the photo you choose, plus your state, the current date, and your saved shift templates so the roster can be read correctly. One thing worth knowing: if the roster you photograph happens to show colleagues' names or shifts, that is part of the image too, so it helps to crop to just your own lines where practical.
• AI Chat — the question you type, plus the roster context needed to answer it. Since the feature exists to answer things like "what did I earn last fortnight?", that context includes your shift and pay figures, along with profile details such as your grade and state so the right award rates are used.

How It Is Processed

• Requests go to my own Firebase Cloud Functions backend, hosted in the australia-southeast1 (Sydney) region, which forwards them to the AI model provider. Sending them through my backend means the AI provider never receives your account credentials and I do not have to embed API keys in the app.
• The underlying AI model is provided by Anthropic (Claude). Your submitted content is disclosed to that provider in order to generate a response, which means it is processed outside Australia. This cross-border disclosure is relevant to Australian Privacy Principle 8.
• Requests are processed transiently to generate your answer. Your submissions are not used to train or improve any AI or machine learning model — by me, by Anthropic, or by Google.
• Requests are protected by Firebase App Check, which verifies they come from a genuine copy of the app.

Your Control

These features are entirely optional. Roster Scan only sends an image when you actively choose a photo and start a scan, and AI Chat only sends data when you send a message. If you would prefer no roster or wage information to leave your device, simply do not use them — every other part of MyRoster works without them.

Cloud Sync — Android (Optional)

MyRoster for Android offers an optional Cloud Sync feature that backs your data up to your account so it can be restored or carried to a new device. It requires you to sign in and to turn sync on. If you do not enable Cloud Sync, your data stays on your device and none of the following is uploaded. (On iOS, the equivalent role is played by your own private iCloud account, which I cannot access.)

What Is Synced

When enabled, the following is stored in your account on my Firebase backend:

• Shifts and roster entries
• Leave and non-effective days
• Employment profiles, which include your pay rates, allowances, and wage-related settings
• Your personal notes, and any photos attached to notes
• CPD entries and any attached photos
• AI chat conversations and messages
• App settings

This data is stored under your own account and is not visible to your friends, is not shared with third parties, and is not used for advertising. It is protected by server-side security rules so that only your signed-in account can read it, and it is encrypted in transit and at rest. It is held in an Australian (Sydney) data region, so your synced roster and pay data stays onshore.

Deleting Synced Data

Deleting your account from within the app removes your synced data from the backend. Note that clearing the app's storage or uninstalling the app removes only the local copy on that device — it does not delete data already synced to your account. To remove that, delete your account in-app or contact me.

Advertising & Attribution — Android

I'm a solo developer, and I occasionally run ads so that shift workers can find MyRoster. To know whether those ads are worth paying for, MyRoster for Android uses the standard app-install measurement that Android provides, so an install or subscription can be matched back to the ad it came from. This is the same measurement almost every app that advertises uses.

None of your personal roster information is involved. Your shifts, wages, pay rates, notes, calendar and account details are never used for advertising and are never sent to any advertising company. This is only about counting installs and subscriptions.

MyRoster for iOS does none of this — it contains no advertising or attribution software at all.

What Is Involved (Android)

• Your device's advertising ID — a resettable number Android provides for exactly this purpose. It is not your name, email, or phone number.
• An anonymous device identifier generated by Meta's software, which is included in the app for the same reason.
• Install and campaign details — which ad or campaign came before the install.

Who Receives It

These identifiers go to RevenueCat (which manages subscriptions for MyRoster) and to Meta, so that an install or subscription can be credited to the right ad. Being straightforward about this: Meta is an advertising company and can connect these identifiers to its own records, which is what makes the measurement work. That is normal for app advertising, but it is a genuine disclosure to a third party, so I would rather spell it out than describe it vaguely. These companies process the information overseas, including in the United States, which is relevant to Australian Privacy Principle 8.

Your Control

• You can reset or delete your advertising ID at any time in Android Settings → Privacy → Ads. Deleting it stops the app receiving it, and MyRoster keeps working exactly as before.
• I don't sell this information, and I don't use it to build any profile of you. I use it to see which ads bring people to the app.

Crash Reports & Diagnostics

MyRoster collects crash and error diagnostics so I can find and fix bugs. Behavioural analytics is switched off — Google Analytics for Firebase collection is disabled in the app — and diagnostics are never used to build a profile of you or to target advertising. (Separately, MyRoster for Android does use advertising identifiers for install attribution; that is described in the Advertising & Attribution section and is unrelated to crash reporting.)

Services Used

• Firebase Crashlytics (iOS and Android) — crash reports. On iOS no user identifier is attached. On Android, reports are tagged with an anonymous Firebase Installation ID so that repeat crashes from the same install can be grouped together; this identifier is not linked to your name, email, or account, but it is a persistent per-install identifier.
• Sentry (iOS only) — non-fatal errors, breadcrumbs, release health (crash-free session counts), and Apple MetricKit diagnostics such as app hangs, CPU exceptions, and excessive disk writes. Sentry is not used in MyRoster for Android.
• Firebase Performance Monitoring (Android only) — app start times, screen rendering, and network response times, used to find slow parts of the app.

What Is Sent

• The crash or error type and its stack trace (which code path failed)
• App version and build number, and whether the build is a public App Store release or an internal test build
• Device model, operating system version, locale, and general device state (such as available memory, storage, and battery level)
• Breadcrumbs — a short trail of technical in-app events (for example screens opened and app lifecycle changes) leading up to the error
• A small sample of performance traces — approximately 2% of sessions on public App Store builds

What Is Deliberately Not Sent

The following are switched off explicitly in the app's code, rather than left to the default settings of the diagnostic tools:

• No user identifiers and no IP address. Sentry's personal-data collection is disabled, so reports are not attributed to you or to your device, and I cannot link a report back to an individual user.
• No screenshots. A screenshot would capture your roster and pay figures, so screenshot attachment is disabled.
• No view hierarchy captures, for the same reason — a screen dump can expose on-screen wage data.
• No network request data. Network breadcrumbs, network tracking, and failed-request capture are all disabled — specifically because a Google Calendar sync address contains your calendar ID, which for a primary calendar is your email address.
• No roster, shift, wage, pay, allowance, availability, or notes content, and no Google account data or Friends account data.

Overseas Handling (Australian Privacy Principle 8)

Sentry processes and stores this diagnostic information in the United States. Sentry does not offer an Australian data region, so if you use MyRoster for iOS, the limited technical diagnostic information described above is disclosed to and held by an overseas recipient in the United States. This cross-border disclosure is relevant to Australian Privacy Principle 8. Firebase Crashlytics diagnostics are likewise processed on Google infrastructure outside Australia. Because these reports carry no identifiers, no personal information about you is intended to be included in what is transferred.

Retention & Your Control

• Diagnostic events are retained for a limited period under the standard retention policies of Sentry and Firebase Crashlytics, and are then deleted automatically.
• Apple MetricKit diagnostics (hangs, CPU exceptions, disk writes) are only delivered to the app if you have analytics sharing enabled in iOS Settings → Privacy & Security → Analytics & Improvements. Turning off "Share iPhone Analytics" or "Share with App Developers" stops those diagnostics at the operating system level.
• Crash and error reporting is otherwise active by default in the released app, and there is currently no in-app switch to turn it off. Because the reports carry no identifying details, I have no way to find an individual user's diagnostic events in order to delete them — there is nothing in them that points back to you.
• If you have questions or concerns about diagnostic collection, please contact me.

This Website

Everything above describes the MyRoster app. This section covers this website, myrosterapp.com.au, which is separate. Your roster, shifts, and wage data are never on this website — the site is marketing and support pages only, and has no access to anything in the app.

Analytics & Advertising Measurement

This site uses three measurement tools, for the same reason described in the Advertising & Attribution section — so I can tell which pages are useful and whether my ads are worth paying for:

• Google Analytics 4 — which pages are visited, roughly where visitors come from, and general device/browser information.
• Meta Pixel and TikTok Pixel — used to measure whether someone who saw one of my ads went on to visit the site and tap through to the App Store or Google Play.

These tools set cookies and similar identifiers in your browser, record the pages you view, and record when you tap an App Store or Google Play button. Meta and TikTok are advertising companies and can connect this activity to their own records, in the same way described earlier for the Android app. They process this information overseas, including in the United States, which is relevant to Australian Privacy Principle 8. I do not sell any of it.

Contact & Creator Forms

If you send a message through the contact or creator forms, the name, email address, enquiry type, platform, subject, and message you enter are submitted through Web3Forms, which forwards them to my email inbox. A captcha check is used to block spam. I use these details only to read and reply to your message — they are not added to any mailing list and are not used for advertising. Replies come directly from my own email.

Your Choices

• You can block or delete cookies in your browser settings, or use a content or tracking blocker — this site works perfectly well with all of it blocked.
• Google offers a Google Analytics opt-out browser add-on, and Meta and TikTok both provide ad preference controls in your account settings on those platforms.
• The only thing this site stores for its own sake is your light/dark theme choice, kept in your browser so the site remembers it. That is not tracking and is never sent anywhere.