What 1stHour holds, and what it does with it.

Who this applies to

Two groups of people appear in 1stHour, and they are treated differently.

• Bishopric users. The people who sign in and plan: the bishop, his counselors, the ward clerk and executive secretary, and anyone a ward gives a bulletin editing role to.
• Ward members recorded by a bishopric. People who do not sign in, but whose names a bishopric enters in order to plan, such as a speaker to invite or a position to fill. These records are created by the ward, not by the member.

A ward bishopric decides what goes in. 1stHour stores it for them and makes it useful. Wards are kept separate from each other by design: every record carries the ward it belongs to, and a sign-in only reaches its own ward.

What a ward puts into 1stHour

Depending on which parts of the app the ward switches on, that can include:

• People a bishopric can ask to speak. A display name, whether they are youth, whether they have asked not to be called on, whether they have moved out, a free text note, the dates they have spoken, and the dates they declined.
• Sacrament meeting plans. Speakers, hymns, prayers, ward and stake business, the conducting script, and the announcements that become the bulletin.
• Assignments raised by any part of the app, with who owns them and when they are due.
• Callings, if switched on: the position, the person proposed, and where it has reached between proposed and set apart.
• Appointments, if switched on: who is being seen, when, for how long, and the reason in general terms.
• Bishopric meeting agendas and notes, if switched on.
• The ward's recurring events, if switched on, with owners and notes.
• Images a ward uploads, such as a flyer on an announcement or a photo at the top of a Sunday. These are stored privately and served only at addresses that cannot be guessed.

What is deliberately not there

The speaker list holds no phone numbers, no email addresses and no home addresses for ward members. 1stHour does not import a membership record, and it is not connected to any Church system. Nothing in it is an official record of The Church of Jesus Christ of Latter-day Saints.

1stHour is not the place for confidential matters discussed in an appointment. An appointment record holds who is being seen, by whom, when and for how long. There is no field for what was said in it.

When the bishop asks his executive secretary to get someone a time, he may leave one short line of instruction, such as "bring his parents". Only the two of them can see it, and it is deleted when that person is booked or met, or taken off the bishop's list. It is never written to the appointment or to a calendar, and never sent in a notification.

1stHour does not message ward members

The only email 1stHour sends goes to the people who sign in: the sign-in code itself, and, when a member on the sign-up page says none of the times work, a note to the executive secretary (or the bishop) with the name and email address that member gave, so they can reach out. 1stHour keeps the name on a to-do and does not keep the address. Ward members are never emailed or texted by the app. A member given as a guest on an appointment hears from Google, which sends the calendar invitation and its updates, as described under Google Calendar below. When a bishopric offers appointment times, it copies a link and sends that link itself, through whatever it already uses. No member contact details are needed for that, and none are stored for it.

The sign-up page

A ward can open a sign-up page where members book an appointment themselves, without signing in. A member gives their name and up to five email addresses. The name is kept on the appointment, as any appointment's is. The email addresses go to Google as guests on the appointment's calendar event, which is how Google sends the invitation, and 1stHour does not keep them. If Google cannot take the event at that moment, the appointment is not made and nothing is kept; the member is asked to try again. There is no field for why they want to meet. A name typed on the page is only suggested as a match to someone in the ward's People list; the bishopric confirms it.

What the ward can see

One part of 1stHour is public by design: the page a ward opens on Sunday. It shows the program, the announcements, and the bishopric contact details the ward chooses to publish. It does not require a sign-in, so treat anything published there as public.

A ward that opens its sign-up page publishes that page too: the names of the interviewers on it, the kinds of appointment offered, and the open times. It never shows who has booked a time, or when anyone else is meeting.

Planning stays private. A speaker who has only been asked, or who declined, is never shown on the public program. Appointments, callings in progress, bishopric meeting notes and assignments are visible only to the ward's signed-in bishopric.

Google Calendar

1stHour offers an optional connection to Google Calendar, so that appointment times are not offered when the interviewer is already busy, and so a booked appointment appears on their calendar. It is off unless somebody turns it on, and it is one connection per interviewer: connecting the bishop’s calendar does not touch a counselor’s.

An interviewer can connect their own calendar. So can the bishop or the executive secretary, who already set other people’s availability, which covers the ordinary case of a secretary managing a calendar the bishop has shared with them. 1stHour records which Google account granted the connection and who set it up.

The scopes requested

Five, asked for together at the first connection so that nobody has to reconnect later:

• openid and email, to know which Google account granted the connection. This is not how anyone signs in to 1stHour.
• calendar.calendarlist.readonly, to list the calendars on the account so the right one can be picked.
• calendar.freebusy, which returns whether a block of time is busy or free and nothing about what is in it.
• calendar.events, to put a booked appointment on the calendar, move it when it moves, and take it off when it is cancelled. This scope can read and write events, which is what putting something on a calendar requires.

What it is used for

Scheduling appointments on the connected calendar, in these ways and no others:

• Busy time. Times the interviewer is already busy are left out of the times a bishopric can offer and of the ward’s sign-up page. Google says only when a block is busy, not what is in it. It is asked each time and the answer is not stored.
• Putting appointments on the calendar. 1stHour creates an event for each appointment it books, including a time held as tentative until the bishopric confirms it, moves it when the appointment moves, and takes it off when the appointment is cancelled.
• Linking an event already there. When someone scheduling for an interviewer chooses to link an existing event as an appointment, 1stHour lists the timed events on that calendar for the days being looked at, with their titles, times and guests, so the right one can be picked. The list is shown only to that interviewer, the bishop or the executive secretary, and is not stored. For the event picked, 1stHour keeps its Google event id, version marker, start time and length, and keeps the time and length in step when the event changes on Google.
• Who’s invited. When a bishopric member opens or moves an appointment that is on Google, 1stHour reads the guests on that one event and whether each said yes or no, and can add or remove a guest there. The guests are shown, not stored.
• Keeping in step. About every ten minutes, 1stHour reads what has changed on each connected calendar, looking up to ninety days ahead. When an appointment’s event was moved or deleted in Google Calendar, the appointment follows. Every other event is ignored, and nothing from it is kept. 1stHour keeps only the marker Google issues for where the last read stopped.

1stHour does not use calendar contents for advertising or profiling, does not sell or transfer them, does not show them to anyone outside the bishopric, and does not use them to train any machine learning model.

A member’s email address, when one is given for an appointment, goes to Google as a guest on that appointment’s event, which is how Google sends the invitation. 1stHour does not keep it. If Google cannot be reached at that moment, the address is held so the invitation can be sent later, until Google accepts it, the appointment is moved, done, unbooked or cancelled, or the calendar is disconnected.

Tokens

The authorization Google issues stays on 1stHour’s servers and is never sent to a browser. It is encrypted with AES-256-GCM before it is stored, and it is used only to make the calls described above. How it and the rest of 1stHour’s data are protected is set out under How data is protected.

Disconnecting

Disconnecting in 1stHour revokes its access at Google, then deletes the stored authorization token and the connection, along with any invitation still waiting to be sent. Appointments already on the calendar stay there as ordinary events. Access can also be revoked at any time from Google Account permissions, which works whether or not 1stHour is open.

Signing in

Signing in identifies a person by an email address and the ward and role attached to it. 1stHour stores that email address, the ward, and the role.

1stHour has no passwords. Signing in means asking for a one-time code, which arrives by email and signs that person in when they enter it. Nothing about a password is stored, because none is ever set.

Sign-in does not use a Google account. Connecting a Google Calendar is a separate, optional thing, described below; it tells 1stHour the email address of the account that granted it, and nothing else about that account. 1stHour never receives a Google contact list or Gmail content.

Where the data lives

1stHour runs on Amazon Web Services in the United States, in the Oregon region (us-west-2). Records are held in DynamoDB and uploaded images in a private S3 bucket. Traffic is served over HTTPS. Storage buckets are not publicly listable, and uploaded files are reachable only through the content delivery network at unguessable addresses.

How data is protected

These protections cover everything 1stHour holds, and sensitive data from Google in particular: the authorization Google issues for a connected calendar, the email address of the Google account that granted it, and the few details kept for an appointment’s event.

• Encrypted in transit. Every connection to 1stHour uses HTTPS with TLS 1.2 or newer, and browsers are told to use nothing else (HTTP Strict Transport Security). 1stHour’s calls to Google are made over HTTPS too.
• Encrypted at rest. Records are stored in Amazon DynamoDB and uploaded images in Amazon S3, both encrypted at rest with AES-256. The Google authorization is encrypted a second time by 1stHour, with AES-256-GCM, using a key kept apart from the database, so a copy of the database alone cannot reach anyone’s calendar.
• Google authorization stays on the server. It is never sent to a browser or shown to anyone, including the person who connected it. It is decrypted only to make one of the calls described under Google Calendar, and the short-lived access Google grants from it is held in memory, never stored.
• Access is limited by ward and role. Every record carries the ward it belongs to, and the server checks the ward and role of each signed-in request before reading or writing anything. Something a role may not see is withheld by the server, not only hidden on the screen. Calendar events listed while linking an event, and the guests on an appointment’s event, are shown only to the interviewer, the bishop or the executive secretary.
• Sign-in. There are no passwords to steal: signing in uses a one-time code sent by email. The sign-in session is kept in a cookie that scripts on the page cannot read, sent only over HTTPS and only to 1stHour’s own sign-in service.
• Connecting a calendar. The request to connect carries a signed token that names the ward and the person who started it and expires after ten minutes. 1stHour completes the connection only for that signed-in person.
• Diagnostics hold no Google data. Logs and traces of calls to Google record counts, timings and status codes, never tokens, email addresses, event titles, guests or other calendar contents.
• Operations. Only 1stHour’s operator can reach the production systems, which run in an AWS account separate from development and testing. The databases keep continuous backups and are protected against deletion.

Data is kept and deleted as described under Keeping and deleting, and disconnecting a calendar deletes its stored authorization at once.

Youth and children

1stHour is used by adult members of a bishopric, and is not directed to children. It can, however, hold information about people under 18, because a bishopric plans youth speakers and youth interviews. That information is entered by the ward, not by the young person, and it is limited to what planning needs: a name, that they are youth, and the dates involved.

A parent or guardian who wants a young person's record removed should ask the ward bishopric, who can remove it directly, or contact 1stHour at the address below.

Diagnostics

1stHour records operational logs and traces so that failures can be found and fixed. These hold request paths, timings, error details, and the ward and role that made the request. They expire automatically, currently after 14 days. They are not used to profile anyone and are not shared for advertising.

An email that fails to send is held privately for up to 30 days so that it can be resent, and is then deleted.

The waitlist

The email address entered on the 1stHour home page is collected through a Google Form and used for one thing: telling that person when 1stHour opens to more wards. It is not sold and not passed to anyone else.

Email 1stHour sends

Only to people who sign in, never to ward members:

• Sign-in codes. Sent when somebody asks to sign in. This is how 1stHour works without passwords.
• A note when no time works. When a member on the sign-up page says none of the times work, the executive secretary (or the bishop) is told, with the name and email address the member gave.
• The morning schedule. On a day with appointments, at 6:00 AM, an interviewer who signs in is sent that day's appointments, and the executive secretary everyone's: each person's name, the kind of appointment and its time. Each person can turn theirs off in Settings or from the email's own link, and the bishop can turn it off for the whole ward.
• Other reminders about a ward's own work, such as a speaker still waiting on an answer. These are planned rather than built, and each will be something a ward can switch off.

1stHour does not send marketing email, and a sign-in address is not added to any mailing list. Calendar invitations to members come from Google, not from 1stHour.

Sharing

1stHour does not sell personal information and does not share it for advertising. It is shared only with the infrastructure providers that run the service, currently Amazon Web Services and Google (for the waitlist form and, where a user connects it, Google Calendar, which receives each appointment’s event: its time, a title naming the person and the interviewer but never the appointment’s type, its place, the email addresses of its guests and, for a booking from the sign-up page, the link to change or cancel it), and where the law requires it.

Keeping and deleting

Ward records are kept while the ward uses 1stHour, because a bishopric's value in it comes from history: who spoke last spring, who was asked, what happened last year.

A bishopric can delete most records from inside the app, including meetings, business items, templates and a person's access. Someone on the speaker list is marked as moved out rather than deleted, so that the ward's history of who spoke stays intact.

To have a ward's entire data removed, or one person's records removed outright, write to support@1sthour.app. Requests are answered within 45 days. Removal covers the live records and the uploaded images. Operational logs expire on their own schedule, currently 14 days.

Changes

When this policy changes, the effective date at the top changes with it. A change to how Google user data is used will be described here before it takes effect.

Contact

Questions, deletion requests and anything else about privacy: support@1sthour.app.