New Terms of Service and Privacy Policy in effect

As announced one month ago, our new Terms of Service and Privacy Policy implementing the European Union’s General Data Protection Regulation (GDPR) take effect today.

The GDPR is a set of regulations declaring that the individual should have control over their personal data by specifying how such data may be collected, processed, and stored.

Important principles include that personal data must be processed lawfully, for legitimate purposes, and with explicit consent from the user.

Runbox’ privacy commitment

Runbox has always been committed to the privacy of our users, and the GDPR principles are now fully integrated into our Privacy Policy. It provides a comprehensive overview of the policies that govern your privacy as a Runbox user, and describes in an accessible way the types of data Runbox collects in order to responsibly and reliably operate an email service.

It also lays out how user data are processed and stored, how they are being protected, and what rights you have as a user of our services.

To find out more about our GDPR implementation, please see our previous blog post GDPR and Updates to our Terms and Policies.

Review the new terms and policies

If you haven’t already done so we ask that you review the revised terms and policies now, and invite you to contact us with any questions or concerns.

If you are already a Runbox user or customer you have already actively consented to our Terms of Service when registering a Runbox account, and you do not need to consent again now to the new version.

As a new Runbox user you will have the opportunity to consent to the terms and policies when registering your account.

5 thoughts on “New Terms of Service and Privacy Policy in effect”

  1. With regards to the “right to be forgotten” condition, it seems that a user must contact Runbox and request that their data be deleted. However, your Privacy Policy states you must keep “Account Information” for up to 5 years. Does that mean you delete all emails, but keep the account profile? This needs clarification in your policy. How is a use reassured that their data was actually deleted? No computers are 100% secure, no matter how much effort is done. So what steps does Runbox take to ensure that “erased” data is entirely not recoverable? Delete an account directory from a server does not delete the files that were in that directory, but merely unlinks them. They can still be recovered by a malicious actor. Please expand on your procedures.

    1. The “right to be forgotten” isn’t absolute where other regulations require us to keep data on customers. How we delete data in accounts when this is requested by customers is unrelated to this, and is something we continuously evaluate on a technical rather than legal basis. We regularly review issues surrounding privacy and will update our procedures when new opportunities to improve customer privacy are discovered.

  2. Thank you for the response, Geir. As a privacy-focused company, can you point me to an article that explains how deleted content is handled? It would be great to see something written up that explains the process that Runbox takes to ensure that deleted data is actually unrecoverable from your systems. This would give your customers added piece of mind, and reinforces your stance of taking privacy very seriously.

    Again, unlinking a directory does not delete files from disk. That data is only gone after other files overwrite that space on disk, or if the space is zeroed out. So I think this is a perfectly valid topic to expand upon, and a great time to do that. 🙂

    I know that’s a separate topic from GDPR, but it is related to your Privacy Policy.

  3. For example, in my Main Account section, I see the Home Directory clearly shown. It is believed that this directory contains _everything_ in my account:

    Home directory: /nfs3073/data/ssd-042/runbox/th/therigidorchid

    (randomized for privacy)

    First, I see “nfs” suggesting “Network File System”.
    Second, there’s a reference to an SSD.
    Third, I see that my entire account lives under a directory named after my username, with a parent directory named after the first two letters of that username.

    So, first, as a Network File System, how many other areas of the Runbox network can access this directory structure? Second, if I choose to delete my account, does your system just call “unlink()” on the account directory named “therigidorchid”, or does it zero out the entire directory tree?

    I know that Runbox has a secure infrastructure, but I’m just challenging you to take a closer look at these points. Since the directory structure is based on usernames, that suggests that someone can quickly find the location of any account just by knowing the username. If your walls were ever breached, that leaves it all wide open to targeted attacks.

    I know that security by obscurity is a hot topic, but it does offer additional layers of protection against targeted attacks. For example, if you used a cryptic mapping of usernames to directories, so there’s no direct correlation, that stops targeted attacks in their tracks.

    Imagine if the username “therigidorcid” was mapped to random directory, such as:

    /nfs3073/data/ssd-042/runbox/6b/6b4ac9ac34de2

    A malicious actor would need the mapping to figure out which directories belong to which accounts. More secure in that regard.

    Anyway, I’m not concerned. Just sharing my thoughts on how I’d approach securing the filesystem should the walls ever be breached.

  4. Thanks for your comments, Ted.

    As you know, there are pros and cons with both security by obscurity and security by design. We have chosen a balance between the two, and therefore choose to not provide too much technical detail about exactly how data is processed and deleted. However, your comments are appreciated as we continuously assess our internal procedures. Encryption of data at rest is among the measures we are considering.

    A randomized mapping as you suggest would require a central index mapping which an malicious actor could use to attack one or several targets. Such a randomization would also introduce complexity that could potentially cause issues when accessing user data. We might still consider this in the future, or we may remove the information about home directories from the user interface.

Leave a Reply

Your email address will not be published. Required fields are marked *