Aufmasstool

Privacy policy

The German version of this page is the authoritative one. This translation is provided for convenience; in case of any discrepancy, the German text prevails.

As at:

This privacy policy describes which personal data is processed when you use this website, the Aufmasstool app for iOS and Android and the browser version at app.aufmasstool.de, for what purpose, on what legal basis, who receives it and how long it is stored (Art. 13 DSGVO – the German name of the General Data Protection Regulation). It describes the position as it is today. Where a processing operation is prepared but not yet in operation, or where a question has not yet been resolved, that is stated expressly.

1. Controller

The controller for the processing of data within the meaning of Art. 4 Nr. 7 DSGVO is:

Tobias Bak
Im Oberdorf 13a
36399 Freiensteinau
Germany
Email: info@aufmasstool.de

No data protection officer has been appointed; the conditions of § 38 BDSG (German Federal Data Protection Act) are not met. Please address enquiries about this policy and about the exercise of your rights to the address given above.

2. Overview: where the data is held

The measurement, project and media data arises on your device and is stored there in a database. For signing in and, if you use the cloud, for synchronisation we operate a server of our own.

This server is not a third-party cloud service. It is an installation operated by us ourselves on a rented server of Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany. The server location is Germany. Hetzner provides us with the machine, the storage and the network access and is our processor to that extent; there is no contract with the maker of the server software we use, and that maker does not receive any data either.

Under Art. 28 DSGVO a data processing agreement is required for this processing. We concluded it with Hetzner Online GmbH on 02/10/2026.

Sending of emails

We send emails through a mail server of our own, which we operate ourselves at Hetzner Online GmbH in Germany. There is no further service provider for sending. This covers the messages of the sign-in service – confirmation of the email address, resetting the password, change of address –, the confirmation code on registration (section 4), the invitation to a team (section 5.3), our answer to a request concerning a measuring device, the acknowledgement of receipt of a cancellation and the contract confirmation after a purchase in the browser version and after every increase in the number of Team licences (each section 7). In the process our mail server hands the recipient's address, the subject and the content of the message to the recipient's mail server. The legal basis is that of the processing to which the message belongs; it is given in the section named in each case. Hetzner is our processor for the mail server as well; for the data processing agreement, what is stated above for the server applies.

3. Access to our servers

Server log files when this website is visited

When the website is accessed, the server software automatically records information that your browser transmits. These are in particular:

The legal basis is Art. 6 Abs. 1 lit. f DSGVO. Our legitimate interest lies in the technically flawless delivery and the security of the website. This data is not merged with other data sources, nor is it evaluated for reach measurement or advertising purposes. On the storage period see section 13.

Access by the app and by the browser version

Entries of this kind do not arise only when this website is visited. Every request the app and the browser version make to our server – signing in, synchronisation, uploading recordings, the programming interface – passes through the same chain of proxy, gateway and runtime environment and is recorded there as well, with IP address, time, address called and status message. The purpose and the legal basis correspond to those of the server log files above. Which entries the individual parts of that chain keep in detail follows their default settings. We delete the entries of the access layer, the runtime environment and the sign-in service after 30 days; whatever else the server software logs by itself, it overwrites continuously (section 13).

Cookies, fonts, embedded services

This website does not set any cookies. It loads no fonts, no scripts and no images from third-party servers; all files are held on our own server. No analytics, reach measurement or advertising service is embedded. Consent under § 25 Abs. 1 TDDDG (German Digital Services Data Protection Act) is therefore not required, and there is deliberately no consent banner.

4. Account and registration

Registering is mandatory

Without an account the app cannot be used – not offline either, and not on the free plan. If the app starts without an account, it takes you to registration and not into your data. An account is therefore kept on our server for every user, regardless of whether cloud synchronisation is switched on.

What data arises on registration

We collect an email address, a password, a display name and a local account identifier that the app generates on your device. We do not store the password in plain text. The account includes a profile with display name, email address and a note of which team was last chosen (section 5.8). Our server takes the display name and the email address in the profile automatically from the sign-in service: if you change your name in the app or confirm a new email address, the profile follows. You can therefore only change your name with a connection to our server; it then applies to your account on all devices. The profile also provides fields for company name, billing address and VAT identification number (USt-IdNr.); these fields are currently not filled in by any part of the app.

If an invite code is redeemed during registration, we store which code was redeemed by which account and when. The purpose is the establishment and performance of the user relationship; the legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Language of the account

With your account we store the language set in the app as a code (de, en, pl, es or fr). The app transmits it on registration, on every change of language while you are signed in, and once after start-up if no language is yet stored with your account. It is kept with the other account data in the sign-in service on our server. The purpose is to send you the emails for resetting your password and for confirming a new email address in this language; we do not use it for any other purpose. It is deleted together with your account (section 13). The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Agreement to the terms of use

When you register, you confirm with a tick that you accept the general terms and conditions, have taken note of this privacy policy and are at least 18 years old; without this tick we do not create an account through registration. If there is no such record for an existing account, the app asks for it after you sign in; you can then only agree with a connection to our server. As the record of your agreement we store your account identifier, the kind of agreement, the version of the terms (month and year of their date), the time and whether you agreed on registration or in response to the later request. We do not store an IP address or email address with it.

The purpose is to be able to show that you agreed, to which version of the terms, and that you confirmed your minimum age. The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest is this proof, including in legal proceedings. The record therefore remains after your account is deleted, until the end of the third calendar year after the year of deletion – as long as claims arising from the user relationship can as a rule still be asserted (§§ 195, 199 BGB, the German Civil Code; Art. 17 Abs. 3 lit. e DSGVO). After a deletion in March 2026 the record therefore remains until the end of 2029. After that a daily deletion run removes it.

Confirming the email address

If the registration form asks for a confirmation code, we send a six-digit code to the email address given; only with this code do we create the account. For this we store the email address, the code as a hash value only (not in plain text), the number of wrong entries, the times of request, expiry and use, the language of the message and, in plain text, the IP address the request comes from. A code is valid for 15 minutes. We do not accept addresses from certain providers of disposable mailboxes; for this we compare the part of the address after the @ sign with a list.

The purpose is to prove that the email address belongs to you and thus to establish the user relationship; the legal basis is Art. 6 Abs. 1 lit. b DSGVO. The IP address serves solely to fend off automated misuse of the sign-up route; to that extent the legal basis is Art. 6 Abs. 1 lit. f DSGVO, our legitimate interest is the protection of the sign-up route. An hourly deletion run removes every entry 24 hours after the request; an entry therefore remains for at most about 25 hours. Deleting an account does not remove these entries separately; they go with the same run.

Protection against bulk sign-ups. Before we send a code, the app or the browser version may solve a short calculation task on your device that our own server sets and checks. No outside service is involved, and no cookies are set. So that a solved task does not count a second time, we store a hash value of the task that contains no information about you; how often tasks and codes are requested is counted per email address and per IP address as a hash value only (limiting sign-up attempts, below). The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest is the protection of the sign-up route.

Limiting sign-up attempts

To protect the sign-up route against automated misuse, we limit how often within a time window a registration can be attempted, a confirmation code requested or checked and a calculation task fetched – counted per email address, per IP address the request comes from and per account – and likewise how often a recovery code for the second factor can be entered. For this we do not store the address or identifier itself, but only a hash value calculated from it (SHA-256), together with the start of the time window and the number of attempts. Because the hash value of an IP address can be reversed with reasonable effort, we treat it like the address itself and keep it only briefly: a daily deletion run removes every counter whose time window lies more than 48 hours in the past.

The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest is the protection of the sign-up route and of the accounts. To be distinguished from that are the access logs of our servers, through which these requests also pass (section 3), and the sign-in service's own session data.

Second factor

You can voluntarily set up a second factor for your account: an app on one of your devices that generates time-based one-time codes. The secret key needed for this is managed by the sign-in service on our server. In addition you receive ten recovery codes in case you no longer have access to that app. We store the recovery codes only as a hash value, not in plain text; for that reason we cannot show them to you again either. If a second factor is set up, the app asks for it when you sign in. If you switch the second factor off or redeem a recovery code, we remove the factor and all recovery codes; they are also removed when the account is deleted. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Invite request – this is where the IP address is stored in plain text

As long as registration is possible only with an invite code, you can request a code through the app. In doing so we store your name, your email address, your free text and the IP address the request comes from. The IP address is stored in plain text; with IPv4 addresses a hash value could be reversed within a short time and would therefore be no protection.

The sole purpose of the IP address is to limit the number of requests per origin and thereby to fend off automated misuse of the request form. The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest is the protection of the sign-up route. The address is not merged with other data and is not used to determine your location.

We delete a completed request – we have issued a code or declined the request, or an account has been created with the code – together with the IP address 90 days after it was dealt with, and a request that was never dealt with 180 days after it was received. If we issue a code, we hold it in plain text with the request only until its collection period expires. Both are handled by a daily deletion run. Invite requests bearing the email address under which an account was last held are removed when that account is deleted. On request we also delete a request earlier (section 14).

Signing in and the session

Once you have signed in, the app holds a session credential (access and refresh key) so that a restart does not require you to sign in again. On iOS and Android it is held in the app's database, in the browser in the browser's local storage (see section 5.2). The sign-in service keeps session data of its own on our server for this purpose.

App lock and sign-in with Face ID or fingerprint

In the apps for iOS and Android you can lock the app with Face ID, Touch ID, fingerprint or face unlock and have your sign-in remembered. The biometric check is carried out solely by your device’s operating system; the app only receives the result “recognised” or “not recognised”. Neither the app nor we receive any biometric features.

If you have your sign-in remembered, the app stores your email address and password in an entry in the device’s keychain that the system releases only after a successful biometric check – on iOS only while a device passcode is set, and without transfer to another device. The app’s database only holds your email address as a note that such an entry exists. When you sign in with Face ID or fingerprint, the app sends email address and password to the sign-in service on our server, as with any sign-in; nothing beyond that is transmitted to us. Signing out leaves the entry in place so that you can sign in again. It is removed when you switch the feature off, detach the device from the account or delete the account, and when the server no longer accepts the remembered password; if the device’s biometrics change, for example through a new fingerprint, the system makes the entry unusable.

The system can insert passwords saved in your password manager when you sign in. The link between the app and the web address is established by a public file on our server that contains no personal data. The browser version has neither app lock nor biometric sign-in. The legal basis is Art. 6(1)(b) GDPR.

Sign-in with Apple, Google or Microsoft

Instead of an email address and password you can sign in via “Continue with Apple”, “Continue with Google” or “Continue with Microsoft”. You then sign in with the respective provider – Apple Distribution International Ltd. (Ireland), Google Ireland Limited or Microsoft Ireland Operations Limited – and the provider sends us a confirmation with your email address, an identifier of your account with the provider and, where available, your name. If there is no account for this address yet, we create one; otherwise we link the sign-in to your existing account. With Apple you can hide your address; we then receive a forwarding address from Apple. What the provider processes when you sign in there is governed by its privacy policy; the providers process the data as independent controllers, which may involve a transfer to the United States of America.

We store the identifier with the provider and the details it transmits at sign-in (such as address and name) together with your account. For sign-in with Apple we additionally keep a key with which we revoke the access at Apple when your account is deleted; it is deleted in the process. If your account has no password, you confirm sensitive changes (setting a password, changing the address, unlocking) by signing in with the provider again or with a security code that we send to your address; of the code we only store a check value, it is valid for 15 minutes and is deleted with the next code or with the account. The legal basis is Art. 6(1)(b) GDPR.

5. Data in the app

5.1 On your device

Projects, buildings, floors, units, rooms, items, building parts, measured values, measurement sheets, billing documents, signatures, participants and media are stored in a database on your device. Photos, videos, audio recordings and 3D scans are held as files in the app's data directory. As long as cloud synchronisation is switched off, this project data does not leave your device – the account data covered in section 4 is kept on our server independently of that.

5.2 Browser version and storage on your device (§ 25 TDDDG)

In the browser version at app.aufmasstool.de the database works in main memory. So that your data survives a reload of the page, the application additionally places a copy of that database in the browser's database storage (IndexedDB). The browser's local storage (localStorage) holds the session credential of the sign-in as well as two technical markers by which several open browser windows agree on which of them may currently write; during a registration also the email address entered and the state of its confirmation, without the code itself.

This is a storing of information on your device and an accessing of it within the meaning of § 25 Abs. 1 TDDDG. We expressly rely on the exemption in § 25 Abs. 2 Nr. 2 TDDDG: both are strictly necessary in order to provide the service expressly requested by you at all. Without the session credential you would be signed out after every reload; without the copy your measurements would be lost after every reload. We do not obtain consent for this, because the law does not require it in this case. Nothing is stored on your device for analytics, reach measurement or advertising purposes.

You can delete these stores at any time via the settings of your browser for this address. After that the measurements held in the browser are lost, unless they had been synchronised to the cloud.

5.3 Cloud synchronisation

If the cloud is switched on for your account, the project data is reconciled with our server. What is transferred in the process are the projects including the client's name and the address of the property, stairwells with an address of their own, floors, units, rooms, items, building parts, items of the bill of quantities, measurement sheets, billing documents, signatures (section 5.9), project participants, the change history of the measured values and of the building components, the deletion operations of the recycle bin (section 13), the master data of your company (including address, contact person, telephone, email, tax number, bank details, logo) as well as the administrative details of your media.

Company logo. If owners or administrators of a team save a logo in the company profile, the app uploads it as an image file to the non-public file storage on our server, into the folder holding this team's company data; the company master data refers to this file. All members of the team can read it, including members who may only read, irrespective of the “Photos and media” switch. The team's devices take over a changed logo at the next synchronisation, and our service for jobs of the programming interface inserts it into a PDF requested there (section 8). If you replace or remove the logo, the company master data no longer refers to the old file; the old file itself remains in the file storage until the team is deleted (section 13). The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Access by other customer accounts to this data is restricted on the server side to the members of your team. In the team's member list every member who may edit data sees the role and the display name of the other members and which projects are assigned to them; only the owners and administrators of the team see the email addresses of the other members, everyone else sees only their own. Members with the “Read-only” role see only their own row in the member list, plus the display names of the team's owners; the same applies if they retrieve the memberships directly through our data interface. Our own access through the administration portal is unaffected by that; it is described in section 9. The legal basis is Art. 6 Abs. 1 lit. b DSGVO (performance of the contract of use).

So that document numbers are not issued twice even across several devices of one company, in cloud operation the app reserves blocks of document numbers on our server for owners and administrators when it reconciles. For this we store the team, the number series, the year, the reserved number range, the point in time and an identifier of this installation that the app generates once at random. No reference to your account is stored in the process. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

The deletion operations of the recycle bin, which are reconciled as well, carry the same identifier of the installation. This lets the recycle bin show whether an entry was deleted on this device or on another one. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

If several people work in one team, we additionally record the events of that collaboration: that a project has been assigned to you or withdrawn from you again, that your role has changed or that your membership has ended – each with time, team, project name and the person acting. The purpose is that your device learns of this even if it was not connected at the time; the legal basis is Art. 6 Abs. 1 lit. b DSGVO. On the storage period see section 13.

Permissions for members who only read. For every member with the “Read-only” role, the owners and administrators of the team use four switches to decide whether that member may see prices and documents, photos and media, and measurement sheets of the projects they see in the team, and whether the app allows them to export. For this we store the state of the four switches for each membership; it stays as it is when the role changes. If a switch changes, we record this, like a change of role, as an event of the collaboration, so that the person's device learns of the new permissions. By default, “Prices and documents” is off and the other three switches are on. What a switch excludes, our server does not release to the person: without “Prices and documents” no billing documents, no prices of the items of the bill of quantities, no signatures under billing documents and no recycle bin entries containing billing documents; without “Photos and media” no photos, videos and audio recordings and no files in the file storage other than the company data of the business, such as the logo, and no recycle bin entries containing media; without “Measurement sheets” no measurement sheets, no signatures under them and no recycle bin entries containing measurement sheets. “Export allowed” only takes effect in the app. What a device had already loaded before a switch was turned off is only removed by a version of the app that knows the switches; older versions of the app do not remove it. Regardless of the switches, members with the “Read-only” role see no webhook targets and no number series for billing documents, and they cannot make requests concerning measuring devices. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Team licence in the member list. To the owners and administrators of a team we show in the member list, for every member, whether they have a Team licence and of which kind – their own, one assigned to them, a suspended one or none –, and for members with the “Read-only” role the state of their four switches. We show the display name of the buyer of an assigned licence only if the buyer is themselves an owner or administrator of that team. The purpose is that the team management can see who is able to edit data in the team; the legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Invitation to a team by email. If, as the owner or an administrator of a team, you invite a person, we store the invited email address, the intended role, the invitation code, its expiry date, your account as the inviting one, the language of the invitation and whether and when it was sent successfully. We send the invitation through our email dispatch (section 2) to the invited address – even if the person does not yet have an account with us. The email names the team, the role, the invitation code, its expiry date and your email address as that of the inviting person; replies to the email go to your address. The legal basis is Art. 6 Abs. 1 lit. b DSGVO for the inviting team and Art. 6 Abs. 1 lit. f DSGVO towards the invited person: the legitimate interest of the inviting company and our own lies in inviting the person to work together at the company's request. On the storage period see section 13.

If a Leica DISTO is connected via Bluetooth, the app stores the Bluetooth identifier of that measuring device together with the measured value taken over and transmits it to the cloud as well. This is the identifier of the measuring device, not an identifier of your phone and not an advertising identifier.

5.4 Third-party data in your projects – our role

In your projects you regularly process data of other people: clients, invoice recipients, contacts on the building site. This includes name, company, address, country, email address, telephone number, USt-IdNr., Leitweg-ID, customer number and your notes; in the billing documents additionally the name and address of the invoice recipient.

For this data you are the controller and we are your processor under Art. 28 DSGVO. For your own account, plan and billing data, by contrast, we are the controller. A data processing agreement is required for this. For team and cloud customers it is in preparation and not yet available. Hetzner Online GmbH is our sub-processor in this relationship.

5.5 Camera, microphone, photos, videos and audio recordings

For measuring walls and rooms (on iOS with LiDAR, ARKit and RoomPlan, on Android with ARCore), for reference photos and for construction documentation the app accesses the camera. For spoken notes and for the sound of video recordings it accesses the microphone; the corresponding permissions are requested on iOS and on Android and you can refuse them. In the browser version your browser asks for your permission when you take a photo or video with the camera – the microphone only when a video recording starts – or start an audio recording; there too you can refuse access, and a video is then recorded without sound. The browser version does not measure with the camera: there you choose a photo for measuring with a reference through your browser's file dialogue. Audio recordings are a media type of their own alongside photo and video. Optionally you can attach existing photos and videos from your device's media library.

On Android, the augmented-reality measuring modes – distance, height from floor to ceiling, area, item, volume and the guided room outline – as well as the photo with depth map in the photo documentation use Google Play Services for AR (ARCore) of Google LLC, provided they are installed on your device. So that the app can show which of these modes your device supports, it also checks when the item list is opened whether ARCore is available on your device and – if you have already allowed the app to use the camera – whether it supplies depth images; this check runs through Google Play Services. Measuring on a photo with a reference works without ARCore. Google is responsible for these services; Google's terms and privacy policy apply.

If the cloud is switched on for your account, every recording is uploaded by itself – photos, videos and audio recordings. This happens automatically in the background and not only when a button is pressed. The files are then held in a non-public file store on our server, under a path carrying the identifier of your team, and are readable by the members of that team. The earlier statement that recordings were “not automatically transmitted to us” described the position before cloud synchronisation and has been removed without replacement.

Together with the file we store the file name, file type, size, time of capture, duration, dimensions, title, note, sort order, a small preview image and any drawings made on the image. A photo with a depth map comes with the depth map as a file of its own; it is stored and uploaded together with the photo.

Limits for recordings. Photos over 25 MB, videos over 3 minutes or over 250 MB and audio recordings over 60 minutes are not accepted by the app: it rejects them when they are attached, states the reason and does not store them. If the device or browser cannot read the length of a video, the app only checks its size. A recording of your own that exceeds a limit is therefore lost. The app stops an audio recording by itself at 60 minutes and stores it. A media file over 250 MB that is already on the device is not uploaded by the app; it stays on that device only. How much space the recordings take up is calculated by the app on the device from the file sizes and their entries; nothing is sent to our server for this.

Files are uploaded through a time-limited address of our file storage that the app requests with your sign-in; in individual cases, for example with an older version of the file storage, the app uploads the file directly with your sign-in. Files are downloaded through a time-limited address that the app requests in the same way and that is valid for 60 seconds. When downloading, the same read permissions apply as for the other data of your team, including the “Photos and media” switch for members who only read (section 5.3).

5.6 Location data and EXIF data in photos

The app does not read the location of your device. On Android 11 and older versions, however, the operating system requires the permission for precise location in order to search for Bluetooth devices; there the app therefore requests it when you search for a measuring device, and uses it solely for that search. From Android 12 the app requests only the Bluetooth permissions, expressly without derivation of location. On iOS and in the browser version the app does not ask for the location.

Photos, however, frequently contain EXIF data that the device itself writes into them. Of that, only the time of capture and, indirectly, the image orientation are evaluated. When it is stored, the image file is copied byte for byte and not re-encoded, and the app does not remove any EXIF data. If a photo contains a GPS block – because your device is set up that way – it is therefore retained and, with the cloud switched on, uploaded along with the file. Whether your device writes coordinates into photos is decided by the operating system and your device settings; you can check this in the camera and privacy settings of your device.

5.7 Error reports

From the app and the browser version only with your consent. Under Settings › Error reports you can switch on that the app sends a technical report to our server when an unexpected error occurs; the default is off. The report contains the type and text of the error message, the technical call trace with function and screen names, the point in time, the version of the app and of the local database, the operating system and its version, the device type (phone, tablet or computer), the name of the screen last opened and whether a cloud sign-in exists (yes or no only). It contains no identifier of your account, your team or your device, and our server does not read your IP address when receiving it – apart from the access logs under section 3. Before sending, the app removes from the text of the error message whatever can be recognised as a pattern, for example email addresses, amounts, measured values, bank details, identifiers, file paths and postcodes with a town. It cannot be ruled out entirely that a name standing in the middle of a sentence without such a pattern remains.

The legal basis is your consent under Art. 6 Abs. 1 lit. a DSGVO and § 25 Abs. 1 TDDDG. You can withdraw it at any time with effect for the future at the same switch; reports not yet transmitted are discarded in that case. The app stores the consent on the device or in the browser, not against your account.

From our server services without consent. If one of the services on our server with which the app and the browser version work fails with an internal error, it creates an error report itself: point in time, type of error, name of the service, the error message and the technical call trace. This report, too, contains no identifier of your account, your team or your device. Before it is stored, the error message is cleaned by the same rules and additionally of access credentials and IPv4 addresses; a residue of personal reference cannot be ruled out entirely here either. The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest lies in detecting and remedying disruptions of the service.

Both kinds of report are held on our server, are accessible only to us in the administration portal and are deleted 90 days after receipt (section 13). Independently of that, Expo's update module passes the error message of a serious error at start-up on to Expo (section 6).

5.8 Switching teams, moving projects and plan limits in a team

Which team a device works in. If your account belongs to several teams, a device with the cloud switched on always works in one of them. To show you the choice, the app reads from our server your own memberships including the role and the names of those teams. On the profile of your account we note which team was last chosen; our server sets the same note when you join a team or create one, and we can set it as the operator (section 9). It serves to ensure that switching the cloud on later as a rule ends up in that team. “Create another team” creates on our server a team with the name entered, owned by your account; “Join with code” redeems an invitation (section 5.3).

Switching teams. Switching to another team is only possible with a connection to our server. Beforehand, the app synchronises the device with the previous team. It then removes the data of the previous team from the device’s database – the projects together with everything attached to them, and the company master data of that team –; on our server they are kept. Projects that you created yourself as a member with the “Read-only” role stay on the device. If anything would be lost in the process – changes not yet uploaded, photos, videos and audio recordings, entries set aside on the change to the “Measuring” role, open entries of the conflict list, or room scans held only on the device –, the app asks beforehand and states the number; if this cannot be counted in full, it asks as well. Removal only takes place after your confirmation. On phones and tablets the app creates a backup of the whole database on the device before removing anything, without photos, videos and audio recordings; if it cannot be created, the app does not switch. Of its backups, the app keeps the seven most recent on the device. The browser version has no such backup.

Until a switch has been completed, a note is held on the device with your account identifier, the identifiers of both teams, the time and the state of the switch; until then the device does not synchronise. The app continues an interrupted switch at the next start with a connection, or discards it. If the app needs your consent for this or cannot read the note, it shows this at the top of the Team screen; it discards an unreadable note only on your decision. If you discard an unreadable note there, the app fetches the data of your team from our server again in full at the next synchronisation. Requests for a measuring device that wait on the device for a connection (section 7) carry the identifier of the team in which you made them and go to that team only; requests from an older version of the app without this identifier go to the team in which the device next sends them.

Company details per team. The company details the app holds on the device – name, address, tax and bank details, logo and more – are set aside on a switch under the identifier of the previous team on the device and brought back on a switch back to that team; in the new team, its own company details apply. They are set aside on the device only. They are deleted when you delete your account and do not keep the data on the device (section 13).

Switching the cloud on. If, when switching the cloud on, you choose a team your account already belongs to, create a new one or join a team with a code, and data of another of your teams is held on the device, the app removes it from the device’s database as on a switch and sets the company details aside in the same way; on our server the data are kept. If anything would be lost in the process, it asks beforehand and states the number, otherwise not. On phones and tablets it only removes data if the backup succeeded that the app creates before every switching on of the cloud; if that backup fails, switching on is aborted without removing anything. In the browser version the app removes the data without a backup.

Moving a project to another team. As the operator, we can use our administration portal (section 9) to assign a project, together with everything attached to it including the project participants, to another team. After that, the members of that team see it according to their roles, and the releasing team no longer does. So that the devices of the releasing team learn of this, we record a departure notice – project identifier, project name, releasing team, kind and time, without the new team – that only members of the releasing team can read. A device with a current version of the app reads it during synchronisation, stores it in its database together with the number of changes and recordings not yet uploaded at that point, and removes the project with everything attached to it from its database; nothing is sent to our server in the process. On phones and tablets the app first creates a backup of the whole database on the device, without photos, videos and audio recordings. In the browser version it only removes the project once you have started the download of a backup through the notice in the list of buildings; the same applies on phones and tablets if the backup could not be created there. If you only have read access in the giving team, the browser version removes the project without a backup as soon as you choose “Remove project” in the notice. The app removes the media files of the project on phones and tablets later when it tidies up its storage; in the browser version they stay in the browser’s storage until you clear it (section 5.2). An older version of the app does not read the notice and keeps the project. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

Plan limits in a team. When uploading and for some team functions – inviting, requests for measuring devices, a writing role for a member who so far only reads, creating a further team of your own and sharing a project with a member – our server checks whether the plan covers them. As long as it only counts and does not reject, we record per team, account, reason and area when such an action went beyond the plan for the first and for the last time, and how often. The purpose is to estimate whom enforcing the plan limits would affect; the legal basis is Art. 6 Abs. 1 lit. f DSGVO. Only we can see this count, in the administration portal; it is deleted together with your account or with the team (section 13).

5.9 Signatures on measurement sheets and billing documents

An approved measurement sheet and an issued billing document can be signed in the app – by your client or their site management, for example, with a finger, a stylus or the mouse. For this we store the stroke image of the signature, the name, role and place of the signing person as entered, the time, the type and identifier of the signed measurement sheet or billing document, a checksum (SHA-256) of its content at the moment of signing and the identifier of the installation on which it was signed (section 5.3). The checksum makes it possible to recognise later whether the document was changed after signing. This is a simple electronic signature.

The signatures are held in the database of the device on which they were signed. If the cloud is switched on, they are reconciled with our server and reach the devices of the members of your team who may see the signed measurement sheet or billing document – with the same read permissions as the document itself (section 5.3). In the PDF of a billing document and in the PDF report on a project, the signatures appear with stroke image, name, role, place, time and checksum; in addition the app attaches the verification extract of the signed document together with its checksum to the PDF file. A PDF created through the programming interface contains no signatures.

The purpose is to prove that the signing person confirmed the state of the measurement sheet or billing document. If someone other than you signs, their details are third-party data in your projects: you are the controller, we process them on your behalf (section 5.4), and you determine the legal basis with respect to that person – for example the performance of your contract with them (Art. 6 Abs. 1 lit. b DSGVO) or your legitimate interest in the proof (Art. 6 Abs. 1 lit. f DSGVO). For your own signature the legal basis is Art. 6 Abs. 1 lit. b DSGVO. For the storage period see section 13.

5.10 Storing exports on a WebDAV server

In the iOS and Android apps, from the Pro plan onwards, you can store a generated export file directly on a WebDAV server, such as a Nextcloud, instead of sharing it. You determine the server: the app sends the file – depending on the format with project, measurement, billing or photo data – over an encrypted connection to the address you enter and signs in there with your user name and password in every request; to check the access and choose a folder, it retrieves the folder list there. Nothing passes through our server in the process. The recipient is the operator of the server you have chosen; the transfer takes place on your instructions, and you are responsible for choosing the server and for its security.

The app stores the address and user name in its database on the device, and the password in the device's keychain. Neither goes into the backups or into the data export of the app, and neither is reconciled with our server. “Remove access” deletes both, as does deleting your account if you do not keep the data on the device (section 13). This target does not exist in the browser version. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

6. Requests to third parties when the app starts

The app triggers two requests when it starts, without any action on your part. They are named here because the IP address of your device is transmitted to a third party in the process.

The legal basis for both requests is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest lies in being able to deliver bug fixes and security updates. Both services are provided by companies established in the United States of America, so that a transfer to a third country within the meaning of Art. 44 ff. DSGVO is to be assumed. Apple is a controller in its own right for its lookup service. For Expo's update service we have not yet finally clarified whether Expo acts on our behalf or on its own responsibility in doing so, and on which safeguard under Art. 44 ff. DSGVO the transfer is based. We therefore cannot name a contract with Expo on this, standard contractual clauses or a certification here; we will add this as soon as it has been clarified. If you wish to avoid the requests, you can use the browser version at app.aufmasstool.de – neither of the two requests takes place there.

7. Purchase, plans and unlocking

We unlock chargeable plans for your account on the server side. For this we store against your account the plan, the period of validity, the origin of the entitlement and the identifiers of the underlying transaction. For a trial period we additionally record when it began, which plan it applies to and whether, according to the app, it was started in the browser version or in the desktop version; these details are deliberately not reset, so that a trial period cannot be taken up more than once. The trial period can be started in the browser version; the iOS and Android apps do not offer it.

On the Team plan you can also request support for new measuring devices from within the app. What is stored in that case is the device designation, your note, the team, the point in time, the language of the app and your account as the submitting one. If we answer it, we additionally record the answer, its point in time and the person answering, and as a rule we also send the answer by email to the address of your account, in the language in which you made the request (section 2). If a request cannot be sent – with no connection, for instance – it remains stored on your device and does not reach us. The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

In the app for iOS, purchase through Apple's App Store is built. Payment is handled by Apple in that case; we do not receive any payment data such as card numbers. For the purchase the app transmits to Apple an identifier generated at random for each installation – expressly not your account identifier and no personal data. Apple transmits to us details of the purchase and of its further course, for example on renewal or cancellation; we check the receipt signed by Apple on our own server. Apple's privacy provisions apply in addition.

In the app for Android, purchase through Google Play is built. Payment is handled by Google through Google Play in that case; we do not receive any payment data. When you purchase, the app passes to Google, as an obfuscated account identifier, the SHA-256 hash value of your user identifier – not the identifier itself, not your email address and not your name. After the purchase the app sends our server the purchase token, the product identifier and the package name of the app. With these our server queries the state of the purchase from the Google Play Developer API and receives back the product, the term, the state of the subscription, whether it is a test purchase, and the obfuscated account identifier; we assign the purchase to your account only if this identifier matches your account. In addition, Google sends our server real-time notifications about your subscription through Google Cloud Pub/Sub, for example about renewal, cancellation or refund; we then query the state again. For the subscription we store the product, the plan, the expiry date, the environment (test or live), the original purchase token as the identifier of the transaction and the type of the last notification. Google's privacy provisions apply in addition.

Besides that, our system knows routes that manage without a purchase: we can unlock a plan by hand (in which case we store the reason for the unlocking), and you can redeem a voucher code in the browser version (below, “Vouchers”). In addition, you can buy in the browser version through Stripe (below).

The legal basis is Art. 6 Abs. 1 lit. b DSGVO, unless stated otherwise below. The delivery of the app itself takes place through the App Store of Apple Inc. or through Google Play of Google Ireland Limited; these companies are controllers in their own right for the processing in their stores, and we do not of ourselves learn who has downloaded the app.

Team licences for employees

A buyer can acquire Team licences for employees and distribute them to other people. For the person who holds it, such a licence works like a Team plan of their own. They are bought in the browser version through Stripe (below). For each licence we store the buyer's account, the account of the person who holds it, the time of the assignment and who made it, and the time of a release and who made it. If the buyer issues a licence as a code, we hold the code only as a hash value, not in plain text; we show it in plain text to the buyer alone, once, when it is issued. Such a code is redeemed through the same field as a voucher (below). We do not delete a released licence; its entry remains as the record of who worked in which period at whose expense. If the person who holds or held a licence deletes their account, we delete these entries with it.

Assignment by email address. If the buyer assigns a licence to an email address, we store the address as entered, in lower case. The assignment is at first a reservation. When an account with this confirmed address next retrieves its plan from our server – for example when the app starts or on sign-in – and does not hold another licence, the app asks whether it accepts the licence; for this we show the buyer's company name or, if none is stored, their display name. The licence only takes effect once it has been accepted. We do not send any message to the address. The answer to an assignment is the same whether or not an account exists for the address, and until the person answers, the buyer sees only the reservation. If the person accepts, the buyer sees their display name in their overview (below) and can tell from it that an account exists for the address; if the person declines, the licence becomes free again. We delete the address entered as soon as the reservation has been accepted, declined or released. If it has not been accepted 90 days after the assignment, a daily deletion run releases the licence and deletes the address – with the first run after the 90 days have passed (section 13).

Who sees what. For each of their open licences the buyer sees whether it is assigned to an account, an address or a code, the address they entered (only while a reservation is open), the display name of the person who holds the licence (only if an account holds it, so for a reservation only after acceptance), the point in time and whether the licence is in effect or suspended. The buyer does not see the sign-in address of a person who has redeemed a code. A person who holds a licence sees only their own assignment, without details of the buyer, and can release it themselves. In our administration portal we see, for each buyer, their email address and the numbers of their licences, but no codes.

Suspension. If more licences have been given out than the buyer pays for – after a payment default, for example, or after the buyer has reduced their number –, the licences given out last are suspended; codes not yet redeemed and reservations count as well. A suspended licence gives no plan; if the paid number rises again, it takes effect again of its own accord. No data is deleted in the process. If the buyer's account is deleted, all licences they gave out are suspended, and the daily deletion run releases reservations not yet accepted, together with the address; if the account of a person who holds a licence is deleted, their entry is dropped and the licence becomes free.

So that addresses cannot be tried out on a large scale through the assignment, we accept at most 100 assignments and codes per buyer account per hour. For this we store not the account identifier itself but only a hash value (SHA-256) calculated from it, together with the start of the time window and the number of attempts; a daily deletion run removes every counter whose time window lies more than 48 hours in the past.

The legal basis is Art. 6 Abs. 1 lit. b DSGVO – towards the buyer the contract on the licences, towards the person who holds a licence the contract of use. For the address entered for a person who does not yet hold the licence, and for limiting the assignments, the legal basis is Art. 6 Abs. 1 lit. f DSGVO: the legitimate interest of the buyer and our own lies in passing the licence to that person at the buyer's request and in protecting the assignment against misuse. On the storage period see section 13.

Purchase in the browser version through Stripe

In the browser version you can buy a plan or Team licences through the payment service provider Stripe. The following applies:

Vouchers

In the browser version you can redeem a voucher code in your profile under “Redeem voucher”; the apps for iOS and Android do not have this field. We hold codes that have been issued only as a hash value, not in plain text; we do not store the code you enter. If the redemption succeeds, we store which voucher was redeemed by which account and when, together with the plan unlocked and the end of the unlocking. The code of a Team licence is redeemed through the same field; if that succeeds, we assign the licence to your account (above). The legal basis is Art. 6 Abs. 1 lit. b DSGVO.

So that codes cannot be guessed by trial and error, we accept at most ten attempts per account per hour. For this we store not the account identifier itself but only a hash value (SHA-256) calculated from it, together with the start of the time window and the number of attempts; a daily deletion run removes every counter whose time window lies more than 48 hours in the past. The legal basis is Art. 6 Abs. 1 lit. f DSGVO; our legitimate interest is protecting the vouchers against misuse.

Cancellation route

Contracts that you have concluded directly with us you can cancel through the page Cancel contracts; it leads to a form in the browser version that you can use without signing in. The purpose is to receive, confirm and carry out your cancellation under § 312k BGB. For this we store your name, your email address, your voluntary details of the contract, the type of cancellation (ordinary or extraordinary), for an extraordinary cancellation the reason, the point in time requested, the language, the date and time of receipt and the state of processing. If you are signed in at the time, we additionally store your account identifier.

If you cancel while signed in, ordinarily, with effect from the earliest possible date, and you have exactly one running subscription through Stripe, we cancel it there automatically with effect from the end of the term and store the identifier of the subscription and the end date. Every other cancellation we deal with ourselves; in doing so we record when and by whom it was dealt with, together with a note. We send an acknowledgement of receipt with the content of your declaration immediately to the email address given (section 2) and record whether it went out.

To protect the cancellation route against mass submissions, we accept at most three cancellations per hour per email address and at most five per hour per IP address from which the request comes. For this we store not the addresses themselves but only a hash value (SHA-256) calculated from them, together with the start of the time window and the number of submissions; a daily deletion run removes every counter whose time window lies more than 48 hours in the past.

The legal basis is Art. 6 Abs. 1 lit. c DSGVO in conjunction with § 312k BGB and, insofar as the ending of your contract is concerned, Art. 6 Abs. 1 lit. b DSGVO; for limiting the submissions Art. 6 Abs. 1 lit. f DSGVO, our legitimate interest being the protection of the cancellation route against misuse. We keep cancellations received as a record, including beyond the deletion of your account (section 13).

8. Programming interface and webhooks

On the chargeable plans you can use a programming interface (API) and set up webhooks in order to pass your data on to a system of your own – your enterprise resource planning system, for example. The following applies here:

Export jobs through the interface

Through the programming interface your own system can start the export of a project as a file – as a CSV, JSON, XML, Excel or PDF file or in the formats GAEB X31 and REB DA11. For this we store a job with team, project, the requested format and its settings (row kind, language), the state of the job, where applicable an error code and error text, the file name, which we form from the project name and the day, storage location and size of the file, notes on the file, the times and the identifier of the key used. The file is produced by a service of our own on our server at Hetzner Online GmbH (section 2): for this it reads the data of the project – structure, items, building parts, items of the bill of quantities and the change history of the measured values – and stores the file in a non-public area of our file storage. For a PDF file it additionally reads your team's company details – including name, address, contact, tax and bank details and the accent colour – and the company logo from the file storage (section 5.3); it does not include project participants, photos or signatures in the PDF. We only create an address for downloading when your system queries the finished job, and only as long as the project is in the team that placed the job. It is valid for at most 24 hours, never beyond the retention of the file; an address already issued remains valid until it expires, even if the project has since been assigned to another team. We do not store the address. When a job is finished, we report this on request through a webhook – with job, project and format, without the file and without an address.

Errors of this service do not go into the error reports from section 5.7 but only into the log of the service on our server. It contains identifiers, format, duration, size and error code, but no content such as project names, addresses or prices; how long it is retained depends on the default setting of the server software, and we have not so far laid down a period of our own. The legal basis is Art. 6 Abs. 1 lit. b DSGVO; for third-party data in your projects, section 5.4 applies. How long job and file are retained is set out in section 13.

Import jobs through the interface

Through the programming interface your own system can also have a bill of quantities read in – as a GAEB, Excel or CSV file –, as a new project or appended to an existing project of your team. For this we store a job as for an export: team, project, the kind of import, the file name stated by your system, the information on the decimal separator, the state of the job, where applicable an error code and notes, the times and the identifier of the key used. We place the uploaded file – it may contain project names, addresses and prices – in a non-public area of our file storage until the job is completed. Our service on our server (above) reads it, creates the items of the bill of quantities – for a new project also the project – in your team and deletes the file as soon as the job has finally been completed or has finally failed. The items created then belong to your team's data and reach its devices at synchronisation (section 5.3). When the job is finished, we report this on request through a webhook. The legal basis is Art. 6 Abs. 1 lit. b DSGVO; for third-party data, section 5.4 applies. How long job and file are retained is set out in section 13.

9. Access by the operator

For operation and support we run an administration portal of our own to which only we have access. It requires a sign-in with a second factor and can additionally be restricted to particular network addresses.

In the role with the widest rights, accounts, teams, plans and unlockings can be managed there and project, item and billing data can be viewed – including the complete details of your project participants (name, company, address, email address, telephone number, USt-IdNr., Leitweg-ID, note). The restricted role for support alone has no access whatsoever to this data view: every call is rejected there, not only the one for billing data.

What is logged is not every look, but the opening of a single record – of a project, of an item and of a billing document. What is not logged is paging through the lists and calling up the remaining views; that includes rooms, measurement sheets, items of the bill of quantities, the company master data, the file list and the list of your project participants. The reason is that a log recording every change of page would cease to be evaluable after a short time; we name it here nonetheless, so that nobody infers more from the log than it contains.

What is also logged is every rejected access attempt; in that case the IP address is stored as well. This audit log is technically immutable. The legal basis for the access is Art. 6 Abs. 1 lit. b and lit. f DSGVO (provision and support of the service, investigation of misuse and of errors), for the log Art. 6 Abs. 1 lit. f DSGVO in conjunction with Art. 5 Abs. 2 DSGVO (accountability).

In addition, people with administrative access work on the server on maintenance and troubleshooting; in doing so, server and database output may be viewed which can contain email and IP addresses. These accesses are limited to the necessary circle of people and are bound by our instructions.

10. Backups

We back up the database and the file store regularly. Every backup is encrypted before it leaves the server and moved to a backup storage of Hetzner Online GmbH in its data centre in Falkenstein, Germany. The 14 most recent states are kept on the server and the 30 most recent in the backup storage, counted separately for database and file store; older states are deleted after every successful run. If the backup runs once a day as intended, this corresponds to about 14 and 30 days respectively. The legal basis is Art. 6 Abs. 1 lit. f DSGVO in conjunction with Art. 32 DSGVO (availability and restorability). What this means for a deletion is set out in section 13.

11. Recipients at a glance

Beyond the cases named in the preceding sections we do not pass personal data on – in particular not for advertising purposes and not to data traders. The recipients today are exclusively:

Beyond that we disclose data where we are legally obliged to do so or where you have consented. Where data leaves your device by way of the export – as a PDF, Excel or GAEB file, for instance, which you pass on yourself or send with the mail program of your device – you alone determine the recipient; we learn nothing about it.

12. What does not happen

The following statements can be checked against the program version delivered and apply equally to the website, the app and the browser version:

13. Storage period

The period depends on the category of data. Where “a daily deletion run” is mentioned below, an automatic run on our server removes the entries once a day as soon as their period has expired; an entry may therefore remain up to one day longer than stated.

14. Your rights

Under the DSGVO you have the following rights:

For access under Art. 15 DSGVO an informal message to the address given in section 1 is sufficient. We answer without undue delay, at the latest within one month (Art. 12 Abs. 3 DSGVO). If there are reasonable doubts as to your identity, we will ask (Art. 12 Abs. 6 DSGVO).

Two rights you can also exercise directly in the app:

15. Right to lodge a complaint with a supervisory authority

You have the right to lodge a complaint with a data protection supervisory authority about the processing of your personal data (Art. 77 DSGVO). The authority competent for us is the

Hessische Beauftragte für Datenschutz und Informationsfreiheit (Hessian Commissioner for Data Protection and Freedom of Information), Wiesbaden.

The authority publishes its current contact details itself. Independently of that, you may also turn to the supervisory authority of the place where you are resident.

16. Changes to this privacy policy

We adapt this policy when the processing operations described change or when legal requirements call for it. The authoritative version is the one published here at any given time, bearing the status stated above. The versions in other languages are translations; in the event of discrepancies the German version applies.