Last updated: 25 October 2026

Only the German text is legally binding, in every country. Any other language version is a translation and serves only to aid understanding. Where it differs from the German text, the German text applies.

Filum Privacy

This page describes what the Filum app does with data. Filum archives project email out of Microsoft 365 mailboxes into storage the office chooses itself.

For bimover’s website, account, licensing and payment data, see the general Privacy Policy. That policy and this one fit together: it covers what happens around the app, this page covers the app.

1. Controller and contact

bimover GmbH, Hammer 19, 5000 Aarau, Switzerland Email: privacy@bimover.ch

For the mail inside an archive, the office running Filum is the controller, not bimover. See Section 2.

2. The mail does not reach bimover

Filum archives project email out of Microsoft 365 mailboxes into a folder on storage the office chooses itself, for example the office’s own NAS. The mail does not reach bimover. It travels from Microsoft into the app on your machine and from there onto your storage.

We operate no server in that path and we hold no copy. That also means we cannot read an archive, cannot change it and cannot switch it off. For the personal data inside an archive, the office running Filum is the controller.

3. What Filum reports to us

Filum sends us the following when it is connected to your bimover account. The account’s sign-in goes along so that we know which office it belongs to. When it is not connected, only the licence question and the request before converting go out, without the sign-in and without a single mailbox hash, and we turn them away; the report after a run is then not sent at all. The requests go from your machine and carry what any request carries, including your IP address.

When setting up and before each run, including a run in the background (Section 5), Filum asks whether there is a licence for each mailbox a project archives from. It checks as soon as the project is set up and then every time Filum shows the project’s page; nothing is taken up by that. Before a run begins, Filum asks once more and takes up the licences. If the sign-in cannot be renewed at that moment, the request is omitted and we receive nothing. Otherwise we receive one hash per mailbox instead of the address (SHA-256 over a fixed prefix and the address in lower case). If no licence is free for a mailbox, Filum does not archive it; we have still received its hash with the request.

After an archive run we receive, provided the sign-in could be renewed:

the same hash for each mailbox the run archived from
an identifier of the archive, the identifier of the run, and the time of the run. The archive identifier is created when the archive is set up and is derived neither from the project name nor from an email address.
the checksum of the latest record, how many messages the archive holds and how many records its chain counts

Before converting an archive, when Filum converts mail it has already filed because “Store attachments only once” was switched on or off, Filum reloads your account’s licence record so that your office’s settings apply; if the sign-in cannot be renewed at that moment, this request is omitted too. When Filum is connected, the same request also goes out at start-up and before a run when the stored record needs renewing, and when you click “Check” in the settings. Apart from the sign-in it carries only the app’s identifier.

On the Mac Filum also asks for the state of your account while it is connected and the sign-in can be renewed: when connecting, when the sign-in is renewed, and from time to time before a run or when you click “Check”. This request carries the sign-in, your account’s identifier and the app’s identifier.

No addresses in clear text, no subject lines, no file names, no attachments and no messages. The sample project built into Filum reports nothing and asks nothing.

We treat a mailbox hash as personal data. It is pseudonymous, not anonymous: the same mailbox always produces the same hash, and anyone who already holds an address can compute it and compare. We do not hold the addresses behind these hashes and we do not try to resolve them. We use this information for three purposes: to say before a run which mailboxes have a licence, to count how many different mailboxes an office archived in a year, which is what the licence is measured against, and to notice later that an archive is reporting fewer records or fewer messages than it once did.

Legal basis: performance of the licence contract for the question of free licences, reloading the licence record, the account status request and the mailbox count (Article 6(1)(b) GDPR), and our legitimate interest in correct billing and in the comparison with earlier reports (Article 6(1)(f) GDPR). For Swiss law, see Section 12 of the general Privacy Policy.

When you sign in with Microsoft, we process the identity token Microsoft issues and take from it the identifier Microsoft gives your account and your email address, in order to find or create your bimover account. Where the token names your Microsoft organisation, we process that identifier as well. We do not process passwords. Authentication is performed by Microsoft.

Filum signs in with Microsoft only, because the same sign-in also reaches the mailboxes it archives; there is no second login.

In Filum the same sign-in also authorises the app to read in your mailbox and in mailboxes shared with you. Access is delegated: Filum acts as you and reaches only the mailboxes and folders you can reach yourself. We hold no company-wide permission over your mailboxes. Filum asks for access to your own mail and to mailboxes shared with you (Mail.ReadWrite and Mail.ReadWrite.Shared).

With it, Filum reads, among other things:

the folder list of your mailbox and of every mailbox you name in Filum: the names of the folders and how many messages they hold, so that you can choose a project’s folder.
the folders you archive a project from, with the messages in them and their senders and recipients. Mail from addresses and domains you mark as private in the settings Filum fetches in no project; confidential mail it archives with a note.
for a project that collects by contacts and project number (the default for new projects), at every run and in the background too: the headers of the newest messages in the inbox and in sent items of your mailbox (among them subject, sender, recipients, date and the identifiers) and, for practically every one of these messages, the text without attachments, to find the project number and project name in it. After a new rule Filum reads back the same way to the rule’s start, every message with its text, for «All emails, older ones too» to the oldest message. If you assign an older message to a project in «To clarify», the next run reads back to it the same way. Only what a rule or you yourself give the project goes into the archive; of all other messages Filum keeps only checksums on your Mac.
for «To clarify», only when a project collects by contacts and project number: when the app starts, after each sign-in, when the office’s own domains change and when you open «To clarify» or decide there, the headers of the messages of the last 30 days in the inbox and in sent items, at most 500 per folder, and at most 20 texts per pass. Only you see what is listed there.
after each run, the header details of the newest messages in the inbox and in sent items of every mailbox the project archives from, at most 5000 per folder: subject, sender, date, whether attachments are included, and the identifiers of the message and of the conversation. With them Filum shows what from conversations already in the archive has not been filed yet; of all other messages it gives only the number.
while collecting, that is only when you open it in the app: the same header details of the newest messages in the project’s folder, in the inbox and in sent items, so that Filum can suggest what belongs to the project. Only what you confirm is taken over.
in the background, if you have agreed to it: the headers of the newest messages in the inbox (Section 5).

Write access is part of that for one reason: on your request Filum moves a message into the folder you archive from. The app does not send messages and does not delete them. In the Microsoft admin centre the registration is listed as “Filum Mailspace”.

What Filum reads this way travels between your device and Microsoft and stays on your computer unless it goes into your office’s archive. It does not pass through us, and we never store it. The Microsoft tokens stay on the device.

5. Running in the background

After the first run of a project, Filum asks you once whether it should keep archiving in the background. Only if you agree does it register with macOS as a login item. Filum then starts without a window as soon as you log in to your Mac and, every two hours, archives the new messages of every project you have set up. Everything this page says about a run applies to these runs, Section 3 included. If you decline, Filum does not ask again. You can switch it on and off at any time in Filum’s settings, and off in macOS System Settings under login items.

After such a run, Filum also fetches the headers of the newest 200 messages in the inbox of every mailbox a project archives from, without text and without attachments. The headers also contain sender, recipients and subject. Filum evaluates only the line with which a sender’s domain signs its message (DKIM signature), takes the domain and the name of the key from it, and fetches the matching public key (Section 6). It keeps nothing of the rest.

Filum stores the keys on your computer, in the app’s own storage area. It moves a key into the archive only when an archived message needs it. A key that no message has needed for twelve months is deleted. The reason: a sender’s domain changes its keys from time to time, and once the old one is no longer published, the signature of an older message can no longer be checked. None of this goes to us; the office running Filum is responsible for it (Section 2).

6. Senders’ keys (DNS)

To fetch the public key of a sender’s domain, Filum asks the name service (DNS) your computer uses anyway: when filing a signed message and in the background (Section 5). The query names the key and the domain, for example selector1._domainkey.example.ch, no address and no content. It can be seen by the name service of your office or your internet provider and, through it, by the name server of the sender’s domain. Filum uses no other service for this, and we receive none of it. A key Filum fetches while filing goes into your office’s archive. One it fetches in the background is first stored in the app’s own storage area on your computer and moves into the archive only with the archived message (Section 5). The sample project makes no such query.

7. The timestamp service

A record is created at the end of a run that changes the state of the archive: at the first run of an archive, when a run files something, moves a key into the archive or takes over a changed setting, and when Filum converts an archive. A deletion is recorded by the next run. Otherwise a record is created at the first run of a day. For every record, Filum asks independent services for a timestamp, so that the time of a state can be attested by somebody other than the office that owns the disk. Filum sends these services a checksum of the record and nothing else.

The default is OpenTimestamps: Filum sends the checksum to four public calendars (a.pool.opentimestamps.org, b.pool.opentimestamps.org, a.pool.eternitywall.com, ots.btc.catallaxy.com). They combine many checksums and anchor them in the Bitcoin blockchain. Some hours later, when the archive is checked, Filum collects the finished confirmation: from the calendars the receipt names (alice.btc.calendar.opentimestamps.org, bob.btc.calendar.opentimestamps.org, finney.calendar.eternitywall.com, btc.calendar.catallaxy.com), with the value from the receipt, and from two services that provide Bitcoin blocks (blockstream.info and mempool.space), with the number and the identifier of the block. Both must name the same block. SwissSign (Switzerland, RFC 3161 timestamps) can be chosen instead in the settings. The requests go from your machine and carry what any request carries, including your IP address. We receive none of it.

8. Support: your request and the diagnostic log

When you write to support from Filum, we receive the subject and text of your request, your name and email address for the reply, Filum’s platform, version and language, whether a diagnostic log exists, and a random, resettable installation identifier, so that several tickets from one installation can be linked. When Filum is connected to your bimover account, the sign-in goes along and we link the request to your account.

Filum keeps a rolling log on your device of what it last attempted: runs, errors, folder and file names, counts, and how long the individual steps took. It goes nowhere on its own. It reaches us only if you release it, and the app shows you the full text first.

The log comes with an overview without which support cannot understand the case: the account you are signed in with, the state of your licence, and for each project its name, its number, only the last folder of the storage path, whether it was reachable, how many mailboxes the project archives from (not which), the report of the last run and the result of the last check.

File names in the archive are built from date, sender and subject. Before a log leaves your machine, Filum replaces every such name in it with a placeholder, attachment names included, removes the addresses of your correspondents and shortens every storage path to its last folder. A log never contains message text or attachments. If a case is especially sensitive to you, send the ticket without the log and we will ask for what we need.

9. Support: a session you release

Filum can also take instructions from the bimover support app when that app is installed on the same machine under the same user account. The two exchange files in a shared folder on your disk; there is no network connection and no open port for this.

The channel is shut until you switch it on, a release lasts one hour and then closes by itself, and an instruction older than two minutes is refused. While a release is open, a support agent can ask for the same things you can see: your projects and sign-in state, the diagnostic report, what a mail folder currently holds, and the result of checking an archive. The agent can also start an archiving run, which is the same run your own button starts.

Nothing can be done through this channel that a button in the app cannot do, and every instruction is recorded in the app.

10. The Outlook add-in

The add-in for Outlook is a button that opens the Filum app. It reads neither messages nor details of your mailbox from Outlook, and it passes no details from Outlook on to bimover. It asks Outlook for the lowest permission level.

For Outlook to show the add-in, it loads the add-in’s page from www.bimover.ch and the office.js program library from Microsoft. As with any page request, your IP address and the usual details of your browser go to these servers. Outlook usually adds details of the program, platform, version and language to the address. How we handle them is described in the general Privacy Policy; for Microsoft, Microsoft’s own privacy statement applies.

The button calls the address www.bimover.ch/filum/oeffnen. If Filum is installed, the operating system takes over the address and starts the app. Otherwise the browser shows a page that explains how to open Filum, with a link to the contact page. The address carries no data.

11. Your rights

For the account, licensing and billing data around Filum, the rights set out in the general Privacy Policy apply, and requests go to privacy@bimover.ch.

For the mail inside an archive, we are not the controller and cannot act: the archive sits on the office’s own storage and we hold no copy. Requests about that mail go to the office running Filum.