Privacy Policy

1Who is responsible

The controller of the personal data described in this policy is Individual Entrepreneur OLEKSANDR BONDARENKO, identification number 302312361 (Georgia), trading as DF Views at dfviews.com.

Write to us about anything in this policy at privacy@dfviews.com. Our full registration and contact details, including how to verify us in the public register, are in §16 — Operator details at the end of this document.

2What this policy covers, and what it does not

This policy explains how we handle personal data for which we decide the purposes and means — essentially, data about the people who use our administrative application: account holders, the colleagues they invite, and people who contact us.

● It does not cover personal data inside your own content. If you upload or publish material that contains personal data, you are the controller of that data and we act as your processor. That relationship is governed by the Data Processing Agreement, not by this policy.

If you are an end user who saw a 3D product presentation on somebody's website, see §9: we hold almost nothing about you, and the operator of that website is the one to contact.

● The public gallery is different, and it is ours. At dfviews.com/explore we run a gallery where customers may publish work. That gallery is our own service: we decide how it works, what is shown and what is measured, so for the author's public profile and for community activity (likes, follows, views) we are the controller and this policy — not the DPA — applies. What the work itself depicts remains the publisher's responsibility. Section 10 describes the gallery in full; read it before you publish anything there.

3What we collect, why, and on what legal basis

● We do not collect payment card details. Payments are handled by Paddle as Merchant of Record (§5). We never see or store your card number.

● The embedded viewer now measures the presentation — and this revision is the change we promised to announce. The previous version of this policy said that the viewer did not measure end users at all. That is no longer true, and rather than change it quietly we have issued a new revision and asked every customer to accept it.

What the viewer measures is the presentation, not the person looking at it. It records how long the presentation was visible on screen, whether the tab was in the foreground, how long the first frame took to appear, and how many times the visitor rotated, zoomed or opened it full screen. One message is sent when the visitor leaves the page.

● What it does not do, stated as plainly as we can: it sets no cookie; it writes nothing to the visitor's browser beyond the picture-quality step described in §4, which is saved only if the visitor changes it themselves; it does not send us the visitor's IP address, browser user-agent, or the address of the page they were on; it contains no identifier that survives the visit, and none that could be matched with the same visitor on another site or on another day. The session identifier is issued by us for a single presentation load and cannot be linked to a person.

Where we rely on legitimate interests, we have considered your interests and rights. You may object at any time (§8).

4Cookies and browser storage

In the administrative application we set one cookie:

In the public gallery (dfviews.com/explore) we set one cookie, and only if you ask us to:

● Simply browsing the gallery sets nothing. The cookie appears only after you choose to sign in there, it carries a signed token naming your account and nothing else, and it grants no permission to change anything — every action still goes through the administrative application (§10).

Both cookies are strictly necessary to provide a service you have asked for. We use no advertising, profiling or tracking cookies anywhere.

● In the embedded viewer we set no cookies, do no fingerprinting and store nothing that identifies a visitor. The viewer keeps exactly one thing on the device, and only if the visitor changes it themselves: the picture-quality step chosen with the viewer's own control, saved as a single number in localStorage so the choice survives the next visit. It contains no identifier, no reference to the product viewed and no record that a visit happened; it is never read by us and never leaves the device. It is a device preference, in the same sense as a player's volume setting, and it is set only in response to an action the visitor takes.

Nothing else is written: no sessionStorage, no other localStorage entry, no cookie. Embedding DF Views therefore adds nothing to the cookie notice on your own website.

5Who else sees the data (recipients and sub-processors)

We use a small number of providers. Each processes data only on our instructions and under a written agreement.

Paddle acts as an independent controller for the payment data it collects from you; see Paddle's own privacy policy at paddle.com.

We may also disclose personal data where we are legally required to do so, or where necessary to establish, exercise or defend legal claims. We do not sell personal data and we do not share it for advertising.

The current sub-processor list is maintained in the DPA. We will notify customers of changes before a new sub-processor starts processing.

6Where the data is, and international transfers

● Your data is stored in the European Union. All three places it rests are in the EU: object storage buckets are created with EU jurisdiction, the main database runs in Frankfurt, Germany, and the public gallery runs on its own server in Helsinki, Finland. We do not store customer data outside the EU.

▲ That is not the same as "no international transfer", and we will not pretend otherwise. We are established in Georgia, and we administer those EU-hosted systems from Georgia. Under the GDPR, access from a third country is itself a transfer. Georgia is not covered by an adequacy decision of the European Commission. So:

• For data you send us as a customer: where you are subject to the GDPR and we act as your processor, we offer the European Commission's Standard Contractual Clauses (Module Two, controller to processor), incorporated in the DPA, together with the supplementary measures described there.
• For data we control: where personal data is transferred out of the European Economic Area to us or to a sub-processor, we rely on the Standard Contractual Clauses or another transfer mechanism permitted by Chapter V of the GDPR.
• Under Georgian law: transfers of personal data out of Georgia are made in accordance with the Law of Georgia on Personal Data Protection, to countries providing appropriate safeguards or on the basis of the safeguards that law requires.

7How long we keep it

These periods are enforced automatically by a scheduled process, not by hand:

After termination we keep your content for 30 days so that you can export it, then delete it. We may retain records we are required to keep by law (for example, in relation to tax or to a legal claim) for as long as that obligation lasts.

● Closing an organisation and closing your personal sign-in are not the same thing, and we say so plainly. Deleting your organisation deletes the organisation, everything in it and its membership records, and it reaches the public gallery (§8, §10). What is retained afterwards is the person's own sign-in identity — e-mail address, authentication secrets and the record of which legal documents that person accepted — because we must be able to prove what was agreed, and because a person may still belong to another organisation. Ask us at privacy@dfviews.com and we will erase that too, except where we must keep something to comply with the law or to defend a legal claim.

● We keep proof that the deletion happened, and that proof contains no personal details. When an organisation is deleted we write a single record to our platform journal saying that it happened. It holds four things: the organisation's internal identifier, the date and time, the internal identifier — not the e-mail address — of the person who asked for it, and how much was erased, as counts of files and a number of bytes. It holds no name, no e-mail address, no IP address, no browser details and nothing whatsoever from inside the organisation; our database refuses to store that record with any of them. We keep it for 24 months, on the same footing as the rest of our platform journal, because of our legitimate interest in being able to show that we did what you asked, and in establishing or defending a legal claim (Art. 6(1)(f), Art. 17(3)(e)).

Why this record exists at all. Until we added it, deleting an organisation also deleted the only evidence that we had deleted it — the organisation's own journal went with the organisation. If you came back months later and asked "did you really erase my data, and when?", we would have had nothing to show you. A deletion that erases its own receipt protects nobody, least of all you.

● Consent records cannot be edited. The database role our application uses has no permission to update or delete rows recording your acceptance of legal documents. A correction is made by adding a new record, never by rewriting an old one. This protects you as much as it protects us.

● Backups are the honest limit of every period above. The periods in this table describe our active systems. We also keep encrypted off-site backups, on a rolling schedule of 14 daily, 8 weekly and 6 monthly copies, so data you delete — or that expires under the table above — can still exist in a backup for up to seven months after it leaves the active systems, and no longer.

Backups are isolated from ordinary use: nothing is served from them and nobody works in them. If we ever restore one after a disaster, the deletion rules above apply to the restored data again, so a restore does not quietly bring deleted data back into service.

8Your rights

Subject to the conditions in applicable law, you may:

• access the personal data we hold about you and receive a copy;
• ask us to correct inaccurate or incomplete data;
• ask us to erase data, where there is no overriding ground to keep it;
• ask us to restrict processing while a dispute about it is resolved;
• receive certain data in a portable, machine-readable format;
• object to processing based on our legitimate interests, on grounds relating to your situation;
• withdraw consent, where processing is based on consent, without affecting prior processing;
• not be subject to a decision based solely on automated processing producing legal or similarly significant effects. We do not make such decisions.

Write to privacy@dfviews.com. We answer within one month, and will tell you if we need longer because the request is complex. We may ask you to confirm your identity — through your existing account where possible, so that answering a request does not itself become a way to get at your data.

Your organisation's activity journal can also be exported by your organisation's owner directly from the application, in JSON Lines or CSV.

● Erasure reaches the public gallery too, and we say exactly how far. Closing the organisation deletes its published work cards from the gallery and — for anyone for whom it was their only organisation — the public profile, its avatar and cover files, the likes given and the follows in both directions. What we keep are notices we received and the moderation decisions we made: they justify actions already taken, the Digital Services Act requires us to be able to explain them, and we may need them to defend a legal claim (Art. 17(3) GDPR). Those records name an account that no longer exists, so the identifier in them points to nothing.

Complaints. You may complain to a supervisory authority:

• in Georgia — the State Audit Office of Georgia, which exercises the supervisory functions under the Georgian Law on Personal Data Protection (sao.ge). Write to us at privacy@dfviews.com and we will give you its current filing channel;
• in the European Economic Area — the supervisory authority of your habitual residence, place of work, or of the alleged infringement;
• in the United Kingdom — the Information Commissioner's Office.

We would appreciate the chance to address your concern first.

9If you are an end user of a customer's website

If you viewed a 3D product presentation embedded on a website:

• we set no cookies on your device. The viewer keeps exactly one thing in your browser, and only if you change it yourself: the picture-quality step you chose with the viewer's own control (§4). It carries no identifier, we never read it, and it never leaves your device;
• we do not build a profile of you and do not track you across sites;
• we do measure the presentation itself, and one message is sent to us when you leave the page. It says how long the presentation was visible, whether the tab was in the foreground, how long the first frame took to appear, how many times it was rotated, zoomed or opened full screen, how much of the presentation area itself was visible at most, and how large that area was in square CSS pixels, measured once when the viewer starts. These last two are measurements of our own viewer on that page — the size of its area and how much of that area was in view. It carries a one-time identifier that we issue for that single load and that means nothing tomorrow. It does not carry your IP address, your browser user-agent, or the address of the page you were on. There is nothing in it by which you could be recognised, here or anywhere else;
• our servers process your request technically, which necessarily involves your IP address in transit and in short-lived network logs of our infrastructure providers;
• no automatic fault report is sent to us. If the presentation fails to load, the viewer shows the failure to you and tells us nothing about it. Should that ever change, this policy will say so before it does, and the change will be a new revision.

The website operator decides what is shown to you and is the controller for their own site. Contact them first; you may also contact us at privacy@dfviews.com.

If instead you were browsing our own gallery at dfviews.com/explore, that is our service and §10 applies.

10The public gallery (dfviews.com/explore)

We run a public gallery where our customers can publish work they have made. It is part of our own service, so this section — not the DPA — governs it.

Taking part is your choice. Nothing appears in the gallery unless the person who owns the work publishes it there deliberately, and unpublishing is a single action that takes effect immediately. You do not need a gallery profile to use the rest of the Service.

● What is public, in full. Your profile page shows the @handle, display name, biography, city, links and software you chose to enter, together with your avatar and cover picture. Each published work shows its title, description, category, tags, publication date, the number of likes and views, and the name or brand displayed under it. All of this is readable by anyone, without signing in, and may be indexed by search engines and copied into link previews on other sites. A profile picture is served from an address that cannot be guessed, but it is not otherwise protected.

● Publishing anonymously hides your name, not your responsibility. If you publish a work anonymously, no name, @handle or link to a profile is shown on the page or returned by our public interface. We nevertheless record internally which account published it, because a rights holder is entitled to a response when they complain about that work. We disclose that record only where we must — to answer a legal claim, or where the law obliges us.

Likes and follows. We record which works you liked and which authors you follow. Publicly we show only totals: how many likes a work has, how many followers an author has. The lists themselves are not published. Where a like looks automated, we mark it internally, stop counting it towards ranking, and do not delete it — deleting it would tell whoever is manipulating the count that we noticed.

A cookie only if you ask for it. Browsing the gallery sets nothing in your browser. When you choose to sign in there, we place the df_view cookie described in §4: it carries a signed token naming your account, it is limited to the /explore path, it lasts an hour, and it grants no permission to change anything. Liking, following and editing all go through the administrative application, where you have a real session.

Counting a view without following you. To avoid counting a refresh as a new view, we store an pseudonymised (keyed-hash) form of the visitor's IP address together with a six-hour window. The address itself is not stored, the hash is deleted within 24 hours, and it is not used to build a profile of you or to recognise you on any other site.

Where the gallery runs. On a separate server in Helsinki, Finland (§5, §6). That machine deliberately holds none of your 3D geometry, none of your published scene files, no passwords and no payment data — only the gallery's own content: profiles, work cards, likes, follows, notices and moderation records.

Reporting content. Anyone — including people who are not our customers — can report a published work. A contact address is required so that we can tell the reporter what we decided; we keep the notice and our decision as part of the record. Decisions are taken by a person, are recorded with their grounds, and are not rewritten or deleted afterwards.

When you leave. Closing your organisation removes its published work cards from the gallery, and removes the profile, its picture files, likes and follows of anyone for whom that organisation was the only one. Notices and moderation records are kept, for the reasons given in §8.

11Security

We do not describe our defences in detail, but the following are commitments, not aspirations:

• Two factors are mandatory for every account: a one-time code by e-mail and a TOTP code.
• Secrets are never stored in usable form. TOTP secrets are encrypted; one-time codes, recovery codes and session tokens are stored only as hashes.
• Separation inside the database. The application connects with a restricted role, row-level security is enforced on customer tables, and the role used for support has no rights to read customer tables at all — it can only read purpose-built views that exclude geometry, scenes, previews and authentication secrets.
• Journals are append-only: the application role cannot update or delete audit records.
• Access to published assets requires a short-lived signed capability, not merely knowing a URL.
• We do not hold payment card data.

● What security cannot do, stated plainly. The viewer runs in your end users' browsers. Anything delivered to a browser can be read there by a determined person. We protect against casual copying, not against a skilled attacker with development tools, and we would rather say so than imply otherwise.

12Personal data breaches

If a breach occurs that is likely to result in a risk to people's rights and freedoms, we will notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, and we will inform affected customers without undue delay so that they can meet their own obligations. Our notification duties under the Law of Georgia on Personal Data Protection apply in addition.

13Representatives

Article 27 GDPR requires a controller that is not established in the Union, and that is subject to the Regulation by virtue of Article 3(2), to designate a representative in the Union. Article 13 of the Digital Services Act imposes a comparable requirement on providers offering services in the Union.

Where those requirements apply to us, we will designate a representative in a Member State, notify the competent authority, and publish the representative's name, postal address, e-mail address and telephone number here and in Terms of Service §9.8.

All contact points in this policy and in the Terms of Service are monitored and answered by us directly — privacy@dfviews.com for data-protection matters, abuse@dfviews.com for notices about illegal content. Supervisory authorities and data subjects may address us there.

14Children

The Service is offered to businesses only and is not directed at children. We do not knowingly collect personal data from children.

15Changes to this policy

Each version carries a version identifier and we record which version you accepted. For material changes we give at least 30 days' notice and ask you to accept the new version before continuing to use the administrative application. Changes required by law or to address a security risk may take effect immediately, with notice as soon as practicable.

---

Contact: privacy@dfviews.com · Individual Entrepreneur OLEKSANDR BONDARENKO, identification number 302312361, registered in Georgia; registry entry verifiable at napr.gov.ge, extract on request.

16Operator details

These are the details of the controller named in §1. They are placed here, at the end, so that the policy opens with what it does with your data rather than with our registration record — the record is a reference, not the subject of this document.