Submission

19 August 2003

IIA draft Cybercrime Code of Practice

This is a submission in response to the public consultation draft Cybercrime Code of Practice issued by the Internet Industry Association of Australia ("IIA") on 21 July 2003.

Contents:

Executive Summary

  • The Code fails to acknowledge the fundamental human right to privacy as a principle underlying the Code, and disregard for individuals' privacy is evident throughout the Code.
  • The provisions of the Code are not, as claimed, "within the spirit and letter of relevant privacy legislation" nor the IIA draft Privacy Code.
  • The Code seeks to establish a de facto extension of the interception of telecommunications regime currently governed by the Telecommunications (Interception) Act 1979.
  • The Code seeks to require ISPs to establish privacy invasive data collection and retention practices, just in case a law enforcement agency ("LEA") asks for information in the future. ISPs have no legal obligation to routinely collect or retain personal information for such a purpose.
  • The data collection and retention requirements are akin to asking a carrier to record every telephone conversation made over its system and asking Australia Post to photocopy every letter, and record the content of every parcel, it delivers.
  • ISPs who comply with the data collection and/or retention provisions of the Code may be exposed to civil liability for failure to protect the privacy of end users as required by the Privacy Act 1988.
  • Some provisions of the Code regarding disclosure of information to LEAs do not comply with the provisions of the Telecommunications Act 1997. Disclosing information in accord with such Code provisions would expose an ISP to criminal prosecution for breach of the Act.
  • A number of definitions in the Code require amendment because they result in the Code provisions being contrary to the Telecommunications Act 1997.
  • Some sections of the Code relevant to data retention, and also others relevant to disclosure of information, are contradictory. The Code does not achieve the objective stated in Section 3.1(b) of providing clear guidelines.
  • If it is true, as suggested in the Code, that smaller ISPs are unable to secure their networks, then it is highly irresponsible of the IIA to develop a Code that seeks to require such ISPs to collect and retain customers' personal information.
  • None of the provisions of the Code will prevent ISPs' networks and facilities from being used to commit offences.
  • If, as claimed, there has been confusion and uncertainty among ISPs as to their legal obligations to assist LEAs, that apparently results from failure by ISPs to read the extensive information issued by the Australian Communications Authority ("ACA") since at least as long ago as 1998. EFA considers the ACA documents are clearer, and present a more accurate summary of ISPs' obligations and the law, than the IIA Code.
  • Given it has taken two years for the IIA and LEAs to develop the Code, it is clear there are no compelling problems facing LEAs that warrant the adverse impact on privacy.
  • The Code is unnecessary and should be abandoned.


Up ArrowGo to Contents List

About EFA

Electronic Frontiers Australia Inc. ("EFA") is a non-profit national organisation representing Internet users concerned with on-line rights and freedoms. EFA was established in 1994, is independent of government and commerce, and is funded by membership subscriptions and donations from individuals and organisations with an altruistic interest in promoting online civil liberties.

Up ArrowGo to Contents List

Introduction

EFA observes with grave concern that the IIA Cybercrime Code seeks to establish a de facto extension of the interception of telecommunications regime currently governed by the Telecommunications (Interception) Act 1979.

The provisions of Section 7 of the Code would enable a vast range of law enforcement agencies, and also private sector organisations (see Section 7.5 later herein), to gain access to a wealth of personal and communications information without a search warrant, let alone an interception warrant. The information collected and retained would be released in relation to the investigation of minor crimes, far less serious than those for which the Parliament has determined an interception warrant must be obtained, and also in relation to investigation of activities that are not criminal offences.

We note that two years ago, the IIA was 'vigorously opposed' to such an extension of the interception regime. However, the Code promotes and encourages exactly the same highly privacy intrusive practices that the IIA previously opposed.

EFA is implacably opposed to the data collection and retention requirements of the Code for the same reasons as stated by the IIA's representative, Ms Mary Jane Salier, in evidence to the Joint Committee on the National Crime Authority on 26 March 2001:

"Ms Salier - The submission of the Australian Securities and Investments Commission, ASIC, included extensive references to what they think ISPs should be obligated to do.

...ASIC refers to records [that they wish ISPs to retain] as 'the details of communications that have taken place and the parties to the communications' [and] log records of proxy servers...

...If [logs noting when ISPs' customers log in and log out of its service] is the information that is sought to be retained, then there are different issues than if it is seriously being suggested that we should retain information relating to every customer that logs in and what that customer does with whom online, what sites they visit, what transactions they conduct, what news groups they frequent and what chat sessions they participate in. The salient point here is that, unlike call charge records, we are not dealing with point to point communications.

Depending on how that word 'records' is defined results in a dramatic difference in impact on industry, privacy and community. If we take the broad use of the word as given by the ASIC, it is akin to asking a carrier to record every telephone conversation made over its system or asking Australia Post to photocopy every letter that passes through its office. This is not an overdramatic analogy. An ISP does not have an interest in recording or monitoring what its customers do once access is gained to the Internet, except for the purposes of providing its service obviously. ISPs do not track or monitor customer activities or communications. ISPs do not record and maintain such information. There are very good reasons for this.

Firstly, there is simply no value in this information for Internet access providers. Secondly and most importantly, there are privacy considerations and implications raised by this conduct. These are enormous as you can imagine, and a critical issue to an ISP's business as it is a longstanding phenomenon that privacy issues are consistently found to be a real barrier to use of the Internet. Our growth is dependent upon finding a way to assure the users that their privacy will be not only respected but also vigorously guarded.
...
...We would submit that ASIC is de facto suggesting an extension of the interception of communication regime currently governed by the Telecommunications (Interception) Act. ... Interception of communications is a drastic power to bestow, as it necessarily involves a complete invasion of privacy. Powers such as these should only be available on a last resort basis and under stringent guidelines. In fact, the IIA vigorously opposes any extension of such powers beyond the act in which they currently lie.
...
Whilst we appreciate the concerns that law enforcement agencies are trying to address and deal with, the fact is that the privacy implications are enormous with the Internet, much more so than, for example, the carriers intercepting telephone conversations. The Internet is not a point-to-point medium and if we go back to the national privacy principles, the first principle is in relation to collection, namely, the collection of data should not be intrusive. I think that anything above and beyond records that you need for your billing purposes or recording when users log on and log off the Internet is intrusive and therefore needs to be subject to greater scrutiny.
...
...the telephone does not give access to as much information as the Internet does. In a telephone conversation that is intercepted, you intercept one conversation on one topic. It is just one medium of communication point to point. When you are intercepting communications on the Internet, you are talking about intercepting web sites that are visited by people, you are talking about intercepting chat sessions that are had by people, you are talking about intercepting emails. There are myriad forms of communication that take place over the Internet which make it not analogous to a telephone conversation.
...
...I am saying that, as a general rule, there should not be an obligation to retain the sorts of records that we are discussing here, namely, when you log on, where do you go? Just as there is not a general obligation on Telstra to record anything beyond the fact that the person dialled from here to there-unless, and again I come back to the interception warrant, there is a specific requirement placed on a carrier to do so.
...
...The issue that was of grave concern to the IIA from the submissions really related to the fact that there were several agencies that appeared to be calling for the general retention of records such as would only be ordinarily retained in the event of an interception warrant.
...
...The information that we are talking about collecting here is of a much greater magnitude than in point-to-point conversations. [It] is akin to recording a telephone conversation every time a conversation is made. We can tell you when one of our users has been using our system, just as Telstra or a carrier can tell you when one of their users has made a call, but I believe the next step is actually akin to requiring a carrier to record the conversation.

Mr KERR - ... Is there a middle ground which would require you to track, not to copy every communication necessarily, but to have the same kind of information as to where users actually go in terms of their contacts within their use of time that is blocked out to them?

Ms Salier - I would say that, in the online world, that is akin to recording a telephone conversation. There is no difference."

The provisions of the Code indicate that during the past two years the IIA has completely reversed its previously stated position, and entered into an unduly cosy relationship with LEAs at the expense of due process and Internet users' privacy.

The Code, developed by the IIA and LEAs, has been issued for 'public consultation' without any information to suggest that consideration was given to whether the privacy intrusion is justified, when taking into account the seriousness of the problem, the alternatives available and whether the measures are even likely to be effective in combatting criminal activity.

There are however indications that the principle consideration was the alleged needs of LEAs. In this regard, we note statements made to the Joint Committee on the Australian Crime Commission on 21 July 2003, the same day the draft Code was issued:

"Mr Inman [ASIC] - As far as we are aware, the Internet Industry Association's cybercrime code of practice will be leading the way globally. We are yet to find another example of a code of practice that specifically addresses the areas that this draft code will.
...
It is very cooperative. We have spent-as I alluded to earlier-two years, and other agencies have spent a lot of time and resources, providing detailed technical advice as to what our needs are. The Internet Industry Association has welcomed that."

"Ms Atkins [AUSTRAC] - ...in terms of the sorts of things you are talking about - monitoring and keeping records - one of the big problems for law enforcement, if somebody is, say, using the Internet to conduct transactions, is: how long are the records kept and how can they get at them? We have been doing quite a lot of work with people like the Internet Industry Association, who have developed a code into which, through AGEC, we have given detailed input about how long they are prepared voluntarily to keep information."

In EFA's view, no LEA witnesses before the Committee provided any examples of problems faced by LEAs that justify Section 7 of the Code. ASIC, for example, said:

"Mr Inman-When we take a proactive stance - that is, we try to identify an offence while it is still being perpetrated; a classic example is when a web site suddenly appears offering someone an investment, the content of which contravenes our legislation - we need to find out who is behind that. The types of material that we are dealing with when we do that are not paper based; they are very much logs - computer logs, network logs - and those types of things."

EFA questions why ASIC could not identify who is making the investment offering without access to ISP proxy logs and similar records of Internet users' communications and online activities. An ISP would know who was paying them for the web site space. If the web site is not hosted by an ISP, details of the web site domain name registrant would be obtainable by law enforcement agencies.

EFA recommends that the IIA reconsider Section 7 of the Code in accord with the 'Framework for Assessing Law Enforcement Initiatives where they impact on privacy' set out in the Federal Privacy Commissioner's submission to the Parliamentary Joint Committee on the National Crime Authority's 2001 inquiry into the 'Law Enforcement Implications of New Technology'.

The privacy intrusion into the lives of the whole population of Internet users, on the grounds that criminal activity might be caught in the process, is not justifiable. It is not proportionate to the type of problems being addressed. Furthermore, given it has taken two years for the IIA and LEAs to develop the Code, it is clear there are no compelling problems facing LEAs that warrant the adverse impact on privacy.

In the remainder of this submission we provide detailed comments on a range of provisions of the Code, some of which are in conflict with the Telecommunications Act 1997 or the Privacy Act 1988.

Up ArrowGo to Contents List

Code Title

"CODES FOR INDUSTRY AND SELF REGULATION AND RULES OF ENGAGEMENT WITH LAW ENFORCEMENT AGENCIES IN RESPECT OF INVESTIGATION PROCEDURES REGARDING ONLINE FRAUD AND OTHER CRIMINAL AND TERRORIST ACTIVITY"

The references to "online fraud" and "terrorist" activity are redundant and should be deleted. Both online fraud and terrorism are a crime, hence the term "criminal activity" includes such activities.

Further the Code does not appear to deal to any significant extent with the investigation of terrorist activity. For example, it does not mention the provisions relevant to assisting ASIO in the Telecommunications Act 1997.

We suggest IIA cease playing the terrorist card in an attempt to gain support for a privacy invasive Code that will not prevent terrorists or any other criminals using ISPs' networks.

Up ArrowGo to Contents List

Section 1 - Background

"1.3 Safety, security and reliability of the internet is dependant upon early detection of criminal activity that might undermine achievement of these objectives. However, this requires a balancing of such fundamental rights as the right of individuals to privacy of communications and the right of individuals to be protected against criminal activities. To address the legitimate rights and expectations of law abiding citizens to the protection of their personal information, the IIA has also drafted an Industry Code of Practice for Internet Privacy [IIA Privacy Code of Practice found at http://www.iia.net.au/privacyvt.html], and remains committed to promoting industry best practice for the privacy of those using the internet for lawful purposes."

The Cybercrime Code does not promote industry best practice for the protection of Internet users' privacy. On the contrary, the provisions of the Privacy Act 1988 have not been taken into account and the Cybercrime Code specifically promotes invasion of Internet users' privacy and breach of the provisions of the draft IIA Privacy Code.

With regard to the IIA Privacy Code, we observe it is still a draft, issued for public consultation a year ago. It largely re-states the National Privacy Principles ("NPPs") contained in the Privacy Act 1988 which are enforceable whether or not an IIA Privacy Code exists. Further, any additional provisions in the IIA Privacy Code are not enforceable as the Code has not been registered by the Federal Privacy Commissioner under the Privacy Act.

"1.5 This Code builds upon other relevant codes and information sheets, referred to in section 2 of this Code to provide a basis for ongoing cooperation between LEAs and ISPs in relation to prevention, detection and investigation of online fraud and other criminal activity and threats to national security and information infrastructure."
"1.6 This Code has been developed recognising the cost of online fraud and other criminal activity, and the cost of its prevention, detection and investigation. Online fraud imposes a substantial cost on ISPs that is ultimately borne by internet users. ... "

The latter sentence appears to be a completely unsupported statement. Denial of Service ("DoS") attacks may impose a substantial cost on ISPs, but it is not apparent that online fraud would unless a vast number of criminals are using invalid or stolen credit card numbers and ISPs are providing services without first checking validity of credit card details. If the latter is the case, the Code will not prevent that nor make it any easier to investigate such crime as criminals would no doubt give ISPs false identity and contact information.

1.6 "... Smaller ISPs are disproportionately affected because of the more limited resources available to them to limit their exposure and secure their networks. Denial of service, hacking and other security threats and attacks impose high costs on business using the internet. LEAs incur substantial costs in detection and investigation of criminal activity. These law enforcement costs are ultimately borne by taxpayers. ... "

If it is true that smaller ISPs are unable to limit their exposure and secure their networks, then it is highly irresponsible of the IIA to develop a Code that seeks to require such ISPs to collect and retain customers' personal information. Such information would be at risk of disclosure to and use by criminals due to ISPs' inability to adequately secure their systems and network.

"1.6 ... This Code endeavours to set clear procedures for cooperation between ISPs and LEAS in an effort to ensure that all these costs are minimised and equitably allocated. This Code is also an important part of internet industry initiatives to assist end users to address concerns that they may have as to risks of dealing online. These initiatives include education as to the availability and use of more secure methods of payment, virus protection software and personal firewalls."

The Code does not contribute anything whatsoever to assisting end users to address concerns about risks. Instead the Code raises increased concerns about risks and threats to privacy resulting from Internet use.

"1.7 This Code is, in the first instance, directed towards ISP/LEA cooperation. Nevertheless, the parties acknowledge the prospect of future extension to other areas of online activity, including hosting and e-commerce (reflecting the breadth of the IIA membership), provided always that such cooperation is solely directed to the purpose of addressing criminal or terrorist activity occurring on or by means of the internet and remains within the spirit and letter of relevant privacy legislation and IIA codes."

The provisions of the Code are not "within the spirit and letter of relevant privacy legislation" nor the IIA draft Privacy Code (see Section 7).

The words "or terrorist" should be deleted from Section 1.7 for the same reasons mentioned earlier herein.

"1.8 Either LEAs or ISPs can initiate interaction with each other in respect of an investigation. This Code seeks to set out procedures to ensure that all parties interact lawfully and in accordance with legitimate and reasonable expectations of those parties and of end users, thus affording parties a measure of certainty regarding the execution of LEA investigations."

Many end users have an expectation that their privacy will be protected in accordance with legislation enacted by the Parliament. The Code should ensure such an expectation is fulfilled, not merely deal with whatever IIA considers to be "legitimate and reasonable expectations".

"1.9 The primary piece of legislation which governs ISPs in Australia is the Telecommunications Act (C'th) 1997 (the Act). The Act covers a range of matters and obligations that ISPs should follow to assist LEAs in certain investigation activities. These matters are covered by Parts 13, 14 and 15 of the Act. The Act also operates in conjunction with the Telecommunications (Interception) Act (C'th) 1979 (Interception Act). This Code is not intended to deal with telecommunication interception obligations of CSPs, other than in referring to when a Telecommunications Interception (TI) Warrant is required, or not required."

The Privacy Act 1988 also governs activities of numerous ISPs (all except those whose annual turnover and activities are such that they are covered by the small business exemption). The Code fails to recognise the Parliament's intention that telecommunications industry codes comply with the Privacy Act. In this regard, the Telecommunications Act 1997 was amended by the Privacy Amendment (Private Sector) Act 2000 and the Explanatory Memorandum to the Bill states:

"The aim of the amendments to Part 6 of the Telecommunications Act is to recognise and promote the pre-eminence of the Privacy Act and the role of the Privacy Commissioner within the telecommunications environment without diminishing the integrity of the current telecommunications self-regulatory regime"
and that
"New clause 116A [to the Telecommunications Act] provides that nothing in an industry code registered under Part 6 of that Act or an industry standard determined under Part 6 of that Act replaces or diminishes any obligations imposed by the Privacy Act 1988 or an approved privacy code as defined in that Act".

Obviously an unregistered industry code cannot replace or diminish such obligations either.

"1.11 The simplified outline of Part 14 reads as follows:
The ACA, carriers and carriage service providers must do their best to prevent telecommunications networks and facilities from being used to commit offences. ..."

None of the provisions of the draft Code will prevent ISPs' networks and facilities from being used to commit offences.

Further, the requirement that ISPs 'do their best' does not require or justify routine collection and retention of personal information about customers. As stated in the ACA Telecommunications and Law Enforcement Manual:

"2.23 There is a requirement on carriers and service providers to 'do their best' to prevent telecommunications networks and facilities from being used in, or in relation to, the commission of offences against the laws of the Commonwealth or of the States and Territories (S. 313 of the Act).
2.24 Agencies suggest that acting in good faith to meet these requirements would involve carriers and service providers in such things as -
  • taking reasonable steps to ensure that customer information is not false
  • taking reasonable steps to ensure integrity of staff
  • not deliberately targeting services towards a market likely to use those services for criminal purposes, and
  • participating in industry action to prevent the networks being used for criminal purposes."

We note that the Code does not require ISPs to take steps in relation to the majority of LEA suggestions listed above. Further, we consider the Code requirement that ISPs collect and retain an extensive and unnecessary range of personal information about customers (including birth date, telephone numbers, etc) is likely to result in some customers providing false information in order to protect their privacy. This would result in more wastage of LEAs time and resources than ISPs not having information available in the first place.

"1.14 The Act is silent as to as to interpretation of the concept of "reasonably necessary" which is central to operation of both Parts 13 and 14 of the Act."
"1.15 There has been confusion and uncertainty created by failing to have any clear guidelines available to the Internet industry and LEAs as to what constitutes "such help as is reasonably necessary" under the Act ..."

If there has been confusion and uncertainty, that apparently results from failure by ISPs to read the extensive information issued by the ACA since at least as long ago as 1998. In particular:

EFA considers the above documents are clearer, and present a more accurate summary of ISPs' obligations and the law, than the IIA draft Code.

"1.14 ... and how such assistance can be given and received so as to ensure that:
...
(c) ISPs and their staff are aware of their obligations and the parameters of the Act and thereby are not unreasonably exposed to criminal liability for failure to protect the privacy of communications of end users."

ISPs may also be exposed to civil liability for failure to protect the privacy of end users as required by the Privacy Act 1988.

Up ArrowGo to Contents List

Section 2 - Other Relevant Codes and Information Sheets

"2.4 Further, the IIA has published a Fact Sheet for ISPs on Law Enforcement Cooperation at www.iia.net.au/ispsheet.html."

The above URL returns a "Not Found" error as at 12 and 18 August 2003. Further, both the IIA site search engine and Google are unable to find such a Fact Sheet on IIA's site.

"2.5 This Code does not seek to duplicate matters already dealt with by the booklet and fact sheets referred to in sections 2.2 to 2.3."

Nevertheless, it does. Also, in some areas the Code seeks to create obligations that the documents referred to above state do not exist in law.

Up ArrowGo to Contents List

Section 3 - Objectives of Code

"3.1 The aims of this Code include to:
...
(b) provide clear guidelines to the satisfaction of both industry and LEAs as to what constitutes "such help as is reasonably necessary" and to ensure this term is defined having regard to standards of confidentiality and privacy afforded to users of the Internet under the Act and thereby establish confidence in and encourage the use of the Internet;"

The Code should also have regard to the privacy protection obligations of the Internet industry set out in the Privacy Act 1988.

3.1 "(c) provide a transparent mechanism for the handling of LEA's investigations for the Internet industry and ensure that there is a clear understanding on both sides as to what the procedures are;
(d) promote positive relations between the LEAs and the Internet industry.
(e) give users of the Internet confidence that their privacy and the confidentiality of their transactions will be guarded from unlawful intrusion by LEAs."

The Code should aim to give users confidence that their privacy will be protected in general not only in relation to LEAs. The Code is likely to result in users of the Internet having less confidence that their privacy will be protected than presently. The Code encourages ISPs to invade users privacy to a greater extent than is necessary for the provision of Internet access and to retain information about individuals' use of the Internet for an unnecessarily long time just in case at some future time a LEA thinks the information might be useful.

Up ArrowGo to Contents List

Section 4 - Principles Underlying the Code

"4.1 In seeking to achieve its objectives this Code applies the following principles:

(a) the Code should be technology neutral;

(b) requirements should be fair to all concerned;

(c) requirements should not adversely affect the economic viability of the parties to the Code and the services they make available;

(d) all lawful privacy obligations will be respected."

The failure to include the fundamental human right to privacy, as a principle underlying the Code, is typical of the disregard for individuals' privacy evident throughout the Code.

Up ArrowGo to Contents List

Section 5 - Terminology and Interpretation

Agency

"Agency means a department or other instrumentality of the Commonwealth of Australia, a State or Territory"

The words "or other instrumentality" should not be included. They do not appear in the Telecommunications Act 1997 and may have the effect in the Code of broadening the definition of LEAs beyond those defined in the Act. The definition should be changed to that given in Section 282 of the Act (which is different from the definition of "agency" in Section 7 of the Act). See also "LEAs" below.

Criminal penalty-enforcement Agency

"Criminal penalty-enforcement Agency
...
c) the National Crime Authority; or
...
f) the Crime and Misconduct Commission of Queensland; or"

There are no such agencies, nor have such agencies been referred to in the Telecommunications Act 1997 since at least January 2003.

The definition should be amended to have the meaning given in the Telecommunications Act 1997 and include the current list from that Act as a note to the definition.

In relation to item (g) of the definition, we suggest it be noted that the Police Integrity Commission of New South Wales is a "prescribed authority" for the purposes of seeking disclosures under subsection 282(3) of the Act (as specified in the Telecommunications Regulations 1998). To the best of our knowledge, it is the only authority prescribed to date.

LEAs

"LEAs means collectively Civil Penalty Enforcement Agencies, Public Revenue Agencies, National Security Agencies, and Criminal Penalty Enforcement Agencies."

The omnibus definitions of "LEAs" and "agency" used in the Code do not take into sufficient account the various agency definitions and use of same in the Telecommunications Act 1997. This results in the Code provisions being in conflict with that Act.

The definition of "LEAs", and use of the term in the Code, should be amended in a manner consistent with agencies specified for relevant purposes in the Telecommunications Act 1997.

The term "National Security Agencies" is not defined in the Code, nor in the Act, and therefore may be perceived to include a number of "National Security Agencies" that are not entitled to receive information by way of a request under Section 282 of the Act. The Code's use of the term "LEAs" in relation to Section 282 incorrectly implies that any "National Security Agency" is so entitled.

In addition, the Code appears to require ASIO to request information via a Section 282 Certificate although the Act specifically provides a different mechanism applicable to ASIO requests.

Other Authorised Process

"Other Authorised Process means general search warrants and other notices and documents authorised by or under law or issued as a result of legal proceedings."

The definition of "Other Authorised Process" is too wide. It could include letters of demand unsupported by relevant statutory, judicial or quasi-judicial powers. The impact on Sections 7.9, 7.10 and 10 would be to open up search powers to civil authorities and agencies without investigatory powers. It also fails to recognise that Section 280 of the Act does not authorise use or disclosure of information in connection with LEAs except under a warrant (see Section 10.1 below).

The definition should be changed to:

"Other Authorised Process means:
  • in connection with the operation of a LEA, a warrant requiring or authorising a disclosure or use;
  • in any other case, a request authorised by or under law. This includes an agency (other than an LEA) request for use or disclosure of information derived from powers authorised by or under law and an order or notice issued by a court for the provision of information (such as court orders made during the discovery process, summons for witnesses to attend and produce records and subpoenas for documents)."

In addition, according to evidence recently given to a Parliamentary Committee, it appears there is a need to make expressly clear that "Other Authorised Process" does not include use or disclosure of information in response to requests from private sector organisations that are not supported by a court order (see Section 7.5 for further information).

Personal Data

"Personal Data as defined in the Privacy Amendment (Private Sector) Act (C'th) 2000 means the information, whether fact or opinion or evaluative material, about an identifiable individual that is recorded in any form."

Contrary to the above statement, "Personal Data" is not defined in the above mentioned Act, nor in the Privacy Act 1988. Further, the definition of "Personal Information" which is defined in those Acts is different from, and broader than, the above definition of "Personal Data". The Privacy Act states:

"personal information means information or an opinion (including information or an opinion forming part of a database), whether true or not, and whether recorded in a material form or not, about an individual whose identity is apparent, or can reasonably be ascertained, from the information or opinion."

There is no apparent reason to use a different definition in the Code other than to exclude some information covered by the Privacy Act 1988 in an attempt to avoid obligations imposed by that Act. However, nothing in an industry code can replace or diminish obligations imposed by legislation.

Moreover, although the Code refers to "Operational Data" and "Other Data" separately from "Personal Data", in the context in which "Operational Data" and "Other Data" is collected and retained by ISPs it will comprise "personal information" as defined in the Privacy Act. This is because the information will be "about an individual whose identity is apparent, or can reasonably be ascertained" by the ISP from the information. If the ISP who retains the information cannot identify the individual user from the information, then the information would be of no potential use to LEAs.

CLI

"CLI Caller Line Identification is information that is generated by the network at the time a telephone call is established, and includes:
the called party's phone number
the calling party's phone number
the time of day
the duration of the call
the routing of the call."

The above definition is incorrect. As CLI is generated at the time a call is established, obviously it cannot include the call's duration, which is not known at call establishment. Further, the term "Caller Line Identification" clearly refers to the calling line, CLI does not include the called party's number.

The definition in the IIA draft Code has been extracted from ACIF Calling Number Display Code ("ACIF Code") and then the word "calling" changed to "caller". However the ACIF Code contains, apparently, an inaccurately summarised version of information that originated in the 1992 AUSTEL Telecommunications Privacy Report which stated:

"Calling Line Identification is data that is generated at the time a call is established. In general, when a telephone call is made through parts of the network with the technical capacity information is passed within the network about -
  • the called party's phone number
  • the calling party's phone number
  • the time of day
  • the duration of the call
  • the routing of the call"

In other words, CLI is the information containing the calling party's phone number. CLI, and the other information, is passed through the telephone network.

Further, the IIA Code uses the term "Caller Line Identification" instead of the term used in the ACIF Code, that is, "Calling Line Identification". The former term should not be used as the information does not identify the caller, it identifies the calling line from which the caller is calling.

The definition of "CLI" should be changed to "CLI Calling Line Identification is data that is generated at the time a telephone call is established that identifies the calling party telephone number/s".

CND

"CND Caller Number Display is information contained in the signalling data which displays the originating caller's number on the terminating party's CND-enabled device (eg a home telephone equipped with a CND capacity). CND will not be displayed if the calling party has (temporarily or permanently) disabled CND or if the called party has not elected to pay for the CND service."

The abbreviation "CND" should refer to "Calling Number Display" (not "Caller Number Display") the same as in the ACIF Calling Number Display Code that is applicable to all members of the telecommunications industry.

Further, the IIA Code definition of CND is incorrect and also does not meet the Code's underlying principle 4.1(a) that "the Code should be technology neutral".

"Caller/Calling Number Display" is not "information contained in the signalling data", it is the display or presentation of such information.

The statement that "CND will not be displayed if the calling party has (temporarily or permanently) disabled CND" is currently factually incorrect. As IIA has been aware since at least October 2002 (P Coroneos quoted in Privacy battle over CLI, The Australian IT, 30 Oct 2002), some carriers are over-riding calling number blocking on calls made to some ISPs.

The reference in the definition of CND to information "which displays... on the ... CND-enabled device (eg a home telephone equipped with a CND capacity)" is not technology neutral and is inappropriate in a Code applicable to ISPs. In Australia, a CND Service provided to ISPs with dial-up calls does not display the number on a CND enabled device, the number presented is automatically stored in the ISP's log-in records.

We recommend the IIA Code use definitions similar to those contained in the ACIF Calling Number Display Code, that is:

CND means Calling Number Display (based on CLI).
CND Information means the displayed or presented number of the telephone service from which a call is made.

References to "CND" elsewhere in the Code (e.g. Sections 7.4 and 11.2) should be changed to "CND Information".

Up ArrowGo to Contents List

Section 6 - Privacy Act

"6.1 ISPs who are not already subject to the Privacy Act may only subscribe to the Code if the IIA has been provided with written evidence that the ISP has elected to be treated as an organisation in accordance with section 6EA of the Privacy Act."

If Section 6.1 is to achieve the apparent objective of ensuring that all Code subscribers are subject to the Privacy Act 1988, IIA will need to frequently check whether an ISP, who had elected to be treated as an organisation in accordance with s.6EA, has subsequently revoked its choice to be so treated in accordance with s.6EA(4).

The Code should set out the means by which, and how often, IIA will check whether or not Code subscribers remain subject to the Privacy Act 1988.

In addition, the Code should include a clause requiring a Code subscriber to notify IIA if it revokes its choice in accordance with s.6EA(4) and stating that such ISPs will be unsubscribed from the Code.

As discussed in the following section, in potentially many cases an ISP who complies with the Privacy Act 1988 will not be able to comply with the IIA Cybercrime Code.

Up ArrowGo to Contents List

Section 7 - ISP record keeping obligations in relation to provision of assistance to LEAs

"7.1 The Act does not require ISPs to retain any particular records additional to those retained for the ordinary course of business. However there is a range of other legislative requirements that obliges Carriers and CSPs to retain financial records for approximate 7 years. Accordingly ISPs already have an obligation to provide reasonable assistance to LEAs under the Act. In order to clarify this obligation ISPs will retain the following Customer related data (Personal Data) [for, as stated in Section 7.7, a minimum period of 6 months from the date a Customer ceases to be Customer, or for 12 months after the creation of the record; whichever is the greater]:
  1. Customer name;
  2. username;
  3. email address;
  4. date of birth (if collected);
  5. Customer address;
  6. contact telephone numbers;
  7. type of service provided (dial, DSL etc);
  8. credit card details where credit card details are collected in relation to billing the particular service offered by the ISP; billing records;
  9. history of changes to Customer details;
  10. prepaid identifier (if applicable);
  11. sub-account details (if applicable)."

Although Section 7.1 claims to "clarify" an ISP's obligation to assist LEAs, it does not. It seeks to create obligations that do not exist in legislation and that in some instances will be in conflict with an ISP's obligation to comply with the Privacy Act 1988.

We draw to the IIA's attention that NPP 1.1 of the Privacy Act states:

"1.1 An organisation must not collect personal information unless the information is necessary for one or more of its functions or activities."

As stated in the Federal Privacy Commissioner's NPP Guidelines:

"NPP 1.1 aims to limit the information that an organisation collects to that which is necessary for its functions and activities.

The Commissioner interprets 'necessary' in a practical sense. If an organisation cannot in practice effectively pursue a legitimate function or activity without collecting personal information, then the Commissioner would ordinarily consider it necessary for that function or activity. It would not ordinarily be acceptable for an organisation to collect personal information on the off chance that it may become necessary for one of its functions or activities in the future."

ISPs have no legal obligation to routinely collect or retain personal information just in case an LEA might want information in the future. This is clearly stated in the ACA Fact Sheet Internet Service Providers and Law Enforcement and National Security:

"Legislation does not specifically require ISPs (or other CSPs and carriers) to keep this type of information for law enforcement or national security purposes. However, an agency may request the holding of information pending further information or court order. ... Agencies ... may make a specific request that an ISP keep certain information pertaining to a particular user."

ISPs who routinely collect personal information that is not necessary for the provision of the relevant service will be in breach of NPP 1.1. In addition, those who retain data for longer than is necessary for purposes permitted by NPP 2 (which does not include routine retention just in case a LEA might request same in the future) may be found to be in breach of NPP 4.2 (see Section 7.7 later herein).

"7.3 ISPs may provide internet access services on a pre-paid basis or otherwise in circumstances where the person proposing to use these internet access services does not provide identity-related information at the point of sale or other provision of pre-paid access. Where internet access services are so provided, as soon as practicable after a prospective user logs on to an ISP's network the ISP will request the Customer to provide the Customer's name, residential address, contact telephone number, date of birth and the public number of any fixed line telephone service at the Customer's address. Where these details, including any paper-based application form, are retained by an ISP, these details will also be Personal Data for the purposes of this Code."

There is no legal basis for an identification requirement. The above encourages breach of NPP 8 (Anonymity), and also Clause 6.31 of the IIA draft Privacy Code, which state:

"Wherever it is lawful and practicable, individuals must have the option of not identifying themselves when entering transactions with an organisation ['with a Code Subscriber' in the IIA Privacy Code]."

It is lawful and practicable for an ISP to provide pre-paid Internet access without requiring such customers to identify themselves.

Clause 7.3 should be deleted. Apart from promoting breach of NPP 8, the clause does not require collection of personal information, merely that an ISP 'request' same, and the final sentence states that ISPs are not required to retain the information. The clause therefore has no obvious purpose. If it is intended to encourage ISPs to ask pre-paying customers to identify themselves on the assumption that many would be willing to do so, the clause should be amended to specifically state that denial of service to a pre-paid customer who declines to provide identification details would be in breach of NPP 8.

We also note that placing identification requirements on pre-paid accounts will not prevent criminal use of the Internet. Criminals will simply use services available anonymously at Internet cafes or one of the many other means of hiding their identity when using the Internet as discussed in EFA's August 2003 supplementary submission to the Parliamentary Joint Committee on the Australian Crime Commission.

"7.4 ISPs will retain the following operational data about each Customer and their interaction with the ISP's network (Operational Data) [for, as stated in Section 7.7, a minimum period of 6 months from the date of creation of such data]:
  1. dynamic IP allocation records, indicating which IP address was assigned to which Customer account at specific log in times;
    records of the date and time of each log in and log out of a Customer;
  2. CND or CLI where collected;
  3. total data transferred (if collected)"

As discussed under the definition of "Personal Data" earlier herein, although the Code refers to the above as "Operational Data" and separates it from the "Personal Data" listed in Section 7.1, in the context in which "Operational Data" is collected and stored by ISPs it will comprise "personal information" as defined in the Privacy Act.

As it is most unlikely that an ISP has an operational need to keep such data for 6 months for the primary purpose for which it was collected, retaining the "Operational Data" for 6 months merely in order to comply with the Code will be in breach of NPP 4.2 (see Section 7.7 later herein).

Item 7.4(c) should be amended to clarify whether "total data transferred" means retention of a copy of all data (information) transferred, or retention of a figure being the total amount of data transferred.

"7.5 ISPs will retain the following other data (if collected) about each Customer and their interaction with the ISP's network (Other Data) [for, as stated in Section 7.7, a minimum period of 1 week after creation of the record]:
  1. proxy logs (IP Address, Time, URL);
  2. email Arrival, delivery, sender, recipient, size;
  3. newsgroup logs;
  4. FTP logs."

Some of the information captured in the above logs is information that relates to the contents or substance of a communication. Either the above list, or Section 8.3 requires amendment to comply with the Telecommunications Act 1997, as detailed under Section 8.3 below.

All of the "Other Data" will be "personal information" as defined in the Privacy Act for the same reasons stated earlier herein. Retaining the "Other Data" merely in order to comply with the Code will be in breach of NPP 4.2 (see Section 7.7 later herein).

According to Mr Graham Henley, Director, PricewaterhouseCoopers, in evidence to the Joint Committee on the Australian Crime Commission on 21 July 2003, presently the larger ISPs only retain proxy logs for 24 hours:

"We have cases that are quite common, where people use ISPs to connect to their web browser and to surf the Internet. ... if that connection activity is controlled by the Internet proxy server-a machine that will basically store logs of all the users connected to that ISP over time-generally you would get 24 hours for the larger ISPs, purely because of the volume of records that that ISP has to keep. ... I would like to see in those instances [retention for] at least seven days."

We note that is the period for which the IIA Code requires proxy logs to kept.

As discussed in the Introduction to this submission, the requirement to collect and retain "Other Data" establishes a de facto extension of the interception of telecommunications regime currently governed by the Telecommunications (Interception) Act 1979. It a huge extension in relation to LEAs and it also enables private sector organisations to access information that would not ordinarily be retained, in relation to investigation of activities that are not criminal offences.

The mass retention requirements will enable agencies and private sector organisations to obtain details of an individual's entire activities over the course of seven days or more. This is vastly more privacy intrusive than the interception of telephone calls which requires an interception warrant. Even if it could be shown to be justified, it should not be implemented by Industry Code. It is a matter that should be subject to public and Parliamentary debate and scrutiny.

According to PricewaterhouseCoopers, apparently some ISPs are already, in effect, intercepting and using communications data for the purpose of assisting private sector organisations:

"Mr Henley-Probably 70 per cent of the computer forensics and investigations work that we do would come from the private sector. ...A lot of work recently has related to the theft of confidential commercial information. This usually involves employees going from one business to the next. Some of our big clients are involved in the software industry, so we do a lot of work with the theft of intellectual property and people distributing intellectual property online. ...
...
If we come across an instance where we need [ISP records], because of my ex law enforcement association - only because of our in-house knowledge - we directly ring the law enforcement liaison officer for the larger ISPs and say to them: 'We need you to preserve the records now. We don't know whether this will go to law enforcement, but it may go to the civil courts. We may come back with a subpoena.' ...

Mr SERCOMBE-Do ISPs invariably comply with that request?

Mr Henley-Usually.

Mr SERCOMBE-But not always?

Mr Henley-I have had instances where the ISPs are reluctant to even talk to a private sector organisation.

Mr SERCOMBE-You cannot go around and have a friendly chat with them?

Mr Henley-No. We ring them and we explain the situation. If they preserve the records for us, well and good; if they do not, there is not much we can do."

EFA believes that use of information. that relates to the contents or substance of a communication that has been or is being carried by an ISP, for the purpose of compiling records in response to a request made by a private sector organisation would be in breach of the Telecommunications Act 1997. It is not a use authorised by Section 280. EFA recommends the IIA Code be amended to make expressly clear that "Other Authorised Process" defined in the Code does not include use or disclosure of information in response to requests from private sector organisations unless such requests are supported by a court order.

"7.6 LEAs understand that ISPs cannot verify the identity of a person using a Customer's log-in details. LEAs also understand that CLI information is generally not made available to ISPs at this stage. Accordingly, ISPs cannot verify whether:

(a) Personal Data provided by a Customer is accurate in every respect;

(b) a Customer has logged in using any particular and identifiable phone service or line."

The above should note that even if an ISP has received CLI information, an ISP cannot verify whether a Customer has logged in using a particular phone service or line.

In addition, it should note that ISPs cannot verify whether a particular Customer was engaged in the activities indicated by proxy logs or any of the other records defined as "Other Data". In this regard, incorrectly configured computers, or computers that have been compromised by a virus, worm or "trojan horse", can be used to perform Internet activities (including accessing web sites) without the knowledge or control of the owner of that computer. In such cases, logs held by ISPs cannot differentiate between activity initiated by the owner of the computer, and may have the effect of implicating innocent Internet users in criminal activity.

"7.7 The information referred to in sections 7.1, 7.4 and 7.5 will be retained by the ISP for the purposes of this Code for a minimum period of:
(a) for Personal Data, 6 months from the date a Customer ceases to be Customer, or for 12 months after the creation of the record; whichever is the greater;
(b) for Operational Data, 6 months from the date of creation of such data;
(c) for Other Data, 1 week after creation of the record.
..."

Compliance with the minimum retention periods is likely to place an ISP in breach of NPP 4.2. As stated in the Federal Privacy Commissioner's NPP Guidelines:

"NPP 4.2 requires an organisation to take reasonable steps to destroy or permanently de-identify personal information if it is no longer needed for any purpose under NPP 2. Purposes under NPP 2 could include a legal requirement to keep the personal information."

As there is no legal requirement for ISPs to keep data about all their customers for the periods set out in the IIA Code, an ISP will be in breach of NPP 4.2 if it retains personal information that it does not need to keep for the primary purpose for which it was collected or for a secondary purpose permitted by NPP 2. Retaining information merely because compliance with an Industry Code requires retention is not a purpose permitted by NPP 2. Moreover, as pointed out under Section 7.1 above, ISPs are not required to keep records just in case they receive a LEA request. The only records that may be asked for are those that are normally kept for purposes such as billing, as stated in the ACA Telecommunications and Law Enforcement Manual:

"4.6 Telecommunications organisations do not have to keep CCRs [call charge records] of a special nature or in a special format for the purposes of law enforcement or security agencies. The records that may be asked for are those which the carrier or service provider keeps for the organisation's own purposes (such as billing). CCRs do not have to be retained, in case they are requested by a law enforcement agency, for longer than they would be kept for normal business practice."

Section 7.7 should be deleted. If the IIA is determined to proceed with a Code that may result in Code Subscribers finding themselves in the position of being a Respondent to a complaint lodged under the Privacy Act, then at the least the final paragraph of Section 7.7 should be extended. It states:

"7.7 ... This information will be retained by the ISP at the cost of the ISP and in a form determined by the ISP, such as electronic media or off-line storage such as CD-ROM, capable of being accessed and read by the ISP during the retention period."

The above should draw Code subscribers' attention to their obligation to secure retained data in compliance with NPP 4.1 of the Privacy Act which states:

"NPP 4 Data security
4.1 An organisation must take reasonable steps to protect the personal information it holds from misuse and loss and from unauthorised access, modification or disclosure."

and that, as stated in the NPP Guidelines, reasonable steps may consist, inter alia, of maintaining:

  • physical security - by adopting ... systems to detect unauthorised access;
  • computer and network security - by adopting measures to protect computer systems and networks for storing, processing and transmitting personal information from unauthorised access, modification and disclosure;
  • personnel security - by adopting procedural and personnel measures for limiting access to personal information by authorised staff for approved purposes and controls to minimise security risks to an organisation's IT systems.

It is of considerable concern that ISP log-in records (including calling numbers captured, dates and times of log-in, user names, etc) and other activity records exist in a format that can be easily altered by any person who has access to same, in the same manner that a text or word processing document can be changed. This is of even greater concern in the context of retention for long periods and potential off-site storage. The Code should specifically require Code subscribers to restrict access to databases and records containing information about customers and their use of the Internet to specifically authorised staff who need access to undertake a necessary function; and establish an enquiry audit trail on such databases and records so that staff accesses can be recorded and the audit trail can be used in the investigation of any alleged unlawful disclosure, use or modification of that information.

"7.8 The retention periods set out in section 7.7 are a minimum standard only and ISPs may retain Personal, Operational and Other Data for longer periods at their discretion whilst at all times complying with the Privacy Act."

Section 7.8 should be deleted. It is unnecessary and has the effect of implying that retention for the Code's minimum specified periods complies with the Privacy Act which is not necessarily factual.

"7.9 ISPs will not be required, unless in response to a proper TI Warrant or Other Authorised Process, to retain or deliver to the LEAs information relating to the content or substance of any communications of its Customers (see further section 10 below)."
"7.10 ISPs will not be required, unless in response to a proper TI Warrant, Certificate or Other Authorised Process, to retain or deliver to the LEAs information relating to usage by a Customer of the ISP's services, including information as destination sites and particular tasks undertaken by a Customer during any session they are logged into the ISP's network."

Sections 7.9 and 7.10 above contradict Section 7.7.

Section 7.7 states that information "will be retained by the ISP" for specified minimum periods, while Sections 7.9 and 7.10 state "ISPs will not be required, unless in response to [a LEA request], to retain...information". Sections 7.9 and 7.10 state the situation under existing law, that is, that ISPs are not required to retain information unless they receive a specific lawful request from a LEA to retain certain information pertaining to a particular user. Section 7.7, which has no basis in law, should be deleted.

Section 7 of the Code does not achieve the objective stated in Section 3.1(b) of providing clear guidelines. Instead it creates confusion.

Up ArrowGo to Contents List

Section 8 - ISP obligations in relation to provision of assistance to LEAs - LEA initiation of request

"8.1 LEAs will ordinarily initiate a request for disclosure of information or documents where a third party, such as a customer of an ISP, is a victim, suspect or witness of the particular matter being investigated. For example, where a person is suspected of committing a fraud or other criminal offence by 'spoofing' an email account maintained with an ISP, and a LEA requires details as to usage of that email account or the person in whose name the email account is registered, the ISP may respond to a request made by the LEA for disclosure of information or documents."
"8.2 Except as noted in section 8.3 below, LEAs should initiate all requests for information relating to carriage services supplied, or the affairs or personal particulars of a Customer, through the submission to the ISP of a Certificate issued pursuant to section 282 of the Act. ..."

We note that the definition of LEAs includes "National Security Agencies". We doubt that ASIO has agreed to, or will, initiate requests via an s.282 certificate, given s.283 of the Telecommunications Act 1997 specifically does not require ASIO to provide a Certificate.

Why does Section 8.2 state "Except as noted in section 8.3 below"? Section 8.3 does not appear to contain any exception to 8.2.

"8.2 ... Attached and marked "A" is a form of certificate which ISPs and LEAs agree is appropriate to satisfy the requirements of the ACA as well as achieve the purposes of the Act."

We observe that the crucial document - Attachment A - is not annexed to the draft Code issued for public consultation. We request that a copy of the document be provided to us and hope that it will be in accord with the ACA's Determination of Requirements - Certificates under subsections 282(3), (4) or (5).

"8.3 Information which may be requested pursuant to a Certificate includes Personal Data, Operational Data and Other Data as referred to in section 7 above."

Section 8.3 does not comply with Section 282(6) of the Telecommunications Act 1997 and also contradicts Section 10.1 of the Code.

Section 8.3 provides that a Certificate is sufficient to disclose "Other Data". However, "Other Data" includes "proxy logs (IP Address, Time, URL)". The URL in that information relates to the contents or substance of a communication. "Other Data" also includes "newgroups logs" and "FTP logs" which would include the subject line of a newsgroup message, or the name of the file down loaded, respectively, which relate to the contents or substance of a communication. (We note that "Other Data" does not include the subject line of an email message.)

Section 282(6) of the Telecommunications Act 1997 states that Certificates "do not apply to the disclosure by a person of information or a document that relates to:
(a) the contents or substance of a communication that has been carried by a carrier or carriage service provider; or
(b) the contents or substance of a communication that is being carried by a carrier or carriage service provider (including a communication that has been collected or received by such a carrier or provider for carriage by it but has not been delivered by it)." [emphasis added]

Hence an ISP who discloses such information in response to a Certificate will be in breach of the Act. Clause 8.3 of the Code, in effect, advises ISPs to breach the Act.

Section 8.3 of the Code, or the list of information deemed to be "Other Data" must be amended to comply with the Act, that is, a warrant is required for release of above information to a LEA, not a Certificate (and not "Other Authorised Process" as defined in the Code - see Section 10.1).

Up ArrowGo to Contents List

Section 10 - Content of Communications

"10.1 Section 280 of the Act provides for Authorisation By or Under Law. Division 2 does not prohibit (ie make it an offence) the disclosure/use of information (including content) in connection with a law enforcement agency if it is required or authorised under TI Warrant or Other Authorised Process. This section does not expressly authorise the disclosure, it simply exempts the disclosure from the prohibition so that the disclosure under TI Warrant or Other Authorised Process will not amount to an offence under the Act. ..."

The statement that "Division 2 does not prohibit" is not correct. In fact, Division 2 sets out a blanket prohibition on disclosure/use of information together with penalties. Division 3 contains exceptions to the offences created by Division 2.

As discussed under Section 5 above, the definition of "Other Authorised Process" is too wide and should be amended. In addition, the draft Code's definition is unsuitable for use in the way it is used in Section 10.1 above.

Section 10.1 indicates that disclosure of information to a law enforcement agency may be required or authorised under "Other Authorised Process" which, as defined in the Code, does not necessarily mean a warrant. That is not correct. Section 280(1)(a) states that in connection with the operation of a law enforcement agency, the disclosure or use must be required or authorised under a warrant. This is also stated in the ACA Telecommunications Law Enforcement Manual:

"2.3 ... Warrants are only required -
* ...
* where S. 280 of the Act, Authorisation by or under law, is used rather than S. 282. It is a requirement that where an enforcement agency uses this section, it must have a warrant."

Section 10.1 commences with information about Section 280 and then inexplicably and confusingly moves on to the matter of certificates under Section 282 as quoted below. The section would be more readily comprehensible if it was split into two parts and the part about s.282 placed after existing Section 10.2.

"10.1 ... LEAs and ISPs agree that requests should not be made via a Certificate for the disclosure by a person of information or a document that relates to:

(a) the contents or substance of a communication that has been carried by an ISP; or

(a) the contents or substance of a communication that is being carried by a ISP (including a communication that has been collected or received by such an ISP for carriage by it but has not been delivered by it)."

Whether LEAs and ISPs "agree" about the above or not, Section 282(6) of the Telecommunications Act 1997 specifically states that Certificates under Section 282(3), (4) and (5) are not applicable to the disclosures referred to above. An ISP who discloses such information in response to a Certificate will be in breach of the Act.

The Code should include a section similar to the above which states that: "...LEAs and ISPs agree that requests should not be made via an uncertified request under s.282(1) or (2) for [disclosure of information or a document that relates to contents or substance]". Such a section would be consistent with the apparent intent of Section 8.2 in relation to information that does not relate to contents or substance.

"10.2 The Interception Act governs the access to communications which are in passage over the telecommunications system. If a communication is in passage over the telecommunications system, a LEA will require a TI Warrant. ..."

The sentence above should be changed, for improved clarity, to "If a communication is in passage over the telecommunications system, a LEA will need to obtain a TI Warrant".

"10.2 ... Where an ISP can satisfy itself that a communication has completed its passage over the telecommunications system, then a LEA may be granted access to the communications by some other lawful means such as Other Authorised Process."

The above should point out that a communication has not completed its passage until it has been read, or otherwise consciously dealt with, by the intended recipient (C'th Attorney-General's Media Release, 18 December 2001). It should also note that "some other lawful means" in relation to a stored communication that has completed its passage does not include a request under Section 282 whether certified or not and that, in relation to a LEA, "Other Authorised Process" means a warrant (as discussed under Section 10.1).

"10.3 Without limiting the concepts of 'content' or 'substance of communication', ISPs and LEAs agree that the following do constitute content and/or substance of communication:

(a) any voice message held as stored voicemail;

(b) the text message held as stored email;

(c) a posting to a newsgroup.

The "to" and "from" address line of an email, and any 'extended header' addressing information associated with routing a message from its originating point to its destination, is not content and/or substance of information. This information where available may be provided by an ISP to a LEA pursuant to sections 7, 8 and 9 above."

The end of the second last sentence above should be changed to "substance of a communication" instead of "substance of information".

An additional item (d) should be added to Section 10.3 stating "the subject line of an email message or a newsgroup posting".

Up ArrowGo to Contents List

Section 11 - Processes for disclosure and cooperation

"11.1 ISPs will ensure that the following processes are in place for receiving and responding to all requests from LEAs under sections 282 and 283 of the Act for Customer information. These processes should ensure that:
(a) A person is nominated as primary point of contact in the ISP for interaction with LEAs. That person's business hours and out-of-hours contact details will be provided to the LEAs;
(b) An alternative or secondary point of contact is also nominated as a point of contact if the primary contact is unavailable for any reason. That person's business hours and out-of-hours contact details will be provided to the LEAs;
(c) Staff designated by the ISP to respond to a LEA request have been made available at the request of a LEA for police checks and security clearances as requested by the LEA;
(d) Requests by LEAs for assistance are dealt with promptly;
(e) Information disclosed in response to requests is forwarded in an agreed manner to a pre-arranged destination;
(f) Staff designated by the ISP to respond to a LEA request are fully briefed in relation to their obligations under Parts 13 and 14 of the Act and this Code."

Section 11.1 imposes a regulatory burden difficult for small ISPs and intrusive on staff members' privacy (police checks and security clearances). This adds to the burden of data retention imposed by Section 7 and "prompt" retrieval and provision of same.

Section 11.1(e) should require information to be forwarded in a secure manner, not solely an 'agreed manner'. Similarly in relation to Section 11.3(d).

In relation to Section 11.1(f), by whom are staff to be "fully briefed"?

"11.2 ISPs will undertake the following procedures prior to contacting, or advising its Customers to contact a LEA in respect of any particular suspected criminal activity, including fraudulent activity or threat to national security: ..."

We consider it astounding that the Code requires an ISP to potentially waste time undertaking a range of time-consuming preliminary investigations prior to contacting, or advising a Customer to contact, a LEA about a threat to national security. We consider the Code should recommend that ISPs undertake preliminary investigations as applicable to a particular circumstance and also allow ISPs to use their own discretion as to whether it appears necessary to contact a LEA urgently, at least in the case of threats to national security.

Up ArrowGo to Contents List

Conclusion

The Code fails to take into sufficient account the existing provisions of the Telecommunications Act 1997 and the Privacy Act 1988. Compliance with various provisions of the Code is likely to place an ISP in breach of one or both of those Acts.

The data collection and retention provisions of the Code seek to establish a de facto extension of the telecommunications interception regime, enabling access to vastly more communications and personal information than results from telephone call intercepts under warrant, without any provisions ensuring accountability, transparency and judicial and Parliamentary oversight.

No information has been provided to the public or the Parliament to even suggest that the problems allegedly being dealt with are sufficiently serious to warrant the massive invasion of Internet users' privacy that would result.

Existing documents issued by the Australian Communications Authority provide a clearer and more accurate summary of ISPs' obligations under the law than the IIA Code.

The Code is unnecessary and should be abandoned.

Up ArrowGo to Contents List

EFA Site Navigation:

You are here: EFA Home » Publications » Submission to IIA re draft Cybercrime Code of Practice

Related Resources: EFA Home » Issues » Privacy » On-line Surveillance