Authentication
Access to the application requires a valid identity. Backend services check it again before sensitive operations.
Trust · Living document
Security and data at Pic on Site
We explain how the application works today: what is stored, where it is processed, who can access it, and what changes when an organisation needs an Enterprise architecture.
Current standard architecture
From phone to project, step by step
A photo is not stored as an isolated item. It travels with project context and produces derived data that helps people locate and retrieve it.
- 1
Capture and upload
The web or mobile app prepares the image and thumbnails. When available, it preserves date, author, GPS and orientation data.
- 2
Identity
Firebase Authentication identifies the user. The application uses that identity to check team membership and the role within the project.
- 3
File and metadata
The image is stored in Cloud Storage. Its record, location and processing state are stored in Cloud Firestore.
- 4
Analysis and search
The image is sent to Gemini to create a description and tags. Metadata needed for retrieval is indexed in Algolia; the original image is not part of that index.
- 5
Retrieval
The application retrieves results and validates project membership again before returning photo records.
Protection
How access is controlled
Teams and roles
Projects are organised by team. Owners, administrators, editors and other collaborators receive different capabilities.
Encryption
Google Cloud encrypts stored data by default and communications use HTTPS/TLS. The standard setup uses Google-managed keys.
Rules and validation
Firestore and Storage apply rules to identity, membership, file type and size. Full deletion runs in the backend to avoid orphaned data.
AI and search
What happens when we analyse a photograph
New photographs are processed automatically with the Gemini API to produce a description and useful visual terms in several languages. Pic on Site stores the result as metadata and uses it for search and reports; it does not currently train its own model with uploaded photographs.
The production project has active billing. Under the current Gemini terms for paid services, Google does not use inputs—including images—or responses to improve its products. Google may keep limited logs for safety, abuse prevention and legal obligations. This depends on the applicable service and contract and will be reviewed if the integration changes.
Algolia receives a search index containing identifiers and relevant metadata—such as tags, author, dates or whether GPS is present—not the original photograph. The contractual location of that index is not currently included in a standard regional guarantee.
Gemini API data termsRetention and recovery
What the standard service covers today
Files
The current bucket keeps deleted objects through soft delete for 7 days. Object versioning is not enabled.
Database
Firestore replicates data within nam5 for availability. Point-in-time recovery is not currently enabled.
Accounts and projects
The application supports account deletion. Shared-project content may be retained as a project record with identity anonymised; shared ownership must be transferred or resolved first.
Commitments
The standard service does not currently publish a contractual SLA, RPO or RTO. If a project requires them, they must be defined in an Enterprise proposal.
Enterprise · By agreement
Three models, depending on who must control the infrastructure
These options are not an automatic in-app switch and are not included in the standard service. They require design, migration, compatibility validation, and a technical and contractual agreement.
Standard managed
Pic on Site operates the current shared infrastructure. This is the starting model and uses the locations documented on this page.
Managed in a selected region
A dedicated or regional environment in a supported location can be assessed. Database, files, Functions, search and AI must be reviewed together: choosing only the bucket does not provide complete data residency.
Customer-managed
Deployment into a Google Cloud/Firebase project controlled by the organisation can be assessed. The customer manages region, billing, IAM and policies; Pic on Site operational access, updates and support are agreed explicitly.
Services that may form part of an Enterprise scope
- SSO or identity federation
- specific retention and deletion policies
- data export and migration
- access logs and reviews
- DPA, security questionnaires and procurement documentation
- agreed integrations and support
Availability, regions, timing and pricing depend on scope. A commercial conversation does not mean that a model is already deployed or certified.
Shared responsibility
Infrastructure does not replace project governance
The organisation must decide what is photographed, who may access it, how long it is kept and what may be shared. Avoid capturing unnecessary personal data, confidential documents or sensitive facilities. Review members and roles when teams change, and export records that must be retained outside the service.
Ownership: uploaded content remains with the party entitled to it. Pic on Site only needs the technical licences required to host, process and display it as part of the service.
Sources and scope
How we keep this page verifiable
This description combines inspection of the current Pic on Site deployment and code with official provider documentation. The architecture may evolve; the date at the top is the latest reviewed snapshot.
Enterprise
Does your organisation have residency or control requirements?
Tell us the countries, volume, users, integrations, retention, identity and level of control expected. We will separate what is available from what requires an Enterprise project.