Page MenuHomePhacility

Phacility Data Use Policy
Updated 444 Days Ago

The Phacility service helps individuals and organizations to host, store, search, and retrieve information.

In order to provide this service, you upload a large amount of private and sensitive information (including documents, files, images, communication, encryption keys, passwords, source code and logs) to our software.

Keeping this information secure is an important aspect of the service, and we endeavor to protect it from both external threats and improper internal access.

This document focuses on internal policies for access and use of your data. Except as described below, Phacility staff do not (and can not) access your data. In particular, with specific exceptions, Phacility staff can not log in to your accounts or instances and can not view your documents, source code, etc.

Username, Instance Identity and Membership

We access and use your username and the identity of your instances (generally, the instance names) and your relationship to instances (for example, membership) internally to help identify and resolve support or technical issues that relate to a specific instance or set of instances.

For example, if you report difficulty accessing an instance, support staff see your identity, and can identify instances you are connected to in order to determine which instance has a problem.

Likewise, if there is a technical problem with an internal service, support staff can identify the affected instances by name in order to communicate and/or resolve the issue.

Capacity and Size Information

In some cases, support staff have access to access statistical information about the size of your instance (for example: the number of users, number of repositories, size of backups, network usage, total data size, or number of support requests).

We use this information to help us scale the service, anticipate the effects of maintenance, plan capacity, or otherwise better support or administrate instances.

For example, we may want to move large instances to dedicated hardware, or spread them across multiple services. Information about instance size can help us plan and execute these changes, or be confident these changes are correct and reasonable when an automated system performs them.

Information You Allow us to Access

In the course of providing support, we may ask to gain access to your data in order to reproduce, debug, understand or verify an issue. You can decline these requests, although we may be unable to resolve issues we can not reproduce.

If you allow us to access your data, we will limit the scope and timeframe of the access to the minimum reasonably required to resolve the issue you are experiencing. To the best of our ability, we will log and audit how this access is used.

Usage Information

At times, we collect statistical usage information from instances (for example: which applications are in use, how heavily they are being used, and how frequently certain options or features are used, enabled, or configured). This data is anonymous and used to inform decisions about the product and our roadmap. For example: if we see that a feature is in common use across instances, we may prioritize improving it.

You can find a log of queries we have executed against cluster data at Ad-Hoc Query Log.

Changes to Data Use

We expect that we may change what data we access in the future. Our access to and use of data is currently very tightly restricted, and essentially represents the minimum level of access we can reasonably have to provide the service.

In the future, we may be interested in collecting more statistical information about instances. For example, we may want to collect performance data so we can understand how to optimize the service.

We do not currently collect this data, and will update this document and notify users if we do make changes.

Information Disclosed to Third Parties

We explicitly disclose some information to third parties that provide technical services. In other cases, third-parties are technically capable of accessing data. These are the third-party services we currently use:

  • Amazon Web Services hosts the machines we run the service on, and has technical access to the network and hardware.
  • Stripe is a payment processor used to charge credit cards. They receive and process billing information.
  • MailGun provides inbound and outbound mail services.
  • ReCAPTCHA provides CAPTCHAs.

In all cases, these third parties either do not have access to data or are obligated to restrict access. We will discontinue use of a service provider if we believe their policies are at odds with our own.

Disaster Recovery, Abuse, Emergencies, and Law Enforcement

In extreme cases, we may need to access data to recover from disasters, stop abuse, prevent harm, comply with the law, or respond to other urgent or unusual situations.

This exceptional access requires internal authorization from senior staff, who are the only employees with technical access to perform it. As permitted by law, we will disclose when (and to what extent) we used this access.

Operational Access Transparency Report

Last Updated: September 29, 2017

This is a transparency report which categorizes operational access levels in the Phacility cluster.

As we currently have two employees, this disclosure isn't very meaningful in its current form, but we believe transparency about access control is important and expect this report will reflect a disciplined approach to access control as we grow.

Access is affected by both policy controls (which describe when access is acceptable) and technical controls (which prevent access). Policy controls can remedy improper access, but can not prevent it. Technical controls prevent access. Wherever possible, we use technical controls.

At the highest level, a minimum number of senior staff have full technical access in order to recover from disasters and remedy problems in the access control implementation itself.

Operational staff currently have these levels of access to the cluster:

Access LevelDescription
MasterFull technical access to the cluster; access restricted by policy controls.
NoneNo access to any customer data or cluster operations.

This table summarizes staff access levels:

Access LevelTitleHeadcountNotes
MasterCEO1The CEO currently has significant operational responsibilities.
MasterHead of Operations1Operations has significant operational responsibilities.