Privacy policy

In short

We do not store raw IP addresses of scans, we do not resolve location below country level, we use no analytics tools, and we do not sell data. What we do is set out in detail below.

This policy covers the website www.smarterqr.com, the management interface at app.smarterqr.com, and the scanning of a QR code created with SmarterQR.

Who is responsible

• Bärtschi Software
• Lochmattweg 45
• 5033 Buchs
• Schweiz

Privacy enquiries

matt@matt-b.ch

No representative in the European Union under Art. 27 GDPR and Art. 14 revFADP has been appointed at this time. Enquiries from the EU should go directly to the address above.

Two roles that must be kept apart

SmarterQR sits between two groups of people, and in law we are not the same thing to both of them.

To visitors of this website and to our customers we are the controller within the meaning of the Swiss revFADP and the GDPR: we decide what is processed and why.

To the people who scan a customer's QR code we are a processor. The controller there is the customer who had the code printed — they decide where the code leads, which form appears and where its entries go. We process the data only on their behalf and on their instructions. If you want to know what happens to the data from a particular scan, contact the operator of that code; we will help you reach them.

In practice this means: only the customer can grant access, deletion or objection regarding a scan. We are not allowed to hand over their data on our own initiative — not even to the person it concerns.

The website www.smarterqr.com

When you open this website, the data every browser transmits is processed: IP address, time, the address requested, the referring address, and browser and operating system identifiers. It sits in the web server's access logs, serves operation and defence against attacks, and is deleted after fourteen days.

We set a single cookie: smarterqr_lang remembers the language you chose so that you do not have to choose it again on every visit. It contains nothing but a language code and serves no recognition purpose.

This website has no analytics tools, no tracking pixels, no advertising networks and no social media buttons. Fonts are embedded when the site is built and served from our own server — while reading this page your browser makes no connection to Google or any other third party. That is also why we do not ask for cookie consent: there is nothing here that would require it.

The contact form transmits your name, your email address and your message to us. We process them in order to reply, and delete them automatically after 180 days — unless the enquiry leads to a contract, in which case the statutory retention periods apply.

The management interface app.smarterqr.com

Managing codes with us requires an account. Sign-in runs through our own instance of the Keycloak software at auth.tightblocks.com. It stores a name, an email address and a password hash — we do not know the password itself.

The management interface holds the data you create yourself: codes and their rules, projects, uploaded files, page content, form definitions and the names of the members of your workspace. We process them in order to provide the service to you.

Your language choice lives in your browser's storage (localStorage), not with us.

Scanning a code — what is collected

When a QR code is scanned, our service decides what happens according to the customer's rules and writes a record of the event. That record contains:

• the time
• the country the request came from — the country only
• the kind of device (phone, tablet, computer) and the operating system
• the preferred language reported by the browser
• which rule matched and where it led
• a check value derived from the IP address (see below)

The check value derived from the IP address is not an IP address. It is an HMAC-SHA256 of the address using a key that changes every day and is derived from the date. Within a single day this makes it possible to count how many distinct devices scanned a code — but the same address produces two values on two days that cannot be linked to each other. No identifiability over time arises.

We determine the country using a database held on our own server. No request goes to a third party when a code is scanned; nobody on the outside learns that a scan took place.

Scanning a code — what is deliberately not collected

The following are missing not because they have yet to be built, but because we do not want them:

• No raw IP address in the database. Only the check value described above.
• No region, no city, no postcode. QR codes are almost always scanned with a phone, and there everything below country level is unreliable — an axis you cannot trust is worse than none.
• No cookie and no identifier that would allow a device to be recognised across several codes.
• No disclosure to advertising networks, no profiling, no sale of data.

Without the customer's own data, a scan record does not reveal who did the scanning.

The cookie used for a trail

Some customers connect several codes into a trail — a route where the next code only opens once the previous one has been scanned. Only then do we set a second cookie, named after the project (sqrp12, for example).

It contains no identifier: no random number, nothing recognisable. It holds only the progress — which stations have been scanned — and a signature that prevents tampering. The service never learns who someone is from it, only that whoever carries this cookie is at step three. Nothing is stored on our server for this. The cookie is HttpOnly, Secure and SameSite=Lax, and clears itself once the trail is over.

Forms on scanned pages

A customer can show a form behind a code — feedback, a registration, an enquiry. What is entered there we store on the customer's behalf and display to them in their management interface. Which fields exist is their decision.

They can additionally specify that entries be passed on to a further system — to an address they provide (a webhook) or by email to recipients they name. Where that goes, we know only to the extent that they told us; responsibility for it is theirs.

How long entries are kept is a setting in the customer's workspace. Without a setting they are kept indefinitely, because we do not know what is in their form, and a period we invented could delete orders in the middle of a running process.

On submission we additionally check for abusive repeated entries. This uses the check value derived from the IP address described above and a field invisible to humans that only automated programs fill in.

How long we keep data

Web server access logs

14 days

Enquiries via the contact form

180 days

Scan records

according to the customer's plan, then deleted automatically; under contract as agreed

Form entries

according to the period the customer sets — indefinitely if unset

Account and contract data

for as long as the account exists, then per the statutory periods

Who receives data

We pass on personal data only as far as operation requires or the law demands. The following work for us as processors:

Hetzner Online GmbH

servers and database, Nuremberg data centre, Germany

Vercel Inc.

delivery of the website and the management interface, United States and global network

Email (invitations, notifications) is sent through a mail server we operate ourselves.

The redirect service — what happens when a printed code is scanned — runs exclusively on our own servers in Germany and knows neither Vercel nor our sign-in.

Transfers abroad

Processing takes place in Germany. From a Swiss perspective Germany is a country with adequate data protection; within the EU it is not a third country at all.

Vercel Inc. is based in the United States. That transfer relies on the European Commission's standard contractual clauses, together with the adaptations for Switzerland recognised by the FDPIC.

Legal bases

Where the GDPR applies, we rely on:

• Art. 6(1)(b) — performance of the contract with our customers and pre-contractual steps, such as replying to an enquiry.
• Art. 6(1)(f) — our legitimate interest in secure, uninterrupted operation; this covers the access logs and the defence against abusive form submissions.
• Art. 6(1)(c) — compliance with legal obligations, such as retention duties under commercial law.

Under Swiss law we process personal data on the basis of the revFADP; in the cases described, consent is not required, because the processing serves the performance of a contract or an overriding interest exists.

Your rights

You have the right to access the data we process about you, to have it corrected, to have it deleted and to have processing restricted. Where the GDPR applies, the right to data portability is added, as is the right to object to processing based on a legitimate interest. Consent you have given can be withdrawn at any time with effect for the future.

Write to matt@matt-b.ch. So that we do not give anyone else's data away, we may have to satisfy ourselves that you are who you say you are.

If your request concerns a scan or a form behind someone else's QR code, address it to the operator of that code — there we are only a processor. If you do not know who that is, write to us and we will put you in touch.

You may also complain to a supervisory authority: in Switzerland to the Federal Data Protection and Information Commissioner (FDPIC), in the EU to the authority of the country where you live.

Security

Traffic to all our addresses is encrypted with TLS. Credentials for third-party systems that customers store with us are held encrypted (AES-256-GCM). Target addresses are checked against a blocklist when saved, and calls to third-party systems cannot reach internal networks.

Nobody can promise absolute security. We align our measures with the state of the art and adapt them.

Changes

If what we process changes, this policy changes. The version published here, with the date given above, is the one that applies.