| Xaraya | ML Luetolf |
| Request for Comments: 0027 | Xaraya Development Group |
| Category: Best Current Practice | November 2002 |
RFC-0027: EU Data Protection Compliant Users Module
This document specifies a Xaraya Best Current Practices for the Xaraya Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright © The Digital Development Foundation (2002). All Rights Reserved.
This RFC describes a possible Xaraya users module that complies with the EU Directive on Data Protection.
The proposed modifications to the current users module involve giving the user the ability to control how his/her personal data is displayed, and to remove his/her personal data from the site.
This document proposes certain changes to the Xaraya source code to make the users module compliant with the EU directive on data protection. This does not imply that Xaraya sites without these changes cannot comply with the directive. The changes proposed simply make it easier to do so, primarily by giving the users enhanced functionality concerning the data they submit.
The directive is quite complex and, depending on the type and purpose of the data collected, can be quite onerous. The changes proposed in this document purport to take into account common situations encountered by most organizations that will run Xaraya. With this in mind, what follows is a simplified summary of the major points of the directive that will be used to define the requirements of a compliant users module.
For special situations the directive in its entirety may need to be taken into account. The directive can be found here: http://www.privacy.org/pi/intl_orgs/ec/final_EU_Data_Protection.html
For the purpose at hand the directive distinguishes between the following subjects (we take subject to mean a natural or legal person):
The directive distinguishes between data collected from the user and data about the user collected from other sources. For our purpose only the former is relevant, i.e. data submitted by users registering on a site. The directive applies to any and all processing of personal data, with some exceptions. Exempted are a number of national or EU institutions themselves (!), and strictly personal or household uses of personal data.
The directive distinguishes between data collected from the user and data about the user collected from other sources. For our purpose only the former is relevant, i.e. data submitted by users registering on a site. While we can make a module EU compliant, this does not necessarily mean that any use of the module is necessarily legal in all cases. National legislation may supercede the directive. What may be allowed by the directive, e.g. processing of personal data "revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership" with the user's consent, may be prohibited by national law. Such considerations are excluded from this document.
Also excluded from this discussion is the obligation that a site may or may not have to notify a supervisory authority as described by the directive. [section IX]
The directive distinguishes between data collected from the user and data about the user collected from other sources. For our purpose only the former is relevant, i.e. data submitted by users registering on a site.
For the purpose of this document we will take the Controller/Processor to mean the owner of a Xaraya site, or any administrator of the site (as long as the administrator has the access rights to view, modify, delete or publish personal data). The Data Subject is any user that has registered and submitted personal data. The personal data is any information relating to the user.
Translating the above rights to a community oriented CMS environment, they can be summarized as:
The "processing" of user data for the purposes of this proposal can be defined as the processing that occurs in Xaraya's users module through the xarAPI. Compliance in this module will automatically extend compliance to any other module that uses the xaruserapi and xaradminapi functions of the users module.
Strictly speaking, the rights above go a bit further than the letter of the directive in that the user is not just given the right to object, but also the right to implement his/her objection (by unregistering).
EU compliant users modules are therefore solutions that implement these 3 rights. Two such proposals are described below.
Having been attacked in the press, P2 is opening a Xaraya site to convince the public that they're just a social club with funny hats and really not out to control the Italian government. Being something of a secretive organization, registrations will be vetted and the members' list is only accessible to registered members. Within the restricted members' area, however, information such as name, secret code name and ICQ number is made available to all fellow members. Members who resign from the lodge are keen to have their data removed from the site, so as to avoid possible future lawsuits.
As concerns consent and removal this is an all or nothing proposition. Those rights are applied to the user data as a whole.
No change required.
AC Milan, which has done quite well in the Champion's League lately, is opening a Xaraya site with up to date information about the Club and its players, including a feedback area. The members' list is public and contains such basic information as name and telephone number. The owner of AC Milan, Silvio Berlusconi, is also Prime Minister of Italy. While he is interested in getting feedback on what fans think about the Club and having his secretary field calls on his business number, he'd rather make his private number available only to the site's admins, to avoid crank political calls on the government's upcoming budget.
In this solution the functionality is applied to single data elements, rather than the user data as a whole. The site administrator can define a subset of the user data as mandatory. For this subset this solution is the same as the previous one (i.e. an all or nothing proposition). The remaining data fields are user optional. The user can define each of these fields as visible to the recipients or not.
The site administrator:
The user:
The possible recipients for user data depend on the visibility setting and are either administrators or users (="All Groups"). (see Open Issues D)
Add the following database fields:
Table xar_user_property:
Field Name Type Contains
xar_prop_mandatory boolean True = field must contain a non-null value
xar_prop_visible boolean True = field visibility can be set by user
Table xar_users:
Field Name Type Contains
xar_fields_visible varchar 255 1-dim array consisting of the xar_prop_id
of all xar_user_property fields set visible
The approach described above could be extended to include all user fields. This would mean merging most of the xar_users table fields (except: uid, username, pass) into the xar_user-property table, thereby allowing the admin complete freedom in deciding which user fields will be user optional.
In practice, however, this probably doesn't make sense. A minimum of mandatory user fields will always be necessary simply to make it possible to do something meaningful. The currently chosen fields seem to be a sensible minimalist choice (exception: url?) that will no doubt work in most cases.
When a user unregisters, his/her data can either be inactivated or physically deleted. Inactivation could be implemented through an additional boolean field in the xar_users table, which would be checked by the appropriate api functions in the users module whenever getting data.
Another approach would be to combine the inactivation with whatever variable (xar_active in xar_userblocks? [check this]) drives the visibility of the user in the members list, as they are really different aspects of the same property.
On the face of it inactivation complies with the directive (there would be no further processing of the data), and may be the wiser choice, as authorities will probably continue to put in place regulation requiring certain data to be archived for extended periods. On the other hand it isn't clear that Xaraya needs to address such requirements (rather than, say, the ISP the site runs on). The EU directive does not cover this area, and it is beyond the scope of this document.
Xaraya allows for the functionality that the user can be set invisible in user view. This flag could be redefined so as to allow or not the EU compliant functionality, i.e. allowing the user to define his/her user fields as visible or invisible. A separate EU flag could be also created. The latter is the preferred solution.
Rather than stipulate that the field xar_prop_visible be a boolean, and therefore the recipients are either admins or users, a more general solution would be:
Table xar_user_property:
Field Name Type Contains
xar_prop_visible integer xar_gid of the group that the property field
is visible to.
Table xar_users:
Field Name Type Contains
xar_fields_visible varchar 255 2-dim array consisting of the xar_prop_id
of all xar_user_property fields to be visible
and the xar_gid of the group each property field
is visible to.
If a group is deleted, any corresponding entries in xar_fields_visible must be changed to the xar_gid of the admins. The admins group cannot be deleted.
Creating an easy to use interface for this solution would be more complicated, as it probably involves either a scheme with multiple dropdowns or having the user input a list of group names (with the appropriate parsing for errors).
While situations can be imagined in which this functionality might be useful, they probably won't apply to the majority of Xaraya sites.
The DDF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the DDF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC-0.
The DDF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the DDF Board of Directors.
Funding for the RFC Editor function is provided by the DDF