In particular, I think this kind of thing is bad and we should be in the mindset that it's bad and not an acceptable use of user data: in 2011, Basecamp published a fluff blog post which included trivial user data (the 100,000,000th file uploaded was a picture of a cat):

• https://signalvnoise.com/posts/3076-i-heard-you-like-numbers?58

There was some backlash about this, and they published this followup:

• https://signalvnoise.com/posts/3078-trust-is-fragile

Although this is silly (disclosing this "cat" information is obviously not important), I do think it represents a fundamentally undesirable attitude toward use of user data. I'd like to see most staff not be able to determine that the 100Mth file was a picture of a cat, and senior staff who have access to this information to consider publicly disclosing it for a fluff blog post to be serious misuse of user data.

To further my thinking here, in DHH's post, none of the solutions are "there should be significantly more rigid internal controls around access to this data", but I believe that should be the foundation of the approach here.

In a comment, he mentions:

Trevor, I don’t really see how [an encrypted database] helps things as long as we are able to log into accounts to debug them. The data will be decrypted at that point. Maybe such a split makes more sense in a large corporation where system administrators don’t even have access to the application level to help resolve issues.

I likewise have different thinking here: the base state should be that we can not log in to accounts to debug them. If this proves onerous, we should relax it in response to specific needs, and relax it as little as possible (accounts authorize access; access is logged/restricted/time-boxed; improve infrastructure for reproducing or reporting issues, etc).

The number of times I actually needed production access at Facebook to resolve something was very small. I probably used it (that is, modifying code in production to debug an issue or connecting directly to production machines -- not accessing user data) more often than I needed it, but usually because it was slightly easier to do it that way than the right way, not because it was required to move forward.

In Phabricator, we do have a fair number of "Weird repository X is broken in awkward way Y" reports, which are very difficult to debug without access to the data, but I think that's a perfect candidate for narrow tooling (small well-known scope, generally not time-critical). Our response can be something like "We can't reproduce this on our own, can you either grant us permission to clone repository X, or create a similar repository which exhibits the problem without sensitive data and give us access to that? Document XYZ explains how we'll use this access."

I like the main thrust of this... However, I don't think we should forbid any aggregate data usage we don't enumerate now, and instead give ourselves some room in that 1) we're human and can possibly miss something in such an enumeration and 2) the product is going to change enough where that list will be stale sooner or later anyway. So I'd like to see a whitelist with the last item being "etc." and then an instructive blacklist.

The other bit of mild dissent here is I'm super, duper interested in having more data about how people use Phabricator so we can effectively and confidently make decisions about how to spend our time. e.g. if we could tell that users used workboards like whoa across Phacility but actually don't use Dashboards pretty much ever, we can do a much better job prioritizing what to do next. Additionally, I will find it a huge source of motivation to see real usage numbers that are increasing / at least moving in some way... Long story short, I think 1) using Phacility means your install is part of these aggregate stats and open source installs can opt in and that 2) we should have a dashboard of this sort of information that Phacility staff can call up. The good news is I don't think any of this is "icky".

I'm fine with starting there, but want to document that we consider that part of signing up with us and that anyone in the company has access to it.

Would you expect any employee to be able to see, say, how many paying users a specific install has? Or only aggregate data across all installs? Or something more granular? (Number of users for a specific install starts to feel pretty icky to me.)

Notably, specific recent example of users with access to "specific install" data abusing that access:

http://www.bloombergview.com/articles/2015-01-23/capital-one-fraud-researchers-may-also-have-done-some-fraud

I figured aggregate data across installs for any sort of dashboard / all employee access data.

For per-install stuff.... I think understanding if a given install has a larger amount of contacts for the upstream than average is important - it would likely be prudent to reach out to that install to figure out what's going on or even in extreme cases to consider ending that customer relationship. (This seems like something for Nuance though.) I think there's also a theoretical need to understand an installs relative size for prioritizing things - particularly if its about customer retention (or getting new customers) - but I don't think in practice that's going to come up for quite some time, if ever. The last bit here is I think it could be interesting to see stats on a per-install basis to understand how certain use cases work out - e.g. an install that turns off all applications except maniphest versus an install that turns on everything including prototypes versus an install that has just engineers versus an install that has many types of workers, etc.

Of all these per-instance things, I think identifying whale-support installs is the only thing I want to make sure we can still do. We can even blacklist the other things if you want as they seem low utility to me at best.

Yeah, I think we can be very narrow in exposing data like that -- like let anyone see the approximate percentile of "support tickets per active users" that an install falls into (a "neediness / whale support" score) without actually disclosing user counts or user count changes over time. In particular, I feel like most employees should not be able to determine if a client fires a lot of employees suddenly.

I'm going to start with something on the restrictive side here, with exceptions for some of what's mentioned here and some other forseeable things, and just try to frame it as a living document and we can go from there.

Some of the stuff (like application usage) we could also get through opt-in stuff in the upstream, too, without needing to engage Phacility access specifically. I think that's generally a better approach when it's applicable.

I also pruned out a couple of things from our Privacy policy that have not materialized, like "third-party advertisers". We can amend the policy if we ever have third-party advertisers.