Defining a Privacy Policy. Ideas, tips, examples?

[stig (Stig Nygaard)]

I have read that to have a chance to get a browser extension featured by Mozilla, one of the requirement is that a privacy policy has been defined for the extension. Now with approx. 100 daily users of my extension, it probably doesn’t qualify for anything anyway, but still it made me think that it maybe would be good practice to define a privacy policy for my extension…

My extension, Flickr Fixr, is a simple extension with the solely purpose to make Flickr a better place to be. It of course runs on Flickr’s main domain (flickr.com), but also on flickr.net which hosts two flickr blogs. The extension is basically a content-script altering UI and sometimes adding information information from other pages on flickr.com or from the Flickr API at api.flickr.com (all API calls are currently “public unsigned”).

My first attempt to define a privacy policy looks like this:

Flickr Fixr does not collect data and does not use data in any other ways than nescesarry for the extensions features and functionallity. The only purpose of the extension is to make it a better experience to be on Flickr.
Flickr Fixr does in current version not communicate any data at all outside the flickr domains (flickr.com and flickr.net). If some future new feature of Flickr Fixr will require data to be sent outside the flickr domains, It will be an opt-in (default disabled) feature, and I will make sure to state how data is used before you eventually enable it.

The “opening” for future changes in the end of this draft-version, is because I have an idea in my head for a feature which will require an external database application keeping some statistics on favorites and favorites lists, and that the user needs to register as a user on my database application (using Flickr id) and maybe also authorize extension and/or database-application to read the Flickr API signed as the user (readonly). I probably never find the time to implement this idea, but didn’t want a privacy policy to be a problem, in case I do.

But then I read the mouseover hint on my plugin’s settings page on AMO for defining privacy policy saying:

If your add-on transmits any data from the user’s computer, a privacy policy is required that explains what data is sent and how it is used. It is only relevant for listed add-ons.

which is kind of the other way around than I was thinking. I guess my basis assumption was that extensions was running in a sandbox, thus it was not an interesting angle looking at transfering information found on the browser/system. But of course, depending on granted permissions, extensions does have access to some information on user, users system (OS/browser) or setup available.

So how could a good simple privacy policy look like? Does anybody have some tips or examples of clear, simple and short privacy policy for a browser extension, that could be good inspiration?

[jscher2000]

But then I read the mouseover hint on my plugin’s settings page on AMO for defining privacy policy saying:

If your add-on transmits any data from the user’s computer, a privacy policy is required that explains what data is sent and how it is used. It is only relevant for listed add-ons.

which is kind of the other way around than I was thinking. I guess my basis assumption was that extensions was running in a sandbox, thus it was not an interesting angle looking at transfering information found on the browser/system. But of course, depending on granted permissions, extensions does have access to some information on user, users system (OS/browser) or setup available.

Hmm, while extensions run in a sandbox, they may have permissions to capture history in real time and read content from pages. Some extensions have been removed for exfiltrating history inappropriately. Other sensitive data also could be discovered. So that is where privacy could be most seriously impacted, even without access to the rest of the system.

There is a wide variation in privacy statements. In part this is a matter of style (or “corporate voice”), in part the national approach to privacy (compare U.S. and Germany, for example), and in part whether legal professionals got involved (in which case you can expect a more comprehensive approach).

Since I am a lawyer, I probably would look at large companies’ extensions to get an idea of the things I might want to say. For my user script, I log installations through including an icon, so I have a statement online about that along with the usual webserver stuff. Not applicable to your extension, but yet another style to consider. https://www.jeffersonscher.com/gm/google-hit-hider/privacy.php

[stig (Stig Nygaard)]

Thanks very much for comments. I know its a difficult issue and question to advise on. Probably even as a lawyer

I’m kind of hoping to be able to make it short. Like maybe 10 lines. So very different from the typical policies made by most large companies. If I can get it to make sense and have any value in such short statement.

And thanks for your interesting example. With the icon and google analytics, you are getting more information than I get (I currently basically get none info about use or users of my extension, besides the statistics that Mozilla’s addon store provides). But if I ever implement the favorites related feature I talk about, I too will have connections to a webserver or webapplication I’m running or have access to. And even a Flickr identity of my users, I guess.

I’ll think a bit more about it, and welcome any further suggestions, ideas and inspiring examples anyone would have…

[stig (Stig Nygaard)]

Bringing up this thread from last year. But I never decided on anything back then. Now I have a candidate policy. Trying to keep it really short and simple. But before adding it to AMO, I just wanted to hear if anybody think it is a bad example of a privacy policy, if it’s missing something, or how people would feel about reading that policy for an extension they were about to install? :

Flickr Fixr does not collect or share data about its use, users or users’ systems. All data is kept within the “eco-system” of your browser/extension and Flickr’s servers.
If some future feature of Flickr Fixr requires communication with some external service, it will be an opt-in (default disabled) feature. And how data is used if enabling feature will be clearly described.

[freaktechnik (Martin Giger)]

I’d personally also refer to Flickr’s privacy policy.

[stig (Stig Nygaard)]

Your point is that if Flickr Fixr sends data to Flickr, we should know what Flickr does with it?

Hmmm… Your comment made me think about the part that says:

All data is kept within the “eco-system” of your browser/extension and Flickr’s servers.

What I write kind of sounds like Flickr Fixr is storing or sending data to Flickr, which I wont actually say it is. Communicating, yes. A couple of places it reads data from another Flickr page or from a webservice to fetch more details about the image the user is already looking at. And if you are surfing Flickr - especially if you have an account and is logged into it - I would expect you are aware that Flickr’s privacy policy applies.

But still, it might look good to add the reference. Maybe a policy something like the following is better:

Flickr Fixr does not collect or share data about its use, users or users’ systems.

Current version of Flickr Fixr is not communicating with any 3rd party (non-Flickr) services. But if some future feature of Flickr Fixr requires communication with a 3rd-party service, it will be an opt-in (default disabled) feature. And which data that might be shared by enabling such a feature, will be clearly described.

You might also refer to Flickr’s privacy policy.

[freaktechnik (Martin Giger)]

Communicating involves contacting flickr’s servers, which means their privacy policy for those calls applies. Even just a request to a server contains information about the user they may not want to share. I personally just state what services an extension interacts with and if possible link to their privacy policy.

Now sure, the extension only works on Flickr’s properties itself, but it is still good to tell the user that the extension will have to load additional things from flickr or similar. Not all users understand that adding data requires that data to come from somewhere that may not be their machine.

[stig (Stig Nygaard)]

I hesitate doing it too technical and detailed. It will sound scary for people not fully understanding how internet and page/service requests works. But maybe something like the following would do nice, and take your thoughts into account…

Flickr Fixr adds or changes look and functionality of Flickr pages, by rearranging, modifying and sometimes also by adding extra content fetched from another Flickr page or Flickr service.

Flickr Fixr does not collect or share data about its use, users or users’ systems. But any activity on Flickr sites and services can be monitored and logged by Flickr itself.

Current version of Flickr Fixr is not communicating with any 3rd party (non-Flickr) services, but if some future feature of Flickr Fixr requires communication with a 3rd-party service, it will be an opt-in (default disabled) feature. Which and how data might be shared by enabling such a feature, will be clearly described.

You might also want to refer to Flickr’s own privacy policy.

I’m not natively English speaking, and any comments about the language/grammar is also welcome. Though I guess it in principle is a bit out of scope for this forum…

[stig (Stig Nygaard)]

Thanks for the comments. I ended up skipping the last line with link to Flickr’s privacy policy. I think you can easily take the step from reading the policy to take an additional look at Flickr’s policy if you feel that is relevant. Also if I included Flickr’s policy I also felt I should include AMO/Mozilla’s privacy policy. It started to go a little over the edge I think…

https://addons.mozilla.org/en-US/firefox/addon/flickr-fixr/privacy/

I hope it makes my extension look trustworthy, and signals that it really doesn’t do anything besides the obvious and relevant for its functionality.

[rugkx (rugk)]

I think your one reads quite good.

Another general note, I have:
If you use the storage.sync API to let Firefox sync (part of) your add-on settings or similar, it is good practice to also mention that in your privacy policy. Best is to explain what you do, that data is e2e-encrypted in Firefox and stored on Mozilla servers. Apart from that, just refer to Mozilla’s privacy policies about that topic.
Here is how I describe that.

The only more complicated example I have, is this one, which is quite hard, because it can contact any servers, based on the user’s choice. In the end, i ended up describing the add-on’s functionality in non-tech terms (as best as I can) pointing out where, which data is sent.

If anyone has ideas to improve this/criticism feel free to comment or (maybe better) open a new issue in the corresponding repository. (Note I’ve used permalinks above, the up-to-date version can differ, if you are reading this later.)