Skip to main content

User Privacy v1.0

This document is intended to promote public understanding of user privacy & explain where there is currently consensus about what is best practice for ISPs when dealing with matters of privacy on and around the Internet.

Version 1.0, 15th May, 2001

CONTENTS

  1. Introduction
  2. Disclaimers
  3. Overview
  4. General principles
  5. Confidential information
  6. User details
  7. Logs of calls to the Internet
  8. Logs of actions on the Internet
  9. Approaches by Law Enforcement
  10. Approaches to Law Enforcement
  11. Documenting privacy policies
  12. Techniques for enhancing privacy
  13. Glossary
  14. References and resources
  15. Contributors

1. Introduction

The privacy of Internet users has always been of importance to both users of the Internet and those organisations that provide them with access. As the Internet becomes ever more central to communications, that privacy becomes ever more important. Failure to provide privacy for people's use of the Internet will become equivalent to exposing those people's entire lives to public gaze. Practices and procedures are needed throughout the Internet industry to ensure that privacy is designed into systems at every level.

Inevitably, as all types of activity start to involve the Internet, some of that activity is criminal and unacceptable to society. Naturally this means that Law Enforcement Agencies are also becoming involved with the Internet. For the police and other authorities to be able to continue to act on behalf of society, it is necessary for them to be able to relate events in "cyberspace" back to identities in the "real world". For this to happen there will, of necessity, be some retrieval of otherwise confidential information and some examination of private actions.

Since this is a new area for everyone involved, there are not centuries of tradition to fall back upon to decide how privacy should be handled in the online world and how it should be balanced against other priorities for our society. It is possible to argue by analogy, but analogies can be deeply flawed. It is possible to argue from first principles, but this requires a depth of knowledge and an analytical approach that few can muster.

To put it another way, we do not yet understand all the privacy issues that will arise on the Internet. We do know that privacy requires constant vigilance to protect it and that assumptions that hold true in other areas will not necessarily apply online.

This document is intended to promote public understanding of the issues and of the solutions that are emerging. In particular it explains where there is currently consensus about what is Best Practice for ISPs (and also for users) when dealing with matters of privacy on and around the Internet.

Back to top

2. Disclaimers

  • This document should not be read or understood to constitute legal advice. It is simply indicating what "Best Practice" might be.

  • This document was written in 2001, taking into account the laws, regulations and best practices in the United Kingdom. It may be applicable to other times and places, but readers are cautioned that without consideration of local differences it may not turn out to travel well.

  • This document does not discuss whether messages sent over the Internet or other actions performed using the Internet may or may not be illegal. For a discussion of the issues that arise in this area, the LINX "Best Current Practice on Handling Illegal Material" should be consulted.

Back to top

3. Overview

The basic principles that underlie this document are set out in Section 4 and there is a discussion of the concept of confidential information in Section 5. Section 6 discusses the type of information ISPs hold about users, section 7 the type of information they will hold about telephone call access to the Internet. Section 8 discusses the type of information that ISP systems will hold about particular services such as email. Section 9 discusses Best Practice when Law Enforcement Agencies approach an ISP and Section 10 deals with Best Practice when the ISP is making the approach. Section 11 deals with the way in which ISPs should document their privacy policies and Section 12 deals with types of techniques that users can employ to enhance their privacy. Finally, appendices give some supplementary information including a glossary and some pointers to related information.

Throughout this document, much use is made of the term "ISP", which stands for Internet Service Provider. It should be taken to mean not just those companies that call themselves ISPs, but any organisation that makes Internet access services available to independent customers.

ISPs can have several other roles. They may be providing "content" (running a web site for example) or providing e-commerce services. These give rise to rather different privacy issues, which are not deeply examined here.

The term "user" is also used throughout this document as a generic term to cover not only the situations where there is a formal, signed, contractual relationship between an individual and an ISP but also to other cases where someone may be using an ISP's facilities and services.

There are other ways in which individuals can obtain Internet access, for example students may use facilities provided by their educational institution or employees may be able to access the Internet at work. The relationships in these cases are not the same as the ISP/user relationship. Although much of this document may be of interest to such people, particularly when considering basic principles, they should look elsewhere for specifics of relevance to them.

Back to top

4. General principles

All of the commentary and Best Practice procedures within this document are based on a small number of straightforward principles.

4.1 Respect human rights

There are a number of international conventions setting out the fundamental rights and freedoms of individuals. In particular, the 1950 European Convention on Human Rights (ECHR), the 1981 Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data, the 1995 EU Directive on Data Protection and the 1997 Directive on privacy in the telecommunications sector.

The first principle is that ISPs must respect human rights and in particular they must respect the right to privacy with respect to the processing of personal data.

4.2 Obey the law

The second principle is that ISPs must obey the law of the land.

The Human Rights Act 1998 incorporates the ECHR mentioned in 4.1 directly into UK law. Article 8 is of particular note since this deals with an individual's right of "respect for his private and family life, his home and his correspondence". The issues surrounding Article 8 are expanded upon below.

The Data Protection Act 1998 sets out a number of relevant requirements relating to the holding and disclosure of personal data. These requirements will be discussed in various sections below.

The other laws of particular importance to this document are those relating to access to information, usually under warrant, by police officers and others with statutory authority. Specific reference will be made to the Police and Criminal Evidence Act 1984 (PACE) and the Regulation of Investigatory Powers Act 2000 (RIP).

Although the Internet crosses boundaries between jurisdictions this does not change the principle that the law to be obeyed is the local law. Other countries may have different regimes, but it is still necessary (and usually sufficient) for an ISP to obey the law of the country in which they are operating. However, whilst developing their Best Practice, ISPs should take into account supranational and regional policies and developments that may impact their laws in the future. In particular, UK law is continually being brought into line with EU Directives, so it is wise to consider their provisions at an early stage.

4.3 Publicise privacy policy

The third principle is that users must be told the details of an ISP's Privacy Policy. This is discussed in more detail in section 11 below.

The Data Protection Act 1998 requires that individuals should be aware of the identity of the legal person obtaining information about them, the uses to which this information will be put, the disclosures that will be made of it and the subsequent uses thus made. The individual should also learn of anything else relevant that, given the circumstances, will make the processing of their information "fair". Failure to provide all of this information is a contravention of the First Data Protection Principle of the Data Protection Act.

4.4 Enhance privacy wherever possible

The final principle is that users are entitled to take steps to augment the privacy available to them. For example, use of "end-to-end" encryption should be encouraged, so that users' privacy will not depend upon intermediate systems being secure.

It is Best Practice for ISPs to educate their users as to what software and procedures are available for privacy enhancement and for improving system security generally, and there is more about this in section 12.

Back to top

5. Confidential information

English law has protected confidential information since at least the middle of the nineteenth century. The courts may grant an injunction to restrain a threatened breach of confidence, and may in some cases award damages for a breach.

The modern interpretation of the law of confidence is that unauthorised use or disclosure of information is a breach of confidence if:

    1) the information is of a confidential kind
and 2) it was obtained in circumstances requiring it to be treated as confidential.

5.1 Information that can be considered to be confidential

Information will be of a confidential kind if it is of limited public availability. Where a user has published some information (for example by posting it in a message to a publicly accessible newsgroup or including it in a generally accessible web page), it is reasonable for an ISP to treat that information as non-confidential. However, this would not be the usual situation for the much of the information that an ISP holds about a particular user.

There is a further test for information to be regarded confidential, in that it must be capable of clear definition or identification. A court would use this test when considering matters such as an injunction to prevent the disclosure of confidential information. The information held by ISPs would clearly meet this test and therefore part (1) above would be met.

5.2 Circumstances that require information to be treated as confidential

The circumstances requiring information to be treated as confidential may arise in several ways. There may be an explicit contract to make the duty of confidence clear, but it can also arise in other situations of trust where no contract is present. A duty to keep information confidential may also be imposed upon a third party who receives information which he then knows or later discovers was disclosed to him in breach of confidence.

Many relationships have been recognised as automatically imposing a duty of confidentiality on the recipient of communications within them. Examples include communications between doctor and patient, client and lawyer, banker and customer or client and accountant, as well as marital communications, the secrecy of the confessional, and a journalist and his source. Most of these examples of confidential relationships come from the common law, but in some cases their special status is reflected in statute law as well and is recognised in international law.

5.3 Do ISPs have a duty of confidence to their users?

No case has yet arisen in which a court in the UK has had to decide whether the relationship between an ISP and a user imposes a duty of confidentiality on the ISP. There are very strong arguments that suggest that it does.

The UK has for many years recognised the right of individuals to the privacy of their correspondence, as laid down in the European Convention on Human Rights. This right has been held to apply to all forms of communication including electronic mail. In addition the 1997 EU Directive on privacy in the telecommunications sector contains explicit confidentiality and privacy provisions.

Unauthorised interception of mail or telecommunications over public networks, and the disclosure of private information about such mail or telecommunications, have been serious offences in the UK for some time. The RIP Act 2000 extended the previous regime to cover the private networks that form part of the Internet. The new Act also makes it clear that email is covered by its provisions. The previous Act, IOCA 1985, did not cover email explicitly.

Since breaching confidence would be a serious matter, it is undesirable for there to be doubt as to whether the relationship between an ISP and a user is, like those mentioned above, a confidential relationship. Accordingly, it is Best Practice for ISPs to recognise explicitly in their terms of service, or within their privacy policy statement, that the relationship between a user and that ISP is a confidential relationship.

The matters that the ISP is bound to treat as confidential include:

  • Customer details - the name, address and other communication details of the user or others using the user's account

  • Billing details - information about the user's banking or credit card arrangements.

  • Payment records - payment history and other matters relating to the operation of the user's account.

  • Traffic data - the source and destination of all communications received and sent by the user.

  • Content data - the content of all communications sent and received by the user.

  • Logging data - information about the use made by the user of the services of the ISP.

5.4 Disclosing confidential information

There are two ways in which the use or disclosure of confidential information by an ISP will not amount to a breach of confidence.

The first is where the use is expressly or implicitly authorised by the user. The second, exemplified in the old maxim "there is no confidence in iniquity", is where the nature of the information (or other circumstances) mean that the court will refuse to provide any remedy to someone complaining of a breach of confidence.

5.5 Authorising the release of confidential information

ISPs will wish to use some of the information they hold. They may, for example, wish to use some of the information they hold about a user to ensure that they are paid their due, perhaps by passing it on to a Debt Collection Agency.

It is Best Practice for the ISP's terms of service to explicitly address this point and require the user to authorise usage to allow an ISP to enforce their rights. The authorisation should also allow information to be disclosed to third parties where it is strictly necessary for this purpose.

It would also be Best Practice to make it clear that the content of communications (and their source and destination) were not included amongst the information that might be used in this way.

Sometimes there are several people using a single account. This is often the case where a business is operating the account, but it can occur in other circumstances as well. In such a case it might be argued that this information was confidential to particular users. An ISP is unlikely to be aware of the true situation, and to avoid the complexities that this will engender, it is Best Practice for an ISP to make it clear that they will treat information about the account as if there were a single user. It is also Best Practice for the ISP to explicitly require the account "owner" to make the situation clear to any further users of the account.

5.6 Releasing information on the grounds of "iniquity"

For an ISP to justify a disclosure on grounds of "iniquity" may be highly problematic. Although it has been said that there is no protection for illegality, gross immorality or even conduct contrary to public policy, the courts have acknowledged the uncertain scope of these concepts.

For example, in 1988 a court held that disclosure of the details of a lesbian relationship involving a married woman could not then be said to be the disclosure of gross immorality, whatever view might have been taken in earlier times.

The courts have refused to restrain an employee of a financial services company from disclosing regulatory breaches to its regulator or accounting irregularities to the Inland Revenue (in circumstances where the regulator and the Inland Revenue already had powers to demand the information). The courts have also held that they had a power to require the disclosure of confidential information to a victim of wrongdoing where that information was in the possession of a person innocently caught up in the wrongdoing.

5.7 Releasing confidential information in response to requests

Where a user has not given permission to release information, the case law relating to "iniquity" is so complex and contradictory that an ISP would be well advised to have the protection of an order of the court before disclosing confidential information. This order would also tackle Data Protection issues, since there would be a concern that the disclosure of the information would contravene the requirements of the First Data Protection Principle.

An ISP will rarely be in a position to come to a well-informed conclusion about whether confidential information in its possession can in fact be disclosed without the risk of an adverse finding in court. It is likely to be particularly hard to predict the legal outcome where there is a dispute about the facts of the matter or about the effect of the law in contentious circumstances.

Therefore, Best Practice is to refuse to release confidential information without an order of the court, unless legal advice is categorical and unqualified to the effect that the information can be released on the grounds of "iniquity". This is unlikely to occur often. Accordingly, it is Best Practice to insist, from the start, that those seeking access to apparently confidential information should obtain the authority of a court for its release.

Unless the court forbids the ISP from informing the user, it is also Best Practice for the user to be informed, in confidence, that an order is being sought so that they have an opportunity to resist the making of any such order. Since the ISP is not looking to the court to block access but would like it to formally examine the circumstances, it would seldom be appropriate for an ISP to oppose the granting of such an order.

Two circumstances further support the appropriateness of concluding that an order of the court should always be required:

The first is the practice of bankers, professional people and the broadcasting organisations. Bankers and members of the professions will always require the authority of an order of a court for the disclosure of confidential material, with rare statutory exceptions which are themselves closely circumscribed (for example, for money laundering). The broadcasting organisations will provide the authorities with copies of broadcast material without restriction; but without an order of the court they will not release material that has not been broadcast.

The second is the way in which the previous law on the interception of communications was extended to ISPs and the provisions of the RIP Act with respect to communication data. The RIP Act establishes a proper legal basis for demands for certain user information. The existence of legislation may be seen as a clear acknowledgement that without a proper legal basis, disclosure cannot reasonably be expected from ISPs.

Back to top

6. User details

An ISP will hold contact information for its users. This will usually include a name, address and one or more telephone numbers. There will be an account history, containing details such as how and when the account was opened. There may be payment details and some sort of credit history. Some ISPs will have asked for demographic information such as age, hobbies and interests.

Where the user is an individual or a sole trader (rather than a company) these details will all be "personal data" within the meaning of the Data Protection Act. The ISP may find it necessary to notify the Information Commissioner of their role as a data controller, although under the 1998 Act there are widespread exemptions. Where an ISP is going to disclose the information to other organisations then this must be included in any notification. Where an ISP can reasonably foresee the need to disclose the information to other organisations such as the police then it is Best Practice to record these possible disclosures as well. However, when disclosures under S29(3) of the Data Protection Act are proper, then these can be made even when this type of disclosure was not documented.

In order for personal data to be obtained fairly, the user must be aware what it is to be used for. If some part of the information that is collected by an ISP is not going to be used to provide the service, but for marketing or profiling reasons, then the fact that the provision of these items of information is not obligatory should be made clear.

ISPs may also hold "communications data" that gives details of users' telephone calls and their use of the service. These topics are separately discussed in sections 7 and 8 below.

It is Best Practice for all types of data collected by an ISP, and all the types of disclosure that may be made, to be documented in a privacy policy. This is discussed in Section 11.

6.1 Data Protection Act requirements

The Data Protection Act 1998 places a number of requirements upon the holders of personal data. These can be quickly summarised as requiring data to be:

  • Fairly and lawfully processed;

  • Processed for limited purposes;

  • Adequate, relevant and not excessive;

  • Accurate;

  • Not kept longer than necessary;

  • Processed in accordance with the data subject's rights;

  • Secure;

  • Not transferred to countries without adequate protection.

Full details and a great deal of explanatory material and advice can be obtained from the Information Commissioner. This material is also available on the Internet at: http://www.dataprotection.gov.uk/.

ISPs that are members of the Internet Service Providers Association (ISPA-uk) should note a special provision within the ISPA Code of Practice. This requires that when notifying the Data Protection Registry the paperwork must state that the data may be used for regulatory purposes and that ISPA-uk is a potential user of that information.

ISPs sometimes include in their registration a statement indicating that a possible use for data is to supply it to law enforcement. Such transparency is useful, but the statement should be qualified by listing the relatively limited circumstances when law enforcement's requests can be considered to be valid. There is much more about this in section 9 below.

6.2 Usage of user details

There is nothing unusual about an ISP holding user details; it is the sort of data that most businesses hold about their customers. The information will be used for obtaining payments, answering customer support queries, proactively supplying information to users about new or changed services and for general marketing purposes. The processing may need to be notified under the Data Protection Act and the ISP will need to state the purposes for which the data will be used. It is Best Practice for an ISP to conform to the Act by documenting, on their corporate web site, what data is collected and the purposes it will be used for.

Some people have an objection to receipt of "junk mail", by which they usually mean the unexpected arrival of advertising material on their doormats. Almost everyone objects to similar material arriving by email. ISPs should carefully distinguish between an operational need to contact their users, perhaps advising of some change in the service provided, and a marketing communication that just attempts to make the user aware of a new service. It is a Data Protection Act requirement to allow users to choose, at any time, to opt out of receiving marketing information whether by traditional post or by email. There are also similar rights not to be contacted involving global opt-out lists for telephone calls and faxes in the Telecommunications (Data Protection and Privacy) Regulations 1999.

User databases have value to other organisations that wish to use them as a marketing resource. However, if the ISP wishes to share personal data with third parties for this purpose then this will need to be recorded in the Data Protection Register and the Data Controller will need to "notify" accordingly. The ISP must make clear to the users that personal data may be passed to third parties and must give users the opportunity to opt out. This opt out is usually done by a checkbox on a web page or other sign up form. It must be possible for a user to opt out at any time, not just when the data is collected.

6.3 Sensitive data

It would be unusual for ISPs to have any need to hold or collect "sensitive data" as defined in the 1998 Act. Sensitive data includes racial origin, political opinions, religion etc, and special considerations apply to its processing. It would be Best Practice for ISPs not to collect any sensitive data.

Where such information is available by inference, for example if a ISP markets itself as the provider of choice for a particular political party, then it is Best Practice to obtain the explicit consent of the individual to hold and process any personal data to which this inference might apply.

6.4 Recognising users

ISPs regularly deal with their users by telephone, letter, fax and email and act upon their instructions to open, close or alter their accounts. It is common to handle cases where passwords have been forgotten and must be reset.

It is important for an ISP to be sure that they are communicating with their user and not with an impostor. Impersonation can lead to private user details or private communications becoming available to third parties who are not entitled to see them. Failure to deal with this issue may amount to a failure to comply with the security requirements of the Data Protection Act.

Since users will not be known to the ISP personally, other methods of verification of identity will be needed. Companies may be able to identify themselves using headed notepaper. Signatures on letters can be compared with material already in a file. Email can be checked to ensure it was posted from the user's account - and hence the account password must have been known. Users can be asked to provide code words or obscure information when their account is set up, and these can be asked for later on. It is rather common for organisations to treat "mother's maiden name" as obscure information, though this can be fairly widely known, and should be regarded as a poor choice. A good scheme is to request some information (e.g. "Mitzi") and an accompanying prompt (e.g. "what was Granny's cat's name"). If the customer forgets the information then the prompt can be used to allow it to be remembered.

It is Best Practice for an ISP to have clear rules for staff to use in determining whether a user has identified themselves sufficiently for a change of account or disclosure of information to be made. Staff should be encouraged to resist "social engineering" and not to prompt users too much or to hunt amongst multiple questions for the one that a user can answer.

The rules should also forbid staff from making unauthorised accesses to records and staff should not have any access where this is not necessary. It is also Best Practice to be able to audit systems in order to determine if unauthorised access has in practice occurred.

6.5 Dealing with ad hoc requests

ISPs must expect to get ad hoc requests for information about their users. These may come from members of the public, other ISPs or from law enforcement agencies. Since user details should not be divulged, it is important that staff who are likely to receive such requests should be aware of the way in which they should be handled. It is Best Practice for ISPs to have a formal code of conduct for staff that forbids the unauthorised disclosure of personal details about their users to third parties.

It is also Best Practice to cover this issue in the training of staff, mentioning, in particular, the type of "social engineering" by which skilled enquirers can extract information that should not be disclosed. Staff who know that a polite but firm refusal is the correct response and who know that their supervisors and managers will back their "unhelpful attitude" will be best able to protect the privacy of the ISP's users.

As will become clear below, requests for user details from other ISPs and law enforcement agencies will require, in general, some form of court order or warrant before they can be complied with. Since it is complex to verify that everything in such a notice is in order, it is Best Practice to refer all such requests to a specialist group, rather than trying to train all of an ISP's staff to be able to handle this type of request.

Back to top

7. Logs of calls to the Internet

Although permanent connections to the Internet by means of leased lines, ADSL or cable modems are becoming more common, most users still access the Internet on a temporary basis by means of a telephone call. The equipment and servers purchased by ISPs is equipped, as standard, with the ability to create logging information of these telephone calls. ISPs require this information for many different purposes, as is discussed below.

7.1 What is logged

Exactly what information is logged will vary depending on the equipment or server used, but usually includes:

  • a session identifier (used to tie separate records together)

  • access equipment port details

  • the connection speed

  • a pre-session duration (before the logging was invoked)

  • the date and time of the start (or end) of the connection

  • an account identifier or username

  • the caller line identification (CLI) provided with the call

  • the IP address used by the user

  • the IP address of the network access server

  • the first destination IP address (often a domain name (DNS) server)

  • what caused the call to end

  • the total traffic transferred in each direction

  • distribution of packet sizes

The various purposes these logs are used for are discussed below.

Many of these uses require only some of the stored information. Therefore it would be Best Practice for ISPs to discard those parts of the information that they do not require. However, equipment vendors do not make this especially easy to do. ISPs may find it hard to justify the cost of the processing to discard some of the information "early" before the rest of the logged information is expired or anonymised. Thus it is quite common to keep the logs in a raw format and extract reports from them as may be necessary. Fortunately, most of the information that is not normally required is of limited sensitivity compared with the information such as account, time, IP address and CLI that will almost invariably be needed by the ISP.

7.2 What the logs are used for

The logs are used for

  • Billing

  • Service Features

  • Account dispute resolution

  • Troubleshooting

  • Usage analysis

  • Prevention of abuse

Taking each of these in turn:

7.2.1 Billing

There are a number of different charging models for Internet access in the UK. Some ISPs charge by usage, often with a certain number of hours for a flat rate charge and then with an hourly charge after that limit has been reached. These ISPs clearly require usage records so as to be able to levy the correct charge upon their users. The user is likely to want access to logs of their usage in order to check how much has been spent during a charge period.

7.2.2 Service features

Regardless of whether call-logging records are used or necessary for billing, an ISP may choose, as a feature or benefit of its service, to provide call records for the exclusive use of the user. In this instance it is Best Practice for the user to be made clearly aware that such data is being held and have the option for the information to not be made available, or perhaps only the most recent information made available e.g. the last two months.

7.2.3 Account dispute resolution

If there are billing disputes regarding usage based charging, then it will be necessary to refer to the logging information. The user is also likely to want to see copies of the log entries.

Even if there is no usage based charging, any sort of charge may be disputed and proof of the use of an account can be important. For example, if an invoice is issued for the renewal of an annual charge it can, on occasion, take several months to chase the debt. If the user maintains that the account is no longer wanted, usage records can prove that it is still being used, and indeed CLI information can demonstrate who is using it.

7.2.4 Troubleshooting

As indicated above, call logs provide information about pre-sessions (how long it took to connect), connection speeds (indicative of line and modem quality), disconnection codes (did the ISP or the user end the connection) and the quantity of data passed in each direction.

The ISP can examine this type of data to help solve individual user's connection difficulties. This type of analysis clearly needs the user identity to be present in the logs.

In addition, the call logs can show information about the performance of a particular connection server or an individual port on that server. An analysis of this information, e.g. one that showed the average connection time to be very short, can quickly lead to the diagnosis of a faulty port. This type of analysis does not require the user identity to be present within the logs, and can be done on anonymised data.

7.2.5 Usage analysis

In running their businesses, ISPs may wish to monitor usage patterns e.g. how does the weather/major sporting events/bank holidays/eclipses/elections affect the usage of their services. Call logs may be used to achieve this.

It may be appropriate to compare usage patterns to previous periods over many months or even years. It is not necessary or appropriate for ISPs to know the usage behaviour of named account users to achieve this, but it may well be necessary to compare usage patterns of a particular person over a short period. It is Best Practice to anonymise data that is to be held for very long periods. Suitable techniques are discussed in section 7.4 below.

7.2.6 Prevention of abuse

On occasion, use of the Internet is abused. Abuse takes many forms from the bulk sending of unsolicited email through to attacks on the integrity of a third parties network or machines. ISPs are under an obligation to prevent abuse by their users and to take appropriate action to protect the Internet as a whole, as well as their own systems and services. The Internet functions because the owners of many different private networks are prepared to carry each other's traffic. If an ISP fails to prevent further abuse then that co-operation can cease, which can lead on to very serious consequences for the ISP's business.

When abuse occurs it is necessary to determine which user account was responsible. The LINX Best Current Practice document on "Traceability" should be consulted for a full discussion on how this might be done. At heart, the process is to determine which user account was responsible by comparing the details recorded for the abuse and checking these against the ISP's call logging data, which will contain relevant identification information. Tracing the perpetrator of some forms of abuse can be complex and it will be necessary to consult other logged data as well.

Once the account has been identified, the ISP will take suitable action, which will often be as simple as suspending use of the account. It is Best Practice for ISPs to have an Acceptable Use Policy (AUP) that indicates what type of activity will be considered abuse and what action will be taken for a breach of the AUP.

7.3 Length of time logs are held

Logging information that has been anonymised can be held indefinitely without any privacy implications at all. However, anonymous records are not suitable for many of the purposes for which logs are necessary. When considering how long data may be preserved, a balance has to be struck between the operational necessity and privacy.

The Data Protection Act makes it clear that the basic position is that personal data (and non-anonymised logging data is certainly personal data) may only be held for specific purposes and for an appropriate time to meet those purposes. Therefore it will be for each individual ISP to determine why they are keeping non-anonymous logs and, having established the purposes, determine the appropriate time period to hold the information. Once that time has been reached the logs will need to be destroyed or anonymised.

Besides the Data Protection Act itself, the European Directive "97/66/EC - Telecoms Data Protection Directive" gives some further indication of how long call logs should be held if they are needed for particular purposes. The relevant part of the directive has been implemented in the UK by means of Statutory Instrument 1999 No. 2093 "The Telecommunications (Data Protection and Privacy) Regulations 1999" and this should be consulted for the exact legislation.

It is Best Practice for ISPs to formally review what data they are collecting and how long they need to keep it for.

In outline, a typical ISP will find that for most of the operational purposes for which logging data is required the raw data will cease to be relevant after about three months. Logging data that is specifically held to allow for investigation of abuse issues may need to be preserved for a little longer, because some types of abuse may not come to light for some time after the event for which logging is relevant.

Access data may also be needed to resolve billing issues, since it is not uncommon for customers to claim that accounts are not being used and refunds of subscription amounts are therefore appropriate. Although this is a reasonable purpose for which to hold relevant information it does not mean that all possible logging information needs to be kept for this purpose. In particular, it may be sufficient to just retain the date or hour of a call, an indication if the call was long or short and only a small part of the CLI information.

UK Law enforcement agencies have recently expressed a wish to see access logs being held for many years. Little heed seems to have been given to privacy and whether this could actually be achieved or where the costs might fall. Practical realities aside, this wish is not consistent with current Data Protection legislation or with European Directives. Data may be preserved for an appropriate period for a business purpose. It is not a business purpose to preserve data because there is a possibility that law enforcement might wish to inspect it. Therefore, data must be destroyed or anonymised once it is no longer needed for business purposes.

7.4 Anonymising logging data

When creating anonymous forms of logging records it is important to ensure that the records are truly anonymous and the process has not merely obscured the identity of the caller from a casual enquirer.

Where possible, information should be summarised and the original records destroyed. Where summaries are unsuitable then removal of all identification information (account name, CLI etc) will of course produce anonymous records. This would be the system of choice, except that it does not allow usage patterns to be analysed because it is impossible to answer questions like "how often do users connect to the service".

A simple scheme is to anonymise the data by allocating identity #1 to the first caller of the week, #2 to the second etc. This will allow usage patterns to be analysed, until the identities are reset at the end of the week. However, it may still leak identities if some users call very often, or always call just after midnight at the start of the week.

Techniques that involve one-way encryption functions may prevent the processed data from directly identifying a user, but they do not anonymise. If more data can be processed through the same function then it is possible to determine which user is which. The only way to make this type of scheme immune to reversal is to include a randomly generated key as part of the one-way function, and to discard all details of the key once the processing of the datafile is complete.

However, all replacement identity schemes will have the same problem. If some extra information is available (perhaps the exact time of a single call, or some other specific and unusual property of a particular user's set-up) then it may still be possible to determine the identity of some users within the "anonymous" data by seeing which identity matches.

De-anonymising by the matching special values can be made considerably more difficult if the data has been processed in various ways. Changing the precision to which information is recorded will ensure that more people's data will have the same values. Adding a random "fuzz" to values will also make it harder to match information with external information. In both cases, it is possible to alter the records without affecting the statistical significance of the data.

Since ISPs will usually have a great deal of information about calls, it is not necessary to keep all of it and this leads to a very powerful anonymising technique. Identities can be supplied to the first caller, second caller as before. However instead of keeping all of the data, a small (but statistically significant) random sample is selected and the rest of the records are destroyed. Now, not only is the resulting data anonymous, but the markedly reduced likelihood of finding a particular user's information within the preserved data will make it highly unlikely that any attempt would ever be made to de-anonymise it.

Back to top

8. Logs of actions on the Internet

Most ISPs will usually log nothing whatsoever about any actions or data passed during an individual Internet session. This is due to the vast volume of data that would be stored and the difficulty in analysing that data.

ISPs are quite likely to capture and process information about the usage of their individual servers such as mail, news and web servers. In this, they are acting no differently from any other Internet content provider.

8.1 Logging on mail servers

Mail server logging typically records the source and destination of email. It will not have any details of the content or even header information such as subject line. These logs are used for diagnostic purposes when email appears to have gone astray or has been delayed on its journey.

The source and destination records can also be used for tracking down the true origin of bulk unsolicited email (commonly known as "spam").

Summary information will be produced for management purposes. This will be almost entirely anonymous.

8.2 Logging on news servers

News server logging will always be summary information - the sheer volume of any other records means that nothing else would be useful to an ISP. If detailed usage pattern information is required then it is Best Practice to ensure that this information is immediately anonymised.

8.3 Logging on web servers

Web servers are usually configured to log all page accesses against the requesting IP address along with some other useful information such as the referral page which brought the user to that site. This information is used by webmasters to understand page popularity, navigation difficulties experienced by users and indeed which remote sites have out-of-date references to pages that have now been removed.

8.4 Special case logging

Even where services are configured to record very little information, it may be the case that unusual events such as errors or failures will record very detailed information about what was occurring. System administrators will use this information to fix the system. It is Best Practice to destroy this information as soon as the fixes have been deployed.

8.5 Processing server activity logs

As was discussed in section 7, if server logs are anonymised in a non-reversible manner then privacy issues will not arise and the length of time that data is held is irrelevant.

However, where a service forms a significant part or the whole of a service e.g. a mail service such as Hotmail or a news service like Supernews, then it may be necessary to store some information for resolving user service issues. It is Best Practice to analyse the actual requirements carefully and to develop log-processing programs that discard unnecessary information. Where information must be kept then consideration should be given to summarising it rather than keeping excessive detail.

Back to top

9. Approaches by Law Enforcement

From time to time, ISPs are approached by Law Enforcement Agencies (LEAs) who are seeking assistance in investigating a crime. These agencies may be the police, customs and excise or such bodies as Trading Standards who have a power to demand information under S29 of the Consumer Protection Act 1987. The ISP industry is working with the LEAs to set up a "single point of contact" (SPOC) system. Once this is in place it will be Best Practice to insist that all requests be made through the SPOC system.

9.1 Statutory authority

Personal information held on computer systems cannot usually be divulged without infringing the provisions of the Data Protection Act 1998. Therefore, the LEA will need to produce a statutory authority to demand the information (such as a warrant or a court order). It is expected that when the Sections 21-25 of the RIP Act come into force (mid 2001) the main mechanism for seeking information will be the serving of a notice under S22(4).

ISPs are often approached by organisations or individuals, who are not LEAs, making requests for information on the basis that a crime or civil wrong may have been committed. If confidential information is involved then the advice in Section 5.7 should be carefully considered. It will invariably be possible for an order of the court or a statutory notice to be obtained, and it is Best Practice for an ISP to wait for this before divulging information. However, it is also Best Practice that ISPs do not (misleadingly) reject requests solely on the basis that the Data Protection Act forbids release of the information, because 29(3) might provide them with an exemption.

Statutory demands may be made under a variety of laws such as the Regulation of Investigatory Powers (RIP) Act, the Police and Criminal Evidence Act (PACE), or indeed by a Witness Summons issued by a court. If a statutory demand is made then Best Practice consists of scrutinising the document carefully, verifying that it is valid and then providing the information requested. Verification should use third party information; checking the validity of a warrant by phoning the telephone number written on it has an obvious flaw. Should anything be less than straightforward, then seeking legal advice is essential. If the warrant purports to access email or communications in transit then legal advice will also be necessary. Since consulting lawyers may take some time, care should be taken to ensure that the requested information is preserved during this period.

Although personal data is only a concept that applies to individuals rather than businesses, it is Best Practice for ISPs to treat all customers as if they were individuals. Releasing information about "a company" would be unlawful if it subsequently transpired that the customer was an individual after all.

9.2 "29(3) forms"

In the period remaining before the RIP Act comes into force, requests by LEAs are continuing to be made under the provisions of the Data Protection Act, using "29(3) forms". This form was developed in the late 90s through consultation between the police and ISP industry representatives. At that time, concern centred on the provisions of the Data Protection Act and how an ISP might lawfully release information under the provisions of S29(3).

The form was designed to provide the ISP with sufficient information to allow it to come to the conclusion that a crime has been committed and that it cannot be investigated without the disclosure of information by the ISP. If this is the case then the tests in S29(3) will be satisfied and the Data Protection Act will not be infringed by releasing the information.

The form must be signed by the investigating officer and by another senior officer. It is very important that it is completed correctly because the ISP may need to rely upon the information provided on the form to show that they did not act unlawfully.

Best Practice when an ISP receives a 29(3) form consists of reading the form, reading the extensive notes provided with the form and checking the administrative parts of the form (such as the signatures). The ISP will then have to decide whether the form asks a clear question and whether failing to answer that question will prevent the police from investigating a crime. If the ISP reaches the conclusion that withholding an answer will prevent the investigation of a crime then they may, at their discretion, answer the question without breaching the Data Protection Act.

However, there are likely to be further complications if the information is confidential. Section 5 discussed this in considerable detail. There might also be some doubt as to whether any provisions of the Human Rights Act apply since the RIP Act clearly envisages a statutory scheme, although it has been delayed. ISPs who receive 29(3) forms should consult a lawyer for detailed advice.

It is not expected, nor is it currently the case, that ISPs will receive large numbers of 29(3) forms. If the number was to grow, or if many unconvincing forms were submitted then confidence in the system would be significantly damaged and it would become far more common for ISPs to exercise their discretion and refuse to provide information upon receipt of a form.

9.3 Verbal requests

Where there is no paperwork accompanying a request from an LEA then Best Practice is for the ISP to refuse to supply any information and to then raise the incident through various industry consultation bodies such as the ICF. This will ensure that internal action is taken within the LEA to prevent a repetition.

However, it is of course understood that upon occasion preliminary discussions may be held with the ISP, often to determine the best form of paperwork to supply. The ISP should be aware that there is no duty upon them to preserve any data during this process. ISPs may also, at their discretion, provide LEAs with information that is in the public domain. For example, IP allocations and domain name ownership are available in open registry databases.

9.4 Payment for providing information

Arrangements are currently being put in place for ISPs to charge LEAs for the costs incurred in responding to statutory requests made under the RIP Act. This charging is done on a cost recovery basis; ISPs are not entitled to make any profit from these activities.

It is Best Practice for ISPs to submit claims for these costs since it will bring existing auditing processes at ISPs and within LEAs into play. This will help to ensure that properly authorised procedures are being followed.

Back to top

10. Approaches to Law Enforcement

It is sometimes the case that an ISP will become aware of what appears to be criminal activity and will wish to inform the authorities. The two possibilities are that the ISP becomes aware of the activity themselves and that a third party tells them.

ISPs may be told by a third party that one of their users is doing something that is said to be criminal. Leaving aside any action that the ISP may take under their Acceptable Use Policy (AUP), then Best Practice is for the ISP to request that the third party approaches the police themselves. Best Practice is to make it clear that in the event of the police mounting an investigation then the ISP will co-operate (using the type of mechanisms outlined in Section 9). It should also be made clear that ISPs are not a part of the Criminal Justice System and should not be seen by third parties in that light. There is also, under the provisions of article 15 of the EU Electronic Commerce Directive, "no general obligation to monitor".

Where ISPs become aware of criminal activity themselves, perhaps because one of their own machines has been the subject of a hacking attempt, then Best Practice is to inform the police promptly and to supply as much information as possible, whilst avoiding any breach of the Data Protection Act.

There are some special arrangements in place in the UK for dealing with "child pornography". Indecent images of children are illegal to even possess. Therefore, however an ISP gets to learn of its existence, action will need to be taken. If it is in a Usenet article then that article must be removed from the news server. If it is on a website operated by the ISP then access to the image must be prevented - although there may be considerable practical difficulties where machines are not under the direct control of the ISP.

All material should be reported to the Internet Watch Foundation (IWF) who will inform other ISPs where necessary and will also, in their liaison role, report it to the correct police officer within the correct police force. Where ISPs are unsure whether material is in fact illegal to possess then the IWF can be consulted; and ISPs can then be guided by their expert advice.

A further scenario that has engendered some interest is when an ISP is told that someone is threatening to commit suicide and that action should therefore be taken to prevent this. One should always remember that "winding people up" is a part of the culture of online meeting places such as chat rooms, however there have been documented cases of people who have killed themselves after announcing their intention on the Internet. There is also the possibility that the whole thing might just be "social engineering" designed to get the ISP to reveal personal data about their users.

ISPs will need to develop and use Best Practice procedures for dealing with this type of report. The ISP will need to be sure that they are convinced that there is a danger to life and also that the danger is immediate. If so, then the police should be contacted and they should be given all the available information about the report that has been received. If the police require further information, they should be invited to serve an appropriate notice. RIP S22(2)(g) expressly provides for obtaining information such as customer's name and address in an emergency for "preventing death or injury".

Finally, ISP staff may wish to note the provisions of the Public Interest Disclosure Act 1998 which sets out some employment safeguards for "whistleblowers" who report criminal offences or breaches of legal obligations. Disclosures should usually be made to the employer or to one of the "prescribed persons" set out in the Act. This type of disclosure overrides contractual duties of confidentiality to the employer.

Back to top

11. Documenting privacy policies

The third principle identified in section 4 above is that users must be told the details of an ISP's Privacy Policy.

The issues that must be addressed are:

  • What information is collected?

  • What information (such as demographic info) is optional to provide?

  • How is the information used?

  • How long is it kept?

  • Who the information may be shared with.

  • How to change permission given for data sharing.

  • How can information be inspected?

  • How can inaccurate data be corrected?

  • How optionally provided data can be deleted.

Failure to provide this information is a contravention of the First Data Protection Principle.

It is Best Practice to provide this information in a privacy policy statement on the ISP's web site, clearly linked from the top-level page. Sections 6 through 8 of this document will act as an aide memoire when listing the considerable number of systems that are likely to be recording information.

The creation of a comprehensive policy statement will not only inform users of how the ISP's systems behave, but is also likely to make the ISP consider the issues raised throughout this document as a complete list is developed of the systems that are recording information.

There exist some formal frameworks for company privacy policies such as TRUSTe (http://www.truste.org/), though these tend to be aimed at the US market where there is no data protection law to provide basic protection to web site users.

There also exist some scripts to automate the creation of privacy policies. TRUSTe has a "wizard" on its site, and the OECD, whose Guidelines on the Protection of Privacy and Transborder Flows of Personal Data date from as far back as 1980, has a generator at http://www.oecd.org/scripts/pw/pwhome.asp. However, these systems should be seen as ways of providing the framework rather than a way of avoiding the necessary work of providing the substance.

Back to top

12. Techniques for enhancing privacy

There are a number of ways in which users can take their own steps to enhance their own privacy when they use the Internet.

When email is sent across the Internet as plain text it is, in principle, readable by anyone who has access to the communication links over which it flows. It could also be read by anyone who has access to any server on which it may be temporarily stored prior to delivery. The operators of the communications links and storage systems will have strict rules about respecting the privacy of communications, but of course if the email is mis-addressed or mis-delivered then it may be read by an unintended third party. If email is encrypted then only someone who has the appropriate decryption key will be able to read it; thereby ensuring privacy is maintained. There are several encryption systems available, of which the best known and best supported are Pretty Good Privacy (PGP) and Secure MIME (S/MIME).

It is Best Practice for users to employ encryption for privacy purposes and Best Practice for ISPs to provide information and support to users in their usage of email encryption products.

Encryption can also be used between a web server and a user's web browser. The server is usually called a "secure server" and the standard system used is Secure Sockets Layer (SSL). Web browsers will indicate if SSL is in operation, often by displaying some kind of key symbol. Usage of SSL creates a significant load on the server and prevents the use of web caches to reduce external bandwidth requirements. Therefore, it is usual to reserve encryption for sensitive applications such as ordering and paying for goods and for inspecting and updating personal details held on a remote site. It would also be proper to use encryption for inspecting remotely held email.

It is Best Practice for users to insist that merchants and others who hold personal information provide encrypted access. It is Best Practice for ISPs to provide encrypted access to their own web sites where personal information is being transferred. Encryption should be the secure "128-bit" type, rather than the insecure "40-bit" variety.

Web caches exist to reduce loading on remote servers and to reduce the amount of (expensive) external bandwidth that is required. They work by holding a local copy of a web page and supplying that to a browser instead of refetching the page from the remote site. In principle, this means that all the remote site will detect is a page access from the cache machine and it will be unaware of the ultimate destination of the page. This can be inconvenient to the web site owner since they will be unable to calculate the true usage of their site, or indeed to use the access logs to assist them in their marketing efforts. It is therefore not unusual for web sites to use a number of schemes to avoid caches from being effective and to try and determine the identity of the end user.

It is possible to build "anonymising caches" which defeat the attempts by the web sites to identify users. The promotional pages for such sites are a good source of information on what information can "leak" through a normal web cache. However, if the remote site uses Java, JavaScript or Active X then even an anonymising web cache may not be sufficient to hide your identity. This is an evolving area and an introduction to the issues can be found at:

http://www.tiac.net/users/smiths/anon/anonprob.htm

The discussion of email at the start of this section emphasised the use of encryption to hide the contents of the email from prying eyes. However, the issue may be in hiding the identity of the sender; as might be appropriate in many cases - the usually cited examples being correspondence on mailing lists about sensitive subjects such as personal medical problems.

The systems that allow email to pass through them whilst stripping off the identity of the sender are called anonymous remailers. There are a number of these systems in operation, and a general guide to them can be found at:

http://www.andrebacard.com/remail.html

The simplest form of remailer requires you to trust the operator of the system that they will not divulge your true identity to the recipient of the email. It is possible to use more complex remailers in a chain so that no single person will be in a position to know both your identity and the contents of your message. These chained systems are considerably harder to use.

Operators of remailers are under an obligation to the community to ensure that their systems are not used for abuse, and in particular that they are not being used for bulk unsolicited email (see the LINX BCP on Unsolicited Bulk Email).

A recent development is the Freedom network. In this system all Internet traffic is encrypted and passed through a large private network utilising the Internet for connectivity. Your traffic is then exchanged with the destination via a randomly chosen Freedom node. This makes it complex to determine the true location of the user and provides considerable privacy, albeit at some cost in bandwidth and complexity.

When users voluntarily disclose personal information then some difficult problems may arise if this information is revealed in another context. This is a particular problem where children are using the Internet. There are a number of sites providing advice on the use of the Internet by minors, in particular the Cyber Smart advice:

http://www.iwf.org.uk/safe/children.htm

Back to top

13. Appendix A Glossary

AUP Acceptable Use Policy

A document explaining what an ISP's customers may or may do when connected to the Internet.

BCP Best Current Practice

A document summarising what is understood to comprise Best Practice amongst a community at a given time.

CLI Calling Line Identification

The signalling of the telephone number of the device that initiates a telephone call.

ECHR European Convention on Human Rights

See: http://www.hri.org/docs/ECHR50.html

ICF Internet Crime Forum

A UK forum attended by the ISP industry and LEAs. Its aim is to ensure that criminal investigations are carried out lawfully, quickly and efficiently while protecting the confidentiality of legitimate communications and with minimum impact on the business of the industry
See: http://www.internetcrimeforum.org.uk/

IOCA Interception of Communications Act 1985

UK legislation now almost totally repealed by the RIP Act 2000 (q.v.)

IP Internet Protocol

A basic protocol for exchanging packets between machines on the Internet. Other protocols are layered upon this to provide services to users. It is described in RFC791 and RFC1122.

ISP Internet Service Provider

ISP is used in this document as a generic term for any organisation that makes Internet access services available to independent customers.

IUPF Internet User Privacy Forum

A forum set up to promote, encourage and enable dialogue between representatives of the UK Internet Service Provider industry, civil libertarians, civil rights organisations and other interested parties, including the Information Commissioner, on the subject of privacy of Internet users and related matters.
See: http://www.iupf.org.uk/

IWF Internet Watch Foundation

The basic objectives of the Internet Watch Foundation are to restrict the availability of criminal content and help consumers prevent access to potentially harmful content on the Internet in the United Kingdom.
See: http://www.iwf.org.uk/

LEA Law Enforcement Agency

LEA is used a generic term for the police, Customs & Excise and agencies such as the Security Service (MI5) and the Secret Intelligence Service (MI6).

LINX London Internet Exchange

The LINX is a totally neutral, not for profit partnership between ISPs. It operates the major UK Internet exchange point. As well as its core activity of facilitating the efficient movement of Internet traffic it is involved in non-core activities of general interest to its members.
See: https://www.linx.net/

MIME Multipurpose Mail Extensions

MIME is a series of standards (documented in RFC2045-2049 and elsewhere) for incorporating richer content than plain text into email.

PACE Police and Criminal Evidence Act 1984

This Act of Parliament is not currently available online.

PGP Pretty Good Privacy

An email standard, and associated programs, for passing information in a confidential manner.

RFC Request for Comments

The RFCs are a series of notes, started in 1969, about the Internet (originally the ARPANET). The notes discuss many aspects of computing and computer communication focusing in networking protocols, procedures, programs, and concepts, but also including meeting notes, opinion, and sometimes humour. The Internet standards are documented within the RFC documents.
See: http://www.rfc-editor.org/

RIP Regulation of Investigatory Powers Act 2000

See: http://www.legislation.hmso.gov.uk/acts/acts2000/20000023.htm

S/MIME Secure MIME

A system for sending confidential messages by email using MIME (q.v.).

SPOC Single Point of Contact

A scheme set up by the police and communications industries for ensuring that formal contact flows through personnel who have been properly trained in handling requests for information.

UK United Kingdom of Great Britain and Northern Ireland

A small country situated off the Northwest coast of Europe.

29(3) Colloquial name of a form used by the police

The form is named after S29(3) of the Data Protection Act, and is used to request information from ISPs.
See: http://www.hmso.gov.uk/acts/acts1998/19980029.htm

Back to top

14. Appendix B References and resources

A number of references to valuable resources have been included in the body of the document. Some further items of interest are:

Council of Europe: Recommendation No R (99) 5 of the Committee of Ministers to member states for the protection of privacy on the Internet. Guidelines for the protection of individuals with regard to the collection and processing of personal data on information highways. (Adopted by the Committee of Ministers on 23 February 1999, at the 660th meeting of the Ministers' Deputies).

http://www.dataprotection.org/garante/prewiew_paragrafo/1,1731,1412,00.html

Council of Europe: Convention for the protection of individuals with regard to automatic processing of personal data

http://europa.eu.int/comm/internal_market/en/media/dataprot/inter/con10881.htm

OECD: Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (23rd September 1980)

http://www.oecd.org/dsti/sti/it/secur/prod/PRIV-EN.HTM

Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data

http://europa.eu.int/eur-lex/en/lif/dat/1995/en_395L0046.html

Directive 97/66/EC of the European Parliament and of the Council of 15 December 1997 concerning the processing of personal data and the protection of privacy in the telecommunications sector

http://europa.eu.int/eur-lex/en/lif/dat/1997/en_397L0066.html

UK Human Rights Act 1998

http://www.hmso.gov.uk/acts/acts1998/19980042.htm

UK Data Protection Act 1998

http://www.hmso.gov.uk/acts/acts1998/19980029.htm

UK Regulation of Investigatory Powers Act 2000

http://www.legislation.hmso.gov.uk/acts/acts2000/20000023.htm

UK Statutory Instrument 1999 No. 2093: The Telecommunications (Data Protection and Privacy) Regulations 1999

http://www.hmso.gov.uk/si/si1999/19992093.htm

UK Public Disclosure Immunity Act 1998

http://www.legislation.hmso.gov.uk/acts/acts1998/19980023.htm

ISPA-uk Code of Practice

http://www.ispa.org.uk/html/code_of_practice.htm

LINX BCP on Unsolicited Bulk Email

https://www.linx.net/good/bcp/ube-bcp-v2_0.html

LINX BCP on the Handling of Illegal Material

https://www.linx.net/good/bcp/illegal-material-bcp.html

Back to top

With over 770 members connecting from over 76 different countries worldwide, LINX members have access to direct routes from a large number of diverse international peering partners.

© London Internet Exchange, 2018 Registered office: London Internet Exchange Limited, 2nd Floor, Trinity Court, Trinity Street, Peterborough PE1 1DA United Kingdom . Registered in England, Number: 3137929
VAT Registration Number: GB 665 9580 82 Head office main telephone number Telephone: +44 (0)1733 207700 Fax: +44 (0)1733 207729

Web Design by Web Design by Bluestorm Design & Marketing

Leave Feedback

Cookies

This site uses cookies to store information on your computer. Some of these cookies are essential to make our site work and have already been set. By using our site you accept the terms of our Privacy Policy.

×