Privacy Policy

1. Data controller

The controller of the data collected through TrustGuest is 1Site di Antonini Umberto, VAT No. 17449421001, Via O. Respighi, Guidonia (RM). Operational channel for support and communications: assistenza.1siteweb.it.

2. What TrustGuest is

TrustGuest (TrustGuest.app) is a bilateral reputation platform for the non-hotel accommodation sector: it allows registered Hosts and Guests to publish and consult reciprocal reviews, replies and informational reports relating to stays. TrustGuest is neither a booking portal nor a payment service. Access to its functions requires registration.

3. Which personal data are processed

Based on the current operation of the application, the following data are processed:

• account email address;
• authentication data managed by the authentication service (password in encrypted form, user identifier, email confirmation);
• data received from Google when signing in with Google (Google account identifier and associated email);
• public ID assigned by the system, in the H- or G- format;
• Host or Guest role;
• reviews published and received, with rating and comment;
• replies to reviews;
• Red Flag reports associated with a review and data relating to the verification procedure (section 8);
• consent data: date and time of acceptance of the Terms, date and time of acceptance of the Privacy Policy, IP address and user-agent detected server-side at the time of acceptance; version of the Terms accepted, with date and time, IP address and user-agent detected when the “I accept” button is pressed (section 14);
• feedback and messages sent through the platform;
• any WhatsApp telephone number voluntarily entered by the user as a contact detail;
• GDPR requests submitted through the application, with their status and outcome;
• technical data strictly necessary for the operation of the service and session;
• internal statistical events in page_views, recording the event type (for example, visits or searches) and the time at which it occurred;
• sharing events share_<channel>, with the same minimised structure;
• any profile photo (avatar) voluntarily uploaded by the user, kept in the service storage and used for profile functions and previews;
• data relating to stays between Hosts and Guests: internal identifiers of the parties, check-in and check-out dates, stay status and technical data necessary to manage the relationship;
• data relating to abnormal stay events: type of event, reporting party, other party, event status, dates and times, any notes by the reporting party, any dispute notes and any administrative decision with its reasons; such content may include free text entered by the data subjects or the administration;
• data necessary to calculate the Stay Reliability indicator, based on the history of stays and documented events;
• reciprocal ratings on stays (Guest → Host and Host → Guest);
• indicators relating to the advantages/benefits provided for Hosts and Guests and the associated application requirements;
• Host accommodation data (section 9);
• external reputation data voluntarily provided by the Host (section 10);
• Community Points and related transactions (section 11);
• the text of the draft review, when the user voluntarily uses “Improve with AI” (section 12);
• data entered by the Guest in the AI Travel form and technical metadata of the Travel Plan (section 12);
• data relating to unsuccessful sign-in attempts and blocking/ban measures (section 13);
• Host Mini Site data: public link assigned by the system, any property name and unlock date (section 9);
• status of inactivity notices sent for each cycle (section 6);
• review reports submitted to the administration and their outcome (section 7);
• records of platform update communications: version, date, person confirming the communication and number of recipients (section 16);
• administrative records of platform management actions (admin_events).

Some Host data and indicators may also be displayed through the public Mini Site and the HTML Widget that can be embedded in the Host’s external website. The HTML Widget shows information from the public Mini Site and does not expose additional information.

4. How data are collected

Data are collected directly from the user at registration, acceptance of consents, publication of reviews and replies, entry of accommodation data, requests for external reputation verification, completion of the AI Travel form, submission of feedback or GDPR requests and optional entry of a contact detail. Some technical data (consent IP address and user-agent, IP address of unsuccessful sign-in attempts) are automatically detected server-side. When signing in with Google, some data originate from the authentication provider.

5. Purposes and legal bases of processing

• creation and management of the account, provision of the service and publication of content requested by the user (including accommodation data and Community Points): processing attributable to the performance of the relationship with the user;
• recording and retention of evidence of acceptance of the Terms and Privacy Policy: fulfilment of obligations to demonstrate the collection of consent;
• platform security, abuse prevention, protection against unauthorised access, management of Red Flags, moderation, management of administrative bans and recording of administrative actions: the controller’s interest in the security and proper operation of the service;
• management of feedback, support and rights-related requests: management of the data subject’s requests and related obligations;
• aggregated and minimised internal statistics on service usage: an internal technical/statistical purpose;
• optional functions activated by the user — “Improve with AI”, AI Travel and external reputation verification: processing carried out at the user’s request to provide the requested function.

Optional functions are activated at the user’s request. For security, abuse prevention, moderation and dispute management, the controller pursues the legitimate interest of protecting the reliability and proper operation of the platform, taking into account the rights and freedoms of data subjects. When a function requires data to fulfil a user request, processing takes place to the extent necessary to provide the requested function.

6. Account data

The account is identified internally by email and publicly by the ID assigned by the system. Other users can see the public ID, role and associated reputation content; the email is not publicly exposed on the platform.

Community Referral: if you register through an invitation link shared by another member, TrustGuest processes the public ID of the person who shared the link, the link between your account and theirs, the registration date and the invitation status. These data serve only to attribute the registration to the person who invited you, manage the invitation status and verify its consolidation under the service rules (referral Community Points and the symbolic Ambassador recognition at 10 confirmed referrals). They are not used for profiling, marketing or tracking and do not affect reputation metrics. If the invited person’s account is deleted, the link to their account is removed and a record of the invitation may remain without reference to the invited person; when the inviter’s account is deleted, their invitations are deleted.

Inactivity. To manage inactive accounts, TrustGuest considers the date of the last sign-in using credentials (or, if absent, the registration date) and calculates inactivity in calendar months. After 10 months without sign-ins, the account is considered inactive. Approximately 7 days beforehand, a single email notice per cycle is sent to the account address. To avoid duplicate sends, the system records, for each cycle, the notification status, number of sending attempts, dates of attempts and any technical error. Inactivity status is calculated when viewed and is not stored; a neutral inactivity indication may appear on the profile and is removed upon the next sign-in. No record of individual visits is created.

7. Reviews, replies and reputation data

Reviews contain a rating and a comment relating to a stay, under the Terms of Service rules. A review recipient may publish a reply. Reviews and replies are visible to users authorised to view the relevant profile and to the administration, and contribute to the averages shown on the profile. Content may be removed if it breaches the Terms or the law. New reviews are linked to a confirmed stay and may be published within 15 days of check-out, subject to the suspensions provided for by the service rules.

Reporting a review. A user may report to the administration a review considered non-compliant (for example, due to personal data, offensive content, rule violations, an invalid stay or manipulation). The report is managed as a moderation request and includes: the reporter’s email and public ID, message, reason, status (received, under review, retained, removed), any note and identifier of the deciding administrator, and decision date. If the review is removed, no copy is retained: the report remains as a record of its handling, without a link to the deleted review. This process is separate from the Red Flag (section 8), which is an informational report by a Host associated with a Guest’s review.

8. Red Flag

A Red Flag is an informational report that a Host can attach to a Guest’s review. It does not in itself result in the blocking, suspension or exclusion of the reported user. The procedure follows these stages:

• pending: when the report is made, the Guest concerned is informed and has 72 hours to dispute it;
• under review: if disputed, the administration examines the case and may request clarification or documentation from the parties;
• retained or removed: if no dispute is raised within the deadline, or following an administrative decision, the Red Flag is retained or removed.

Only a retained Red Flag may be made publicly visible, under the system rules, for 90 days from the confirmation date; a retained Red Flag also affects the Guest’s Stay Reliability indicator under the service rules.

Public data: the Red Flag indicator/banner on the review. Internal data (visible only to the parties involved and/or the administration): the Guest’s dispute notes, the administration’s reasons, any documentation exchanged through the support channel and internal metadata of the procedure.

9. Host accommodation data

The Host may provide their property data: Municipality, Province, maximum number of guests, type of property and availability of parking, acceptance of pets and a swimming pool (each item may also remain “not specified”). For this function, TrustGuest does not collect or store street, street number, postal code or GPS coordinates.

These data are used to display the property on the profile, for internal platform searches and for matching in the AI Travel function (section 12).

The HTML Widget allows the public information actually provided for by the Widget and Mini Site to be displayed on the Host’s external website. Embedding the Widget does not make public the user’s email address, the private URL provided for external reputation verification or other internal data not intended for public display.

Mini Site. By spending 3 Community Points, the Host may permanently unlock a public page accessible through a link composed of a random code assigned by the system, which contains no name, email or internal identifiers and does not change over time. The Mini Site shows the public information provided for by the service, including the public ID, profile photo if present, public accommodation data and public reputation indicators. The property name, if provided by the Host, is optional and may also appear in the page title and in search engine and social previews. Emails, internal identifiers, the private external reputation URL and administrative notes are not shown. The photo is served through the Mini Site link without exposing the internal storage path. When the account is deleted, the Mini Site is deleted and the link and Widget stop displaying data.

10. External reputation

The Host may voluntarily request verification of their reputation on external platforms (Booking.com, Airbnb, Google, Tripadvisor) by providing the link to their profile or listing. TrustGuest performs a manual verification through the administration.

If verification is approved, the following may be published: platform, property/listing name, verified score, number of reviews and verification date. The original URL provided by the Host remains private, is accessible only to the Host and administration for verification, and is not published. Any reason for rejection is visible only to the Host.

The request may be submitted at most once every 3 months and only if the Host has the required Community Points balance. The administration records the outcome, decision date and its own internal identifier. The 10 Community Points are spent only upon approval; no points are deducted if rejected. The provided link is not shown publicly, including on the Mini Site or Widget.

11. Community Points

Community Points are internal technical indicators of participation in the Community. They have no monetary value, cannot be converted into money, are not transferable and do not affect TrustScore, Stay Reliability or Host Service.

For each valid confirmed referral, 2 points are recorded for the inviter and 2 welcome points, once only, for the invited person. One point is recorded for: a valid completed stay, a Guest review, a reply to a review, a Guest → Host rating and a Host → Guest rating. Approval of external reputation verification and generation of a Travel Plan each require spending 10 points. Permanently unlocking the Mini Site and Widget requires spending 3 points. The system retains point transactions linked to the account.

For each transaction, the following are recorded: account concerned, change (positive or negative), activity type, internal reference to the item that generated it and date. Each transaction is recorded once only and is not modified. Ambassador recognition is symbolic, provides no benefits and is not stored: it is calculated when necessary based on confirmed referrals, and only the presence or absence of the recognition is communicated externally.

12. Artificial intelligence-based functions

“Improve with AI”. When the user voluntarily activates this function, the draft review text is transmitted to an external AI service to obtain a proposed rewording. The text may contain personal data entered by the user. The proposal is neither saved nor published automatically.

AI Travel. The Guest may request a Travel Plan by completing a form with: destination, dates, duration, number of travellers, budget range, interests, needs, preferences and any free-text notes. Free-text notes may contain data voluntarily entered by the user: please do not enter unnecessary personal data. TrustGuest uses an external AI service to process these parameters and generate the Travel Plan.

The “Improve with AI” and AI Travel functions are processed by Google Gemini models through Lovable AI Gateway. For AI Travel, the mandatory requirements indicated by the Guest (for example, capacity, type and amenities) are applied by the system before processing: AI does not decide the requirements. The 10 Community Points are spent only after the request has been validated and one revision is available at no additional cost.

Only the following are sent to the model:

• travel parameters and preferences indicated by the Guest;
• minimised data of candidate Hosts: public ID, Municipality, Province, capacity, type, accommodation features and TrustScore when available.

The following are not sent to the model: users’ internal identifiers (UUIDs), emails, first and last names, street address, GPS coordinates, telephone number, Red Flags, Community Points, external reputation URLs, administrative notes and stay event history.

Travel Plan. The Travel Plan text is not saved in the TrustGuest database: it is returned to the browser and used in the user’s session. The PDF is generated locally in the browser. Upon request, the plan may be sent to the Guest’s email through the transactional email service. To manage the benefit (point spending and available revision), TrustGuest retains only technical metadata: request key, cryptographic fingerprint of the parameters, revision status and date.

The Travel Plan is for guidance only and does not constitute an automated decision regarding the user’s status or rights. Data retention periods and terms of use at AI and email providers are governed by their respective contractual terms (section 19).

13. Sign-in security, blocks and bans

Unsuccessful sign-in attempts. For security purposes, the normalised email, IP address, number of failed attempts and time reference of any block are recorded. After three consecutive incorrect attempts, a further sign-in attempt is blocked for 60 minutes. The record is deleted upon the first successful sign-in; in any event, records older than 24 hours are deleted by daily automatic cleanup, so they may remain until the next cleanup cycle. Any records are also deleted when the account is deleted.

Blacklist and bans. For security, Community integrity and abuse prevention purposes, an account’s email may be subject to:

• a 90-day block, applied when the administration deletes an account following violations;
• a 30-day administrative ban;
• an indefinite administrative ban, as a measure of last resort.

While the measure is in effect, it is not possible to register or operate using the same email. Expired temporary blocks and bans are automatically deleted by daily cleanup once at least 24 hours have elapsed since expiry. Revoked measures remain recorded for verification purposes. Indefinite bans are reserved for the most serious cases. The corresponding record is retained to prevent new registrations in breach of the rules and to document the measure; the administration may review and revoke the block. The record is not deleted by automatic cleanup.

For each measure, the following are recorded: email, type, reason (mandatory for manual bans), expiry (absent for indefinite bans), date, identifier of the administrator imposing it and any date and author of revocation. While it is in effect, the account is signed out and cannot access, register again, publish or modify content; requests relating to GDPR rights remain possible through the channels indicated in section 24. A ban does not delete the account or previously published content. The administration may revoke a manual ban: the block ends and the revoked measure remains recorded. Indefinite bans are not deleted by automatic cleanup.

14. Consent to Terms and Privacy

Acceptance of the Terms of Service and Privacy Policy takes place through two separate, unticked checkboxes. Both are mandatory for the account to become operational, both for registration with email and password and for new users signing in with Google. When consent is collected, the system records the date and time of each acceptance, the IP address and user-agent detected server-side. Both consents are checked before the account can use the platform functions; if they are absent, the user is directed to the acceptance screen.

New versions of the Terms. When the Terms of Service are updated with a new version requiring acceptance, the user sees the new version at their next sign-in and may choose “I accept” or “I do not accept”. Only by pressing “I accept” does the system record the accepted version identifier, acceptance date and time, IP address and user-agent detected server-side. Simply opening the page, browsing or refusing does not record any acceptance. If the user refuses, the account cannot use reserved functions until the new version is accepted. The date of the first acceptance of the Terms is retained and is not overwritten.

15. Authentication through Google

The user may sign in through Google. In that case, the provider manages authentication using its own tools and transmits to TrustGuest the data necessary to identify the account. A new Google user does not obtain an operational TrustGuest account until they have accepted both documents.

16. Feedback, support and GDPR requests

Feedback messages and rights-related requests sent through the application are retained and managed by the administration, recording their status and outcome. Support may also be requested through assistenza.1siteweb.it. If the user provides a WhatsApp contact detail, it is used only for the purpose for which it was provided.

Automatic communications. TrustGuest sends service emails through the application’s transactional email service (sign-in and account management, welcome, stay events, Red Flags, GDPR requests, account deletion, inactivity notice and, upon request, Travel Plan). The account email address and data strictly necessary for the message content are used.

Platform update communications. Communications about service updates are prepared in TrustGuest and manually sent by the controller (1Site) through admin@1site.it to active users with confirmed emails and no blocking measures. For this purpose, the text and list of eligible email addresses are transferred from the administrative area to the controller’s email tool; TrustGuest does not send them. TrustGuest records only the communicated version, date, person confirming the communication and number of recipients.

17. Analytics and internal statistics

The platform records internal statistical events consisting exclusively of the event type (for example, visits, searches and social shares) and the corresponding timestamp. These events contain no user identifier, email, IP address, cookies or identifying device fingerprints. The purpose is internal statistics and technical analysis; no profiling system is used. Minimised collection is used for internal technical and statistical purposes, to understand how functions operate and identify any malfunctions. Recorded events do not include direct user identifiers or IP addresses.

There are no Google Analytics, Meta Pixel, Tag Manager or other third-party tracking or marketing tools.

18. Cookies, local storage and technical tools

• Necessary technical tools: the authentication service uses technical browser storage to maintain the user’s session. Without these tools, access to the reserved area is not possible.
• Technical cookie sidebar_state: maintains the state (open/closed) of the sidebar; duration 7 days; technical nature.
• Invitation links: if you open an invitation link, only the public ID of the person who shared it is kept in the browser until registration is completed; it is then deleted. This is not a cookie and does not record browsing.
• Internal statistics: the events described in section 17 are recorded at application level and do not use cookies or persistent identifiers.
• Third parties in authentication: during sign-in with Google, the provider may use its own cookies and tools on its own domains, under its own policies.

No profiling or marketing tools are used. As no unnecessary tracking tools are present, the platform currently displays no cookie management banner.

19. Third-party services and providers

The following are used to operate the service:

• the database, authentication, storage and backend infrastructure provided through Supabase / Lovable Cloud;
• the Lovable platform for application development and hosting;
• Google Identity, as the OAuth authentication provider for users who choose to sign in with Google;
• Lovable AI Gateway, used as intermediary infrastructure for the “Improve with AI” and AI Travel functions;
• Google Cloud / Gemini, used for AI processing of the same functions (a role separate from OAuth authentication);
• the transactional email service used by the application for system communications, inactivity notices and sending the Travel Plan requested by the Guest;
• the email service used by the controller for admin@1site.it, to manually send platform update communications;
• Google Search Console, to monitor the website’s presence on search engines;
• the external support service accessible at assistenza.1siteweb.it;
• WhatsApp/Meta, when the user voluntarily chooses to use that channel for contacts or invitations.

For AI functions, TrustGuest limits the data transmitted as described in section 12. The Lovable workspace configuration examined by the controller provides for disabling the option that allows Lovable content to be used for model training. The examined Lovable AI Gateway service documentation indicates that prompts and completions may be retained in Gateway logs for up to 90 days. This period concerns Gateway logs and must not automatically be attributed to Google Gemini or other providers, whose retention terms and any safeguards for international transfers depend on the services actually used. Data are transmitted to individual providers to the extent necessary to provide their respective functions.

20. Data retention

• account data: retained for as long as the account exists, subject to further needs or obligations;
• reviews and replies: retained according to the continued existence of the account and the service’s application rules;
• Red Flag: public visibility, if retained, for 90 days from the confirmation date; the procedure record remains linked to the review and is deleted together with it;
• stays: retained for as long as the account and application relationship exist, subject to account deletion under the rules described in section 21;
• stay events: retained under the application logic for management, verification and calculation of Stay Reliability, until deletion of the account to which they are linked;
• accommodation data: until deletion of the Host account;
• Mini Site: until deletion of the Host account;
• acceptance data for the Terms and their versions: linked to the account and deleted when it is deleted;
• inactivity notice records: linked to the account and deleted when it is deleted;
• external reputation: requests and outcomes linked to the Host account, retained until its deletion;
• Community Points: linked to the account and removed when it is deleted;
• Travel Plan: the plan text is not retained in the TrustGuest database; technical benefit metadata are retained until account deletion;
• profile photo (avatar): deleted together with the account under the current deletion procedure;
• “Improve with AI” function: the draft text and reworded proposal are not stored in the TrustGuest database; retention at AI providers is governed by their contractual terms (section 19);
• unsuccessful sign-in attempts: deleted upon the first successful sign-in or by daily automatic cleanup of records older than 24 hours, and in any event upon account deletion;
• blacklist and bans: 90-day and 30-day measures remain effective for their duration and the record is deleted by automatic cleanup once at least 24 hours have elapsed since expiry; indefinite bans and revoked measures are not deleted by automatic cleanup and are retained for security, abuse prevention and documentation of the measure;
• ordinary feedback and tickets: automatic deletion after a predefined number of days is not currently provided for; they are deleted upon account deletion under the procedure described in section 21, except for reports submitted by other users that must remain to document moderation without a link to the deleted review. GDPR requests are treated separately and minimised upon account deletion;
• administrative records (admin_events): automatic deletion is not currently provided for. The log may retain the event type, role, public H-/G- ID and event date and time even after account deletion. The public ID is a pseudonym and is not equivalent to anonymous data;
• internal statistics: scheduled automatic deletion is not currently applied.

The indications above describe the application’s current behaviour and do not constitute fixed time limits guaranteed by the software.

21. Account deletion

The user may voluntarily delete their account from the reserved area. Upon deletion, the system deletes the account and directly linked data under the current implementation, including: reviews written and received and their replies (with any linked Red Flags), linked stays, linked stay events, stay ratings, accommodation data, external reputation requests, Community Points, Travel Plan technical metadata, any records of unsuccessful sign-in attempts, the Mini Site and its public link, inactivity notice records, Terms version acceptance data, referral invitations created by the user and the profile photo (avatar), which is physically deleted from storage. Since stays and events are shared between the parties, deleting one account may cause the corresponding records to disappear also from the other party’s history, with consequent changes to associated counts and indicators. Voluntary deletion does not place the email on any blacklist.

Ordinary feedback is deleted. GDPR requests are instead minimised: the email, public ID and any telephone contact detail are removed and the message is replaced with an indication that the content has been removed; the request type, status, outcome and dates necessary to document its handling may remain. These minimised data are retained to document request handling and for any needs to protect rights, limited to what is necessary.

Deletion imposed by the administration following violations is separate: in that case, the email may be placed on a blacklist effective for 90 days, preventing new registration with the same data, as described in section 13.

22. What may remain after deletion

The following may remain even after deletion:

• administrative records in admin_events, which may retain the role, public H-/G- ID and event date and time; the public ID is a pseudonym and is not equivalent to anonymous data;
• minimised GDPR request records and any messages or tickets managed through external channels;
• any blacklist and ban records, as described in section 13;
• moderation reports already handled, without a link to the deleted review;
• any record of an invitation received through Community Referral, without a link to the deleted account: pending invitations are deleted by the automatic check, while a record of an already confirmed invitation may remain without reference to the deleted account;
• internal statistical events, which in any case contain no identifying data.

23. Data subject rights

Within the limits of applicable law, the data subject may exercise the rights of access, obtain a copy of their data, rectification, erasure, restriction of processing, objection where applicable and portability where applicable. Where processing is based on consent, consent may be withdrawn: withdrawal of mandatory consents makes it impossible to continue using the account. A complaint may also be lodged with the competent supervisory authority.

Decisions on disputed Red Flags, external reputation verification and bans are taken by the administration with human intervention; the data subject may request review or object through the channels indicated in section 24. The Travel Plan generated by AI Travel is for guidance and does not constitute an automated decision regarding the user’s status or rights. Accommodation data and the profile photo may be independently modified from the reserved area.

24. How to exercise rights

Requests may be submitted through the dedicated GDPR request function in TrustGuest, allowing the administration to manage their status and outcome. Alternatively, the following channel may be used: assistenza.1siteweb.it. The platform currently provides no automatic function for a complete data export: a copy of the data is provided after the request has been handled.

25. Security

Access to data is governed by server-side controls and database-level access rules, limiting the reading and writing of content to authorised relationships and the administration. Passwords are managed by the authentication service in encrypted form and compromised-password checking is active; repeated unsuccessful sign-in attempts are temporarily blocked (section 13). No security measure can be considered absolute.

26. Changes to this policy

This policy may be updated to reflect developments in the service or legislation. The last update date is indicated at the top of the page.

27. Contacts

1Site di Antonini Umberto — VAT No. 17449421001 — Via O. Respighi, Guidonia (RM). For any request relating to data processing: assistenza.1siteweb.it.