Create a privacy policy

[luckyrat]

The latest build of KeeFox 1.3 contains some code to track useful metrics so that we can improve KeeFox. No personal or sensitive information is collected but I'd like to create a privacy policy none-the-less, just to put people's minds at rest if they spot occasional connections to keefox.org domains.

The draft of this policy is below...

KeeFox does not collect any personally identifiable information from you.

KeeFox will send basic system information (such as operating system version, Firefox version and KeeFox version) and information about important events (such as setup progress, connection to KeePass and interaction with KeeFox features).

Data is sent to a secure web server which stores the raw data. This data is pulled into a statistical analysis package to help spot problems early and improve decisions regarding future development. We may release reports containing aggregate data and summaries.

You can find out more about the part of KeeFox that manages the collection of this data at [wiki link]

Any significant changes to this policy will be announced on the official KeeFox.org website (you can subscribe to the updates on the website via email or RSS) [TODO: link to various places]. Insignificant changes such as spelling corrections, re-wording for clarity, etc. may not be announced. For all changes, a note that a change has occurred will be included in the release notes of the next KeeFox release.

You may also be interested to note that Mozilla also collects basic statistics on all of your installed add-ons when Firefox checks for updates to your add-ons. The Mozilla Firefox privacy statement [Link to http://www.mozilla.org/en-US/legal/privacy/firefox.html] contains more information about this and Firefox privacy in general.

Last updated: 2013-12-03

[krbvroc1]

This should definitely be optional. I do not want Keefox or any other plugin submitting statistics without my permission. I am pretty sure that when you first install Mozilla there is a bar at the bottom which says something about 'Choose what info your share' or some such wording and you can click it and disable crash reporter, health reporter, etc. Those options are under 'Option -> Advanced - Data Choices' in the latest FF.

I don't see an upside on forcing this on users. In particular, I suspect the demographic of KeeFox/KeePass users will lean towards a more security/privacy conscience individual and you might end up creating more distrust than what is gained by having some statistical data to play with.

[dlech]

I take it that the code is just in KeeFox and not KeePassRPC. Correct?

Like Ken said, the proper way to do this would be to make it optional. Have a "first run" dialog that says "Help make KeeFox better!" and then describes the privacy policy (probably a condensed version) concluding with "Do you want to send anonymous usage statistics to keefox.org?" with Yes/No buttons.

I made some revisions. I stuck it in a gist so that you can look at the diff. I had hoped that it would highlight the individual words and phrases that I changed like some diff programs do, but no such luck. Oh well, at least it will save on some scrolling.

Basically:

• Get rid of the parenthesis (just the parenthesis, not what is in them)
• Reword developer jargon. There are some phrases like "raw data" and "package" (meaning software) that normal people don't use on a daily basis.
• Make "You may also be interested..." a footnote since it is not really policy material.

[luckyrat]

Yes this is KeeFox only. Although some statistics would focus on the KeePass side of things (e.g. how many databases were sent from KeePass to KeeFox) none of the actual metrics management code goes near KeePass directly. We'll only be able to generate stats for things that KeeFox already knows about.

Thanks both for the feedback and @dlech thanks for the suggested edits. I've forked the gist (https://gist.github.com/luckyrat/7797743) and made a few further changes but I think it's now much closer to a finished policy.

Because I haven't decided exactly how the analysis will be done, I've just dropped the "periodic" bit of your edit since, on reflection, I think this is a detail that's not strictly required in the policy.

I've reworded the "optional" bit at the start to dumb down the language slightly but I've not yet decided if it should in fact be an optional behaviour.

As for the benefit of making it non-optional, it's really about getting an accurate picture of how the add-on is used. As soon as there are an unknown number of users choosing to not send the data, one has to wonder whether their absence will skew the data in a non-uniform way (I would think this is highly likely for the same reasons @krbvroc1 used to highlight the importance of handling this issue carefully).

To give a basic example, I could look at the data in 6 months time and see that only 0.1% of users are utilising the keyboard shortcut functionality and therefore decide that I should prioritise development effort away from feature enhancements in that area. If a high proportion of the unknown number of opted-out users do actually use that feature, their experience (and that of the opted-in 0.1%) would become inferior compared to a situation where everyone were opted-in.

I was not aware that Firefox let you opt-out of add-on statistics collection but it appears that there is an about:config setting (extensions.getAddons.cache.enabled) which might do this, although the implication in their privacy policy and from the naming of the setting is that this will disable more functionality than just the statistics collection. Still, I suppose a similar advanced:config option for the technical users (who might have already set that Firefox setting) is a compromise we should consider. Or maybe just an option to opt-out of everything except the sort of basic stats one can glean from a user-agent string and KeeFox version - at least then we'd have some rough idea of how inaccurate any more in-depth statistical analysis will be.

No matter whether any of this makes you reconsider the need for an opt-out setting, it sounds like the messaging around the change needs to be improved if it is to avoid upsetting people. Hopefully the revised policy itself and a carefully worded announcement on the website should help.

It would be good to understand whether that could be enough on its own or whether some people will just baulk at any hint of their web browser sending some bytes to a stats server on the internet. My opinion is that some people will object regardless of how we explain the situation but that leaves two interesting questions:

1. Will their reaction be any different if they can opt-out (or is it just the entire concept of anonymous tracking code in software that offends them)?
2. Given* that what we're doing is morally acceptable and safe, and assuming the situation is explained sufficiently, should we actually be concerned what their reaction is?

* I obviously think this is true or I wouldn't be suggesting it but of course it's difficult to define any claim of morality as a complete and provable truth.

I'd welcome further comment from anyone on this topic.

PS: I put the two gist versions side by side into http://mergely.com/editor - it's not perfect but it does pick out most differences to the word level and I don't usually have anything better available.

PPS: Brackets are my best friend and worst enemy - they help me draft thoughts quickly but each time I proof-read my latest draft, I'll somehow find that I'm removing another set (often completely removing the contents). However, it's getting late so refactoring brackets from the above text is a step to far this time!

[krbvroc1]

My opinion is that whenever data is to be collected like this, it should be opt-out. Providing an opt-out setting, to me, would eliminate the concern. So I am 100% in support of an opt-out setting that disables ALL reporting to any external server. It is also within the spirit of Firefox which provides these controls to disable the reporting. Given the number of people who will probably leave the setting at default (whether or not they have a problem with it), I think you would still have a statistically valid sample.

Defining what is 'morally acceptable' can be tricky and can be in the eye of the beholder. To many people, anonymous tracking and reporting back to a master server, of how software is being used is not morally acceptable. Some people use VPNs and/or modify their User-Agent string because they don't even want that to be stored / tallied.

There are also other reasons for not forcing this...

1. What if a user has numerous virtual machines for various purposes and wants to disable reporting on machines that are not typical of day to day usage, but leave it on for the 'production' machines.
2. What if a user does not have an always on internet connection and is using KeeFox for connections to internal machines?

[luckyrat]

I've posted a new page on the wiki to explain the system in more detail and have essentially split the data into two types: system data and usage data. https://github.com/luckyrat/KeeFox/wiki/en-|-Metrics-collection

Both types of data will be enabled by default but through some method* the user will be able disable the usage data. Since the system data won't contain anything even vaguely unique to a particular user, and since the precise list of data collected in that submission will be incorporated into the privacy policy itself, I don't intend to provide an option to disable the collection of those bits of data.

I've not implemented the change yet but I don't think it will take long so I should be able to do it this weekend. I've also not updated the actual privacy policy yet but I'll do that soon too, so that the different types of data collection are accurately defined in that too.

* I'm leaning towards exposing this as an option somewhere in the main KeeFox options panel but for the initial beta release it may be adjustable only through about:config.

I need to check the specifications of the storage system being used within the metrics module but my understanding from the standard IndexedDB web specification is that there is a limit on the amount of data that can be stored in any given database (50MB I think). This should be sufficient for storing the metrics data for very long periods of time without an active internet connection and the limit will prevent any runaway storage usage problems in the rare case of someone disconnecting their browser from the internet permanently. Additionally, the storage limit and an algorithm within the metrics module will ensure that any large backlog of messages are sent in small batches that won't overwhelm an intermittent and/or very slow internet connection.

As for the virtual machine (or similar) issue, there is definitely a risk that occasional data points will be sent from systems that are not typical of day to day use but I think the number of these situations will be low. It may not be easy to do so, but it is at least theoretically possible to remove or otherwise account for these situations during analysis, certainly more easily than trying to account for an unknown quantity of unknown data.

I'll reference this ticket when I push the code changes soon so that you can take a look if you want.

[krbvroc1]

First, thanks for the description / split of data. I do still think that the entire thing should be optional. Any 'phone home' mechanism is going to potentially be met with some subset of users who dislike the concept and could be vocal especially in their reviews of the plugin.

Second, for the system data that is collected, would it make sense to add the KeePass version, and if available, the Mono / .NET version? Those two metrics would seem to give a good idea of what version/levels of those SW needs to be supported/focused on?

[luckyrat]

This isn't a final and unchangable decision and I'd obviously prefer to reduce the number of negative reviews but I'll be balancing such feedback against the benefits I mentioned above. I'll keep this issue open until 1.3 is released to help keep discussion in a single location but once that's done, I'll close it and open a new issue for any future metrics collection changes.

Good point about the KeePass and .NET version. I get a little bit of data there during the setup process but only whether they are installed or not. It would be good to get more detail but that would require KPRPC to send the data to KeeFox and I'd rather not add new features to KPRPC now we're so close to a beta release. I've added them to the list of system data we'll collect but I won't actually be able to start collecting that data until KeeFox 1.4.

[luckyrat]

Privacy policy gist now updated to reflect split into system and usage data: https://gist.github.com/luckyrat/7797743

[luckyrat]

The latest experimental build of KeeFox 1.3 includes a checkbox in the main options panel to make it easier for people to disable anonymous usage stats collection.

[luckyrat]

The official privacy policy for KeeFox 1.3 is now available on AMO: https://addons.mozilla.org/en-US/firefox/addon/keefox/privacy/

And here's last month's news announcement for reference: http://keefox.org/2014/01/26/keefox-has-a-privacy-policy/