Create a privacy policy for drupal.org.
webchick - September 26, 2007 - 13:48
| Project: | Drupal.org webmasters |
| Component: | Other |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | Legal |
Description
Any lawyers in the house?
http://drupal.org/privacy is a stub page that needs some actual content.
Things to cover:
a) The usual cookies/personal data/etc. stuff that any website has.
b) Information sent to drupal.org via update.module (6.x)
c) Information sent to drupal.org via drupal.module (5.x)
d) That we are not evil and have no intention of doing nefarious things with this data.
I can fill in the technical details of points b) and c) in a bit, but anyone volunteer to take writing this page on?
#1
More from greggles @ http://drupal.org/node/178773:
We should probably have a privacy policy about
1) what information we collect
2) what we might do with it
3) who can have access to it
4) what we'll do if we suspect that anyone has gained access to it who shouldn't have
Maybe there are more things we should have in there. This is just what came to my mind.
#2
If someone can provide the technical details, I can spend the time doing a write up.
#3
For update.module (I haven't had a chance to dig into drupal.module), here's how it works:
For project installed on the site, a request is made to a central update server (default is http://updates.drupal.org/, although other Drupal distributions could change this) which sends:
a) the name of the project
b) the current version of the project
c) a site key: a unique, scrambled hash of both the site URL (ex: http://example.com/drupal) and the site's private key, which is a randomized string (see drupal_get_private_key()).
An example of such a request:
http://updates.drupal.org/release-history/drupal/6.x?site_key=41d98b865c...
This data is collected and displayed to users in aggregate form (for example, how many sites have the X version of Y module installed) -- see http://scratch.drupal.org/project/usage. The site_keys of individual requests are never displayed. And because the site_key is a one-way hash (md5) of the site URL and *another* one-way hash, it is not possible to deduce what the originating site was even with this information.
References:
_update_refresh() : modules/update/update.fetch.inc
drupal_get_private_key() : includes/common.inc
#4
i think we ought to mention that we *might* store their ip address. i think it's really the only solution to this issue: http://drupal.org/node/168009
#5
The privacy policy for g.d.o should also include http://mollom.com/web-service-privacy-policy
We also now have a pretty regular process that removes (emails and IPs?) from the database backups and then share the data (at least for drupal.org) with other parties.
#6
Changed the component to reflect the new component categorization. See http://drupal.org/node/301443
-nielsbom
#7
Anyone want to work on this? Should we kick it to the Legal Eagles in the Association?
#8
I think, Dries should be the one leading this, as we shouldn't take this lightly.
Maybe the lawyers from OSL can help with this?
#9
BIG EDIT:
Misread thread...still, this is a year old, and a privacy policy should be well into place by now if you're going to offer a service to ping the servers with update info sending user info.
Something for the lawyers pronto I believe.
#10
@george2 - my comment in #5 was strictly about situations where the database is being used by someone doing work on the infrastructure (at the time, it was performance tuning and doing performance tuning is something where you want the real data in the real nodes of the site not something _like_ the data). That doesn't happen often and when it does it is scrubbed of all private data prior to being shared.
I believe all of the pingback data from the Update module is already anonymized using a hash of site specific variables rather than those variables themselves.
Also, the IP address where the requests comes from is always stored in Apache logs...but not necessarily in the DB.
#11
thanks for the reply greggles.
a definite answer needs to be determined, and relayed back to the end users in this crazy world of datalogging. :I
#12
George2 - it would be nice if you did some investigation work yourself instead of making demands on others.
In update module there are these lines:
$site_key = md5($base_url . drupal_get_private_key());
$projects = update_get_projects();
foreach ($projects as $key => $project) {
$url = _update_build_fetch_url($project, $site_key);
$xml = drupal_http_request($url);
So, the only information sent back are the IP of the incoming request (no way to get around that) and an md5 hash of the base_url concatenated with the site's private key (a random key generated when the site is first installed/used).
#13
bekasu has written up a general privacy policy, spurred by the docs team preparing to do a fair amount of surveying. I'm attaching it here for folks to review and revise, but obviously this needs the legal team to really have at.
#14
This reads as if it had been ripped somewhere... Could we actually use it?
#15
this feels like 10 bazillion words, when just a few hundred will do? it's very verbose. just my 2c
#16
special considerations for Google Adsense or other third parties?
Is the AUP really necessary in this document?
~silverwing
#17
I have to disagree with #14. This current document has very loose wording and even after going through the first couple of paragraphs it's noticable that the content isn't very accurate. Some examples:
"We ask you when we need personally identifiable information. Usually, this information is needed when you register, enter a contest, subscribe to e-mail newsletters, or complete an online survey." This isn't entirely true. You need to register to enter a contest or to subscribe to e-mail newsletters, and your information is required to register.
"You will have to provide your User ID and Password". Actually you need to enter your username and password.
"The use of this cookie allows you to visit other password-restricted portions of Drupal’s Web site — for which you have security access". What does "security access" mean in this context?
Our personal information is needed "[t]o help you quickly find information on Drupal software and contributed modules." How is our personal information required for this information? The documentation pages are available for everyone, as are the module project pages and the search-function. The forum is available for everyone. You do need to register to post comments although I do not consider this as a part of "quickly finding information".
Also since this is a privacy document I'm expecting information about the option to disable/delete my own account, or even just my own comments/posts.
All in all the document in its current state feels amateurish and vague, quite the opposite from what you'd expect from a privacy policy.
Also, do we really need to write Drupal.org and www.Drupal.org? Why capitalize the first letter when even the
<title>on drupal.org writes it in all lowercase.#18
@wmostrey: Exactly these non-fitting phrases make be think that this has been copied from elsewhere and we might have legal problems when using it.
#19
The legalese is considered boilerplate.
I got it from my brother, a contract attorney in Texas.
Since we weren't paying for services, he provided a generic version with simple wording and said 'you will need to change this to fit your specific site'.
He also said 'I assume your opensource group has legal counsel of some sort. That counsel will want to change it and make it their own.'
I went through it and tried to remove some of the heavy handedness on my own. I left in paragraphs that didn't seem relevant to me (e.g., contests), since I have so little history with Drupal. I don't know what you folks have done in the past, nor what you want to try in the future.
There seemed to be some confusion as to who should be authoring a privacy page.. Drupal or Drupal Association.
From my perspective, I just wanted something to cover our butts BEFORE we start actively, routinely surveying the community. There had been requests for this, but no action. So I took initiative to try to get something for folks to critique.
Unless there are any other concerns, I'd like to formally hand this over to 'the legal contact' along with these comments in this dicussion.
#20
why can't the lawyers at da sort this out? a copy/paste template with names changed just isn't professional, and could escalate a ton of problems later on down the road.
#21
At this point I think it's up to the Association and/or its legal counsel to sort out prior to publication; I'm pretty sure this has been brought to their attention.
#22
Then I'll volunteer to bring it to the attention of the Larry Garfield, the legal affairs director at Drupal Assocation.
Anybody have any problem with having them feed the privacy policy monkey?
bekasu
#23
I'm absolutely for getting the legal affairs department of the Drupal Association on this subject, yes.
#24
I've contacted Larry (Crell), but no response yet. I'll wait a few days and check with him next week.
As soon as we've made contact, I'll report back so we can change the status of this issue.
#26
Could it be that you uploaded the wrong version? This document is about Drupal documentation, not about the privacy policy.
#27
Let me try that again.
Here is the .doc version
I'm removing the above comment with the wrong file.
#28
tagging.