BidGlory privacy notice

1. Who handles what

BidGlory is business software licensed to a company (the "Customer"). The bid, job, product and client records inside a BidGlory instance belong to that Customer, who decides what goes in and who may see it. ProjectThunder Systems operates the hosted service and processes those records on the Customer's behalf. If you are an estimator using BidGlory at work, your employer is the Customer.

2. What the app sends to our servers

• Your sign-in. The user name or e-mail address you type and your password, sent over HTTPS to obtain a session token. The password is not stored on the device. The token is held in the iOS Keychain and expires.
• The records you open and edit. Bids, bid items, rooms, jobs, job log entries, purchase orders and product data.
• Client and contact details. Company name, contact person, phone and mobile numbers, fax, e-mail address, and postal and ship-to addresses.
• Photos and files you attach to a bid, including photos you take with the device camera from the bid screen.
• A sign-in audit record. Date and time, the user name presented, whether the attempt succeeded, the IP address it came from, and the browser or app identifier. It exists to detect password guessing and account misuse.

3. What we do not do

BidGlory contains no advertising or analytics SDK and no advertising identifier. We do not track you across other companies' apps or websites, we do not sell or share your information with data brokers, and we do not use your data or your Customer's records to train models. The app does not ask for your location, your device's address book, your photo library, your microphone or your calendar. The only device-sensor permission it requests is the camera, and only for a photo you deliberately take to attach to a bid.

4. What stays on your device

Your device keeps four things inside the app's private storage. The first three are there so the app keeps working without signal:

• your session token, in the iOS Keychain;
• a read cache of answers the server has already given, so screens still open offline;
• an outbox of edits you made while offline that have not yet reached the server;
• a copy of every proposal you open as a PDF or Word document from a bid. Each one is the file the server generated, with the client's name and address and the bid's items and prices, saved in the app's cache folder so your device can show it. Each time you open one, the app saves a new copy.

The two local database files are marked so that iOS keeps them encrypted at rest — unreadable until the first time the device is unlocked after it restarts — and excluded from iCloud and iTunes backups. One consequence is worth stating plainly: restoring a backup onto a replacement device does not carry unsent edits across.

Signing out deletes the token, erases the read cache and deletes the proposal copies. It deliberately does not delete the outbox. Those are your own edits that have not been sent, and deleting them would destroy your work. They stay on that device under your account, are sent the next time you sign in on it, and cannot be read or sent by anyone else who signs in on that device. An unsent edit is never quietly sent long after the fact — past a fixed age it is shown to you for a decision instead.

The app deletes the proposal copies when the device is signed out: when you sign out, when your session expires or is ended and the app returns to its sign-in screen, and when the app starts and cannot confirm that anyone is signed in. It also deletes them when someone else signs in on the device, removing every copy that is not that person's, including any left from an earlier session. Earlier versions of the app saved these copies without recording who opened them; the app deletes those at the same moments, all of them, whoever signs in. If your session expires while you have unsaved edits, the app asks you to sign in again on top of your work and keeps the copies until someone does. While you are signed in the app keeps them, because the viewer you opened one in may still be showing it; closing the viewer does not delete it. If a copy cannot be deleted at that moment, the app tries again at the next sign-out or the next sign-in by someone else. The device may also clear the app's cache folder sooner to free up storage, and deleting the app removes them. Until they are deleted iOS keeps them encrypted at rest the same way, unreadable until the first unlock after a restart, and leaves them out of iCloud and iTunes backups. To show a proposal the app hands it to a viewer app you choose, and that app may keep its own copy under its own rules.

5. Your controls

• Sign out on the device, which clears the token and the read cache as described above, and deletes the saved proposal copies. If you have unsent edits, the app tells you before it signs you out and lets you stay signed in to send them first.
• Change your password from the account screen.
• Deactivation and deletion. BidGlory accounts are created and closed by your organisation's BidGlory administrator, not by self-service, so there is no in-app "delete my account" button. To have your account closed, or to ask what personal data is held about you, contact your administrator or write to us at the address below, and we will act on the Customer's instruction. We would rather say this plainly than offer a button that does not do what its label promises.

6. How long we keep it

Business records live for as long as the Customer's instance does; the Customer decides when they are removed. Server-side records of individual device edits are kept for a bounded period after the edit and are then purged. Sign-in audit records are retained for security investigation.

7. The Android app

No BidGlory Android app has been published. This section describes what the Android build of the app does, so that the description is in place before one is offered. It is the same app as the one for iPad and iPhone, and sections 2 to 6 apply to it as written, except for the differences below.

• Your session token is kept in the app's encrypted preferences, encrypted with a key held in the Android Keystore, instead of in the iOS Keychain. As on iOS, your password is not stored on the device.
• The read cache and the outbox are kept in the app's internal storage, which Android keeps private to the app. The app does not add encryption of its own to these files. Encryption at rest comes from the device: on a device with a screen lock, Android's file-based encryption, which devices launched with Android 10 or later are required to use, keeps app-private storage unreadable until the device is unlocked for the first time after it restarts. On an older device, whether storage is encrypted depends on the device.
• Saved proposals are kept in the app's internal cache folder, which is private to the app and encrypted at rest by the device in the same way. As on iOS, the app deletes them when the device is signed out and when someone else signs in on the device. Android may also remove them sooner when it needs the space or when you use Clear cache in the app's storage settings, and uninstalling the app removes them.
• Backups. The app opts out of Android backup, and its data-extraction rules exclude all of its storage, including the read cache, the outbox and the token, from both Google cloud backup and device-to-device transfer. As on iOS, restoring or transferring onto a new phone does not carry unsent edits across.
• Connections. The app connects to BidGlory over HTTPS. Plain HTTP is allowed only in developer (Debug) builds, and only to a BidGlory server on the developer's own computer (the Android emulator's 10.0.2.2 address and localhost). That exception is not part of a release build.
• Permissions. The app asks for internet access and for the state of the network connection, which Android grants without asking you. It requests no permission that Android would ask you to grant: not the camera, location, contacts, microphone, calendar or storage.

Questions about this notice? Email support@bidglory.com. See also the licence agreement.