Frila Privacy Policy
Last updated: 10 October 2026
This policy explains how Frila (frila.me) handles personal data. Questions or requests: [email protected].
1. Who is responsible
- Frila is the controller for provider account data, for the short record kept of a closed account, for the reputation list, and for security and abuse prevention. Controller: Vid Bregar s.p. (see the Legal Notices).
- The provider is the controller for the data of their own customers (bookings, contact details, notes, screening data, conversations). Frila acts as the provider’s processor. If you are a customer, the provider you booked with is your first contact; you can also write to us and we will help.
2. What we collect and why
| Who | Data | Purpose | Legal basis (GDPR) |
|---|---|---|---|
| Provider | Email, password hash, name, username, public profile content, photos, contact links, settings, plan, last login, notification subscriptions of the provider’s devices, record of accepting the Terms and confirming the signup points | Provide the account and service | Contract (Art. 6(1)(b)) |
| Provider (closed account) | Email, username, signup date, when the Terms were accepted and the signup points confirmed, closure date; any suspension and its reason | Establish, exercise or defend legal claims | Legitimate interest (Art. 6(1)(f)) |
| Provider (closed account) | The reason the provider gave for deleting the account, stored without any link to the provider | Improve Frila | Legitimate interest (Art. 6(1)(f)) |
| Provider and customer | Technical logs, IP address (used briefly for rate limits), security events | Security, abuse prevention, debugging | Legitimate interest (Art. 6(1)(f)) |
| Customer | Name or nickname, contact (WhatsApp number, or Telegram username and user id), address if the customer gives one, age and gender if the provider asks for them, booking details, notes by the provider | Handle the booking for the provider | Provider’s basis: contract or legitimate interest |
| Customer | Screening data the provider enables: a short note, a selfie, the customer’s exact location at that moment, a social profile link, a reference, the customer’s statement that a deposit was paid | Provider’s safety and reliability checks | Provider’s legitimate interest. The customer chooses whether to send a selfie or share a location |
| Customer | Messages sent to the provider’s AI assistant on Telegram (only if the provider uses the assistant) | Generate AI answers to messages for the provider | Provider’s basis |
| Customer | Record that the privacy notice was shown (time, notice version) and the time the customer confirmed being 18 or older | Prove the notice was shown and the age confirmed | Legitimate interest (Art. 6(1)(f)) |
| Customer (rated) | Hashed contact key, ratings, predefined tags, blocks, number of completed bookings, dates (reputation list) | Safety of providers, reliability of bookings | Legitimate interest of Frila and providers (Art. 6(1)(f)) |
We do not run ID verification. We do not sell personal data. The booking form shows which details are required; without a contact detail a booking cannot be requested.
3. The reputation list
Providers can record tag-based ratings and blocks about customers they served. In the reputation list, contact details are stored only as a keyed hash (HMAC), not in readable form. (The provider’s own customer list, which Frila fills automatically from bookings, holds the contact details in readable form so the provider can use them.) Only predefined tags are used, never free text. A rating requires an accepted booking between that provider and customer. A provider can also block a customer; a block needs no booking, and it stops that customer’s booking requests with that provider only. The list also counts a customer’s completed bookings. Other providers see only totals (number of ratings, average, tag counts, number of providers who blocked, completed bookings), never who recorded them. These results are advisory; every provider decides for themselves. Ratings and blocks stay in the list after the provider who recorded them deletes their account.
If you are rated and were never a Frila user, you can ask for access, correction, or erasure, or object at [email protected]. We review each request. We may keep a severe entry where there are compelling legitimate grounds (for example a documented safety threat) and we tell you why.
4. Sources
Provider data comes from the provider. Customer data comes from the customer (booking form, messages) or from the provider. A provider can also enter a customer or a booking manually, for example where the booking was arranged by message; in that case the provider, as controller, is responsible for informing the customer. Reputation data comes from providers.
5. Who receives data (sub-processors and recipients)
| Recipient | Role | Purpose |
|---|---|---|
| Hosting provider (to be named) | Processor | Servers and database |
| OpenRouter and the upstream AI model host | Processor | Generate assistant replies. We ask OpenRouter to route only to model hosts that do not store or train on requests (and, where configured, to zero-data-retention hosts) |
| Mailjet | Processor | Transactional email from frila.me |
| Email inbox provider (to be named) | Processor | The privacy@ and legal@ inboxes |
| Browser push services (Google, Apple, Mozilla, Microsoft) | Independent services | Deliver encrypted notifications to a provider’s device; they contain no customer name or contact details |
| Other providers | Recipients | Reputation list totals only (section 3) |
| Telegram / WhatsApp (Meta) | Independent platforms | Message delivery on the channels a provider connects |
| Authorities | Recipient | Where the law requires it |
| A successor operator | Recipient | If Frila or our business is transferred to another person or company (Terms, section 20), the data needed to keep running Frila moves to it. Providers are told by email at least 15 days before |
This list will be kept current. Providers receive their own customers’ data.
6. International transfers
Some processors may be outside the EEA. Where so, we rely on adequacy decisions or Standard Contractual Clauses with additional safeguards where needed.
7. Retention
| Data | Retention |
|---|---|
| Provider account | Until the provider deletes it. An account with no login and no booking activity for 12 months gets a warning email and is deleted 30 days later unless the provider logs in. A signup whose email was never confirmed is deleted after 7 days |
| Bookings, customers, provider notes | Kept while the provider’s account exists, and deleted with it. A provider can delete a customer at any time: their details are then removed from the customer list and from past bookings, and the booking history (times, services, prices) stays without personal data |
| Screening selfies | Deleted 7 days after the booking is decided and its meeting is over (declined and cancelled bookings: 7 days after the decision); selfies never attached to a booking are deleted after 24 hours |
| Location screening | Location the customer shares is shown to the provider to decide on the booking; kept with the booking record and deleted with it |
| Assistant conversations | Message content is deleted after 90 days, and a conversation with no message for 90 days is deleted entirely. They are deleted at once when the provider deletes the customer or the account |
| Assistant token usage | Monthly totals per provider (no customer data), deleted after 13 months |
| Reputation entries | No fixed expiry. Kept while relevant to provider safety, also after the provider who recorded them deletes their account; removed on a valid request or objection. The rating provider’s identity is not disclosed to the rated person |
| Server logs | Size-limited: the oldest entries are overwritten automatically. Logs can contain technical identifiers such as email addresses and booking links; passwords and secrets are never logged |
| Notice and age confirmation records on a booking | Kept with the booking |
| Record of a closed provider account (email, username, signup date, acceptance and confirmation times, closure date, any suspension and its reason) | 5 years after the account is closed, then deleted |
| Backups | Overwritten on the normal backup cycle |
We may keep data longer where needed for legal claims or legal duties.
8. Your rights
Under GDPR you can request access, correction, erasure, restriction, portability, and object to processing based on legitimate interest. Where consent is the basis you may withdraw it at any time. Write to [email protected]; we answer within 30 days. If you are a customer of a provider, we may forward your request to them as the controller. You can also complain to the Information Commissioner of Slovenia (Informacijski pooblaščenec, ip-rs.si) or your local authority.
9. Automated decisions
Frila does not make decisions with legal or similarly significant effect about you. Screening results and reputation list information are advisory. A provider may decide to decline a booking; that is the provider’s own decision. Where a provider has blocked a customer, that customer’s booking requests with that provider are refused automatically; this follows that provider’s own choice and affects no other provider. The AI assistant replies to messages but does not decide on bookings by itself unless the provider configures it to do so; customers are told replies may come from an AI.
10. Security
We use access control, encrypted connections, hashed passwords, rate limiting, and limit the data we keep. No system is perfectly secure. We will handle breaches as the law requires, including notice to the authority within 72 hours where applicable.
11. Cookies, children and changes
Frila uses only cookies and local storage needed to run the app (login, preferences). Frila is not for people under 18: customers confirm they are 18 or older before requesting a booking (we store the time of that confirmation with the booking), and we delete data of minors that we discover. We will publish changes to this policy here and notify providers of material changes.