Composr Tutorial: Legal and social responsibilities

(Click to enlarge)

If you are running a website, in particular a large or corporate website, there are important legal and social issues that need to be understood, and procedures or rules need to be put in place.
We will summarise some laws (or broad patterns of laws) in this tutorial, although the particular laws that apply will vary based on where you are located, or have business interests – and it is impossible for us to consider everything. Ultimately businesses may have to seek legal counsel, or use the stated policies of an established business in your jurisdiction as a base for your own.

Rules

Privacy

There is a default privacy page (to hold a privacy policy), which should be edited to correctly detail all the personal data that you collect and/or process, either by request, or by automated means. The page should say every use for this data, especially when the data is available to people outside your organisation, or used actively within your organisation in a non-administrative sense (for marketing, for instance).

If you are a commercial entity, or if you hold sensitive personal data, you are more likely to be affected by privacy laws than others.
Such laws include, but are not limited to:

• The EU GDPR regulation (which is so broad it can almost be considered a superset of global privacy requirements, and is well-served throughout Composr)
• EU regulation required registering with a 'data commissioner'
• California privacy regulation (California Online Privacy Protection Act, California Consumer Privacy Act)
• US COPPA regulation (see the Child protection section)
• CAN-SPAM (see the Mail section)
• Other regulations on a state or regional basis

To further meet GDPR, Composr has many additional provisions, including:

• Logging of access to personal data in the action log
• Automatic log purging, configurable per-log
• Automatic scrubbing of old database records that contain personal data
• Ability to configure customised legal declarations for new users
• Automatic creation of a default privacy page that reflects an audit of what Composr privacy-affecting features are enabled, stock text to get you started

To meet GDPR you also need to consider:

• Web server logs also need to be purged. On Linux you can configure logrotate to do this.
• Backups:
  • You must have an internal documented policy for how long you keep backups.
  • Backup access must be restricted, and encryption may be a good idea.
• You may want to consider filesystem-level encryption, including of the database files, to prevent access to data if hardware is stolen.
• You should use SSL for your website, and any web services you rely on.
• You may need a webhost compliant with the 'EU-US privacy shield'.

The extent of your precautions will likely depend on the nature of personal data you hold (GDPR says: "shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk"). However, basic provisions are required for any website due to the storage of user IP addresses.

There is a "Do Not Track" HTTP that many web browsers allow their users to enable. If you want to support the header, then you can do so using the {$DO_NOT_TRACK_REQUESTED} symbol.

To meet Californian law a privacy policy must:

• State what you do with a "Do Not Track" HTTP header (Composr does nothing out of the box, mainly because we do not do cross-site tracking, and also because the standard is not well-adopted)
• State the date the privacy policy was written on
• State a described process for how changes in the privacy policy are communicated
• Provide at least 2 ways of contacting about privacy requests
• Provide a dated list of amendments
• Provide a 'Do Not Sell My Personal Information' link if you sell personal information

The first four items are included with the default privacy policy. Note there are thresholds that specify what organisations have to apply with certain Californian privacy law, which is outside the scope of this tutorial.

Management of Personal Data

Many laws require that a site operating in their jurisdiction enable appropriate tools for members to manage their personal data. The software employs a privacy system which allows both staff and members to manage personal data:

• Staff can download, purge (anonymise or delete), or generate SQL queries for, personal data based on various criteria (Admin Zone > Tools > Privacy).
• Members can download or purge their personal data on their member profile under Edit > Personal data (though purging in this way is disabled by default; many sites might not want members being able to purge their data on their own unless they are deleting their account).
• Members can also purge their personal data when they delete their account on their member profile under Edit > Delete.
• Staff can control to what extent members can download or purge their data from their profile (Admin Zone > Setup > Configuration > Privacy / legal compliance options > Members). This includes disabling the functionality completely or setting a number of days members must wait between downloads / purges. Where functionality is disabled, members will be instructed on their profile to contact staff if they want to download or purge their data.

The privacy purging system uses intelligence to ensure only data pertaining to the given individual is deleted or anonymised. Where the delete action is employed, if a record does not actually fully belong to that individual, their personal data will be anonymised on that record instead. Also, when downloading records, the system will anonymise fields in the downloaded records containing personal data which does not belong to that individual.

It is highly recommended you have enabled Use a task queue under Admin Zone > Setup > Configuration > Performance options. This is because downloading or purging data can be resource-intensive on a server.

It is your obligation to fulfill a member's request to download or purge their data in accordance with the laws of your jurisdiction. It is also your obligation to ensure, when requested, the personal data of members is also purged from server logs, backups, and anywhere the privacy system cannot cover.

Mail

Your site likely sends out e-mail. As such, you are probably subject to laws and regulations governing an e-mail recipient's right to unsubscribe from any or all e-mail at any time (e.g. CAN-SPAM) especially if you send out commercial or marketing material. Such laws may include required regulations such as the following:

• Define a 'List-Unsubscribe' header in every e-mail sent out; it must point either to an e-mail address one can contact to request unsubscription, or to a URL that can process an unsubscription request automatically.
  • For manual requests, you are often given a limited number of days in which you must fulfill the request (e.g. 10 days).
• Additionally include an Unsubscribe link in the body of the e-mails sent out (especially if they are commercial in nature).
• Unsubscribe pages might have to follow these regulations:
  • The page clearly indicates that the user is unsubscribing from e-mails sent by the site.
  • It allows recipients to unsubscribe without collecting any personal data (other than an e-mail address).
  • The process is fulfilled directly on that page (e.g. you cannot make users go through multiple pages to unsubscribe).
  • No commercial or marketing material on the page, and no calls to action.
  • The page must indicate that the process was successful, or give an error if it was not.
• If a confirmation e-mail is sent out, the e-mail must not contain any commercial or marketing material, nor can it contain any calls to action.
• After the confirmation e-mail, no other e-mail should be sent out under any circumstance unless the user explicitly re-subscribes.
• It is permitted to allow users a choice from what to unsubscribe. And it is expected their choices are adhered.

Composr has a couple built-in mechanisms to aid in compliance; and these work out-of-the-box without any configuration necessary. First, Composr has a global unsubscribe endpoint located at yourbaseurl/data/unsubscribe.php. This is a simple web interface that allows someone to unsubscribe from all e-mails sent by your site. And it only asks for an e-mail address (which is stored in a hashed format to protect the user's privacy). This acts as a low-level global blocklist; every e-mail sent by your site is checked against this blocklist in the mail dispatcher, and if an e-mail address matches, that e-mail address will not receive the e-mail (no matter what it is or its priority).

Composr also supports the List-Unsubscribe mail header. This can be configured with the 'List-Unsubscribe target' and 'List-Unsubscribe-Post data' options. By default, it points to the unsubscribe endpoint mentioned above (and also supports one-click unsubscribe from a recipient's mail client). But it can be changed if, for example, you use an external newsletter software for sending out e-mails. We generally do not recommend ever changing this; your newsletter software should have its own unsubscribe mechanism.

Additionally, Composr's newsletter system allows subscribers to unsubscribe from any or all newsletters while still receiving other e-mails (e.g. notifications). Newsletters by default contain their own unsubscribe link. And subscribers can change their settings through the site:newsletter module.

Removing an unsubscribed e-mail address

If a user who previously unsubscribed from all e-mails wants to be removed from the blocklist, you will need to do this manually. We intentionally do not provide an interface for it so that it is hard for malicious visitors or site staff to remove unsubscribed e-mail addresses. First, run this PHP code (such as in data_custom/execute_temp.php, or in Commandr):


This will echo a hash. Find this hash within the b_email_hashed column of your site database's unsubscribed_emails table, and remove the row. Or, run the following PHP code:

Accessibility

Potentially (under anti-discrimination laws) your website must satisfy the web-accessibility-initiative (WAI), web content accessibility guidelines (WCAG). Fortunately Composr complies to the highest level of accessibility under these guidelines (for all interfaces: user and administrator), which is rare, as the vast majority of web applications are not close to complying with the lowest level of accessibility.

As a site-maintainer however, there are accessibility guidelines that apply to content that the developers can not arrange-for on your behalf. Also, if you modify the default Composr templates, it is very easy to degrade the inbuilt accessibility.

For more information, see the accessibility tutorial.

eCommerce sales

If you use your website to drive 'electronic' sales, then it is likely there is legislation regulating your activities. In the UK, these are known as the 'distance selling regulations' and are essentially involved in making sure that adequate provisions are put in place to make up for the lack of personal communication that is inherent in a brick & mortar store.

Your website would, of course, also be party to legislation on all forms of business, including issues such as tax. International VAT/sales-tax is a particularly complex and situational-dependant topic, so I will not make any attempt to explain it here.

Liability

Unless you disclaim liability, you may be liable for problems caused directly or indirectly by you or your website. For example, if you allow users to get downloads into your database without having them screened for viruses, it is possible someone could try and hold you legally accountable if they were infected by a virus from software from your download database, unless you made it explicit that you disclaim responsibility for this.

Please note that it is not usually possible to disclaim liability for everything that might affect you.

Illegal content

You could be at risk of liability for harm caused to third-parties, particular in the areas of intellectual property.

Specifically:

• Intellectual property infringement:
  • Copyright infringement (unauthorised distribution of copyright-protected works)
  • Trademark infringement
  • Trade secrets
• State-banned material, such as secret documents, or terrorist manuals

Your responsibilities:

• You need to make sure you don't make any direct infringements yourself
• You need to make reasonable efforts to take down illegal content posted by users as you become aware of it. You are likely protected under "safe harbour" laws, but only if you do take reasonable measures to comply when you know of issues.
• You must be reasonable. You can't set up a site for 'warez' or 'file sharing', knowing that it is primarily being used for illegal content then hide behind the safe harbour laws. You can't claim fair use (e.g. parody) for large amounts of material that is clearly being distributed for direct usage.

Perhaps the best way to tackle content policing is a three-pronged approach:

1. Perform cursory checks to make sure submitted data is not illegal
2. Add member rules that prohibit uploading of illegal content
3. Disclaim liability for such content (while this would likely not work if your website became littered with illegal content, it is perhaps more defensible for exceptions)

Of course there is a big difference between highly criminal content (such as terrorist advice, if it is illegal in your jurisdiction) and minor civil-law-breaking content, such as unintended copyright infringement.

You may wish to add to your legal page that you disclaim liability for mis-use of registered trademarks, and that they remain the property of their respective owners.

Discussion of illegal activities

The advice for illegal content generally applies to the discussion of illegal activities also. There is, however, a fine line between discussing the merits of illegal activity and the incitement of it: this is very likely to be an issue on any active community, and you will need to consider how you will deal with it.

Libel

The advice for illegal content generally applies to the discussion of libel (defamation) also.

Government orders

It is possible that governments may make legal requests for you to provide data, or add government tracking systems.

Computer mis-use

It is likely that you will experience attempts to hack into your website by malicious users and 'bots' which automatically probe websites for vulnerabilities. Fortunately Composr is extremely sophisticated when it comes to 'hack-attack' detection, and will block, and log, these attempts. Composr provides a two-layer security approach: it is engineered to use secure practices, and proactively detects when its interfaces are being abused.

However, even with all this, there are 3/4 million (at the time of writing) lines of code that could potentially contain vulnerabilities. You therefore should keep backups, and if you run a high profile website, know how to attempt to track down miscreants and subject them to legal action.

If a vulnerability is found, the developers would like to know about it, and will deal with it promptly and responsibly, for the sake of all our users.

It is also possible that miscreants will attempt to use your website as a vehicle for mischief directed at others. There are not many ways to do this, and we know of no ways to cause serious abuses, but you should keep it in mind that it may be possible, and consider adding a disclaimer into your legal page for it.

Social

The sub-sections of this section briefly cover the main social issues you are likely to need to consider. By running a website with community features, such as a forum, or chatrooms, you are in essence making yourself or your team, community leaders, and therefore you hold the responsibilities that come with this.

Child protection

There are laws in various jurisdictions that provide special protection for children active on websites:

• The US has a law, COPPA that you need to comply with if your (US) website targets children under 13 for membership, or if you know that members of your website are under 13. More information on this law is available here from the COPPA website (see 'see also').
• The EU GDPR requires protection for children under 13/14/15/16 (the actual age varies by EU country).

For simplicity and historical reasons, we refer to any international child consent provisions as "parental consent" in the administration, and keep the language in the user UI vague.

If parental consent support is configured in Conversr, then when visitors try to join they will be added as not validated if they are too young, with a notice to send in a parental consent form to you via mail or fax.
In addition to Composr's parental consent support, you should also add your real-world contact details to your privacy policy, along with thorough details about what Custom Profile Fields may be filled in, how the information is used, how it is disclosed (if at all), and specification of various parent rights (which are listed on the COPPA or GDPR website).

In order to enable parental consent you need to turn on "Parental consent required", and configure your fax number and postal address.

Young members (or even older members) are often naive, as they have less experience of the world and often have lived relatively sheltered lives. Therefore you should actively protect these members from:

• inappropriate exposure of materials by other members (such as pornography or other sexual content)
• stalkers
• paedophiles

The Private Topic (PT) system (of Conversr) can be a particular hot spot. You need to develop a policy of whether you should moderate the PTs of (certain?) members to avoid issues such as online stalking, and you need to make this available in your privacy policy – usually this would only be undertaken at the request of the other (unwilling?) participant of the PT.

Free speech

Offensive content and moderation

It is unfortunate but inevitable that in most social climates, people will have strongly opposing views about what is appropriate behaviour. I have personal experience moderating forums, and know people may be explosively passionate about their views, and highly accusative of those who do not carry them.

Most opposing views are political in some sense, and usually related to the divide between traditionalism/conservatism/political-correctness and liberalism/free-speech.

You need to make three main decisions:

1. Are you going to reach a balance between extremes (if so, make some decisions on where the balance lies), or moderate against your-own or someone-else's personal/corporate views?
2. Are you going to define a level of what is 'appropriate' for your community, not based on personal view, but merely what you think your community should be allowed to discuss?
3. Are you going to limit discussion of topics related purely on relevance to a central topic?

These decisions more than anything will mould the feeling of your community and held you set specific rules and policies.

When it comes to moderation, the words 'freedom' and 'offensive' very often get carried around:

• if you moderate someone, it is likely they will accuse you of 'removing their freedom' (even though your website is not public property)
• if you allow someone to be offensive to others, they will likely accuse you of building a website that is a vehicle to propaganda or an agenda they disagree with

It is inevitable that you will be 'damned if you do and damned if you don't', so you need to be able to cope fairly with criticism.

Staying on-topic

Unless you are a government entity, true "free speech" is unlikely to be an issue – but users may still appreciate some level of unmoderated discussion. You will need to strike a balance between "freedom of discussion" and "staying on topic" that is appropriate to your particular website.

You should make a decision upon this:

• is it necessary to stick to discussing certain topics in certain places?
• or, should members be free to discuss whatever they wish anywhere?
• Or, will there be a compromise depending on circumstance and location

The answer is likely to depend on whether your community is primarily a social community, or whether it exists for some other purpose

Discrimination

You may wish to consider anti-discrimination clauses in your rules, possibly citing what you areas consider to be discriminatory (such as gender, race, appearance, and sexuality).

Abuse

You may wish to make rules and policies regarding abuse between members.

Personality types

As a community-leader, you should be aware that members of your community may have differing psychologies. It is actually likely that in many large online communities you could have users at extreme ends of various spectrums, and therefore you may wish to have policies in place to monitor such users in order to maintain a healthy balance, and protect the more vulnerable users.

With a basic awareness of psychology you may identify issues and be able to help people who may otherwise be isolated (someone very active online may be socially-isolated offline).

Handling feedback

You should develop a policy about how you handle feedback. This is of particular importance to commercial entities:

• will you leave negative feedback visible (possibly with a response, and/or closed to further responses) and possibly therefore allow publishing of negative views on your very own website?
• will you moderate negative feedback and be accused of suppressing the truth?
• will you consciously make sure there is no publicly visible outlet for negative feedback on the site, and remove any that is found for being 'off-topic'?

See also

• Advice for choosing and managing staff
• Children's Online Privacy Protection Act (wikipedia)
• Dos and Do-nots of a (Composr) website
• Running a newsletter

Feedback

Have a suggestion? Report an issue on the tracker.