Issue sheets on Bill C-22 (SECU)

Part 1: Timely access to data and information

Part 1: Notable differences between Bills C‑2 and C‑22

Speaking points

• Part 1 of Bill C‑22 differs from its predecessor in several ways.
• Many of these changes are distinct improvements that reflect some of the feedback that the Government received on Bill C‑2.
• However, certain changes have raised new privacy considerations, and other privacy risks have still not been fully addressed.

Background

• Part 1 reintroduces the lawful-access provisions originally contained in Part 14 of Bill C‑2, with several notable differences that have implications for privacy (summarized below).

Part 1: Key privacy risks

Speaking points

• Part 1 of Bill C‑22 improves upon its predecessor in meaningful ways but also retains several notable privacy risks, including:
  • the definition of subscriber information is too broad in light of the threshold required to access it (reasonable suspicion);
  • the range of persons or entities from whom subscriber information can be sought is too wide;
  • judicial oversight of orders and international requests to produce subscriber information is inadequate; and
  • the term “information available to the public” is undefined, increasing the likelihood that it will be interpreted broadly.
• In my view, these issues are serious enough to justify amendments.

Background

Part 1: Confirmation-of-service demand

Speaking points

• The proposed new confirmation-of-service demand is a significant improvement over the information demand proposed in Bill C‑2.
• By narrowing the scope of what can be demanded and from whom, the new power recognizes the privacy interests that attach to much of the information that service providers collect from and about Canadians.
• The timelines for recipients to apply for court review remain short, but in my view, this is less concerning given the power’s reduced scope.

Background

• Bill C‑2 would have amended the Criminal Code (cl. 158, s. 487.0121) and CSIS Act (cl. 185, s. 20.21) to create an information demand that would have empowered law enforcement and CSIS to compel a range of information from any person or entity who “provides services to the public,” without prior judicial authorization, based on a threshold of reasonable suspicion.
• Information that could have been demanded would have included: whether the person provides or has provided services to a given subscriber, client, account, or identifier; whether the person has any information relating to the specified subscriber, client, account, or identifier; the country, province, and municipality in which services are or were provided; when the person began or ceased providing services; and if known, the name or identifier of any other person who provides services to the public that provides or has provided services to the specified subscriber, client, account, or identifier, as well as specified information about those services.
• Recipients of demands under the Code would have had just five days after the day the demand was made to apply to a judge for review (cl. 158, s. 487.0121(7)). Under the parallel power in the CSIS Act, recipients would have had to apply for review by the deadline specified in the demand (potentially just 24 hours) or within five days of the day the demand was made – whichever was shorter (cl. 185, s. 20.22).
• Bill C‑22 replaces the information demand with a much more narrowly tailored confirmation-of-service demand that could be made only to telecommunications service providers and require only that they confirm whether or not they provide or have provided telecommunication services to a subscriber, client, account, or identifier (cl. 5, s. 487.0121; cl. 31, CSIS Act s. 20.22).
• New subsections would also prohibit the making of a confirmation-of-service demand if the confirmation would disclose medical information or information that is subject to solicitor-client privilege (cl. 5, s. 487.0121(3); cl. 31, CSIS Act, s. 20.22(2)).
• The timeframes for recipients to apply for review are substantially the same, but Bill C‑22 has clarified that recipients could have up to five business days after the day the order is received (cl. 5, s. 487.0121(8)), though potentially still just 24 hours under the CSIS Act (cl. 31, s. 20.22(3)).

Part 1: Production order for subscriber information

Speaking points

• The codification of a specific process for law enforcement to obtain subscriber information, subject to judicial oversight, is a positive development given the potential sensitivity of such data.
• However, aspects of the proposed production order continue to raise significant privacy concerns, including the breadth of the underlying definition of subscriber information, the range of persons who may be compelled to produce it, and the extent of subscriber information that they would be compelled to produce.

Background

• Bill C‑22 would add a new provision to the Code (cl. 6, s. 487.0142) empowering peace and public officers to ask a judge or justice to order any “person who provides services to the public” to produce “all” subscriber information in their possession or control that “relates to” information specified in the order, based on reasonable suspicion.
• Like Bill C‑2, Bill C‑22 would also reduce the timeframe for recipients of production orders under the Code – including general production orders, as well as production orders for subscriber information and transmission, tracking, or financial data – to apply for court review: Bill C‑2 would have set a deadline of five calendar days after the order is made, which in Bill C‑22 has been increased to ten business days after the order is received (cl. 10, Code, s. 487.0193(1)).^{Footnote 1}
• Other privacy-specific concerns include:
  • The proposed definition of subscriber information (cl. 4, Code, s. 487.011) would capture not only basic subscriber information (e.g., name, address, telephone number) but also such open-ended categories as “information that may be used to identify” the subscriber and any “information relating to the services provided”.
  • The production order could be served on any “person who provides services to the public” (e.g., TSPs, healthcare providers, lawyers, financial institutions, dating apps) based on a threshold only of reasonable suspicion (cl. 6, Code, s. 487.0142).^{Footnote 2}
  • Given the wording of the provision and the related Form 5.0052 (cl. 25), recipients would be compelled to produce “all the subscriber information” in their possession or control that “relates to” information specified in the order. As a result, while the judge or justice making the order could specify what the subscriber information must relate to (e.g., a person’s name, an <abbr title=">IP address, transmission data), they would not otherwise have discretion to directly limit the subscriber information that must be produced.

Part 1: Definition of “subscriber information”

Speaking points

• The proposed definition of “subscriber information” is not limited to what has been characterized as “basic subscriber information” but would also capture information that may be more revealing (such as details about the nature and timeframe of services provided).
• Depending on the service, such information could be highly sensitive, either in itself or because of the connections or inferences about an individual that it might reasonably support.
• The Supreme Court’s decisions in Spencer and Bykovets indicate that this kind of information could reasonably attract a heightened expectation of privacy, yet Bill C‑22 would require only reasonable suspicion in order to access it.

Background

• Bill C‑2 would have defined “subscriber information” as (cl. 157, Code, s. 487.011):
  1. information that the subscriber provided to the provider in order to receive the services (e.g., their name, pseudonym, address, telephone number and email address);
  2. identifiers assigned to the subscriber by the provider (e.g., account numbers); and
  3. information relating to the services provided to the subscriber, including (i) the types of services provided, (ii) when the services were provided, and (iii) information that identifies the devices, equipment or things used by the subscriber in relation to the services.
• Bill C‑22 substantially preserves this definition but substitutes a new, potentially broader paragraph (a): “information that may be used to identify the subscriber or client, including their name, pseudonym, address, telephone number and email address” (cl. 4, Code, s. 487.011).
• Potential issues with the definition are magnified by the other provisions in Part 1 that rely on it. For example, the proposed production order for subscriber information (cl. 6, Code, s. 487.0142) could be served on any “person who provides services to the public.” This means that, at least in some cases (e.g., healthcare providers, lawyers, financial institutions, certain apps and online services), service providers could be compelled to produce highly sensitive information about clients or subscribers based on a threshold only of reasonable suspicion.
• By contrast, the threshold for the Code’s general production order (s. 487.014), which law enforcement currently relies on to access subscriber information, is reasonable belief.
• The types of subscriber information that would have been accessible under previous lawful-access proposals – namely, Bills C‑74 (2005), C‑47 (2009), C‑52 (2010), and C‑30 (2012) – were defined more narrowly (see related issue sheet).

Part 1: Definitions of “subscriber information” in previous bills

Speaking points

• In contrast to Bill C‑22, previous lawful-access bills tended to treat subscriber information as a much narrower concept.
• Those bills generally focused on information that would identify a subscriber of a telecommunications service, and typically specified a closed list of discrete identifiers to be produced, such as a subscriber’s name, address, telephone number, and IP address.
• Defining subscriber information in such a way would reduce the risk that sensitive personal information will be produced, thereby making reasonable suspicion a more appropriate and defensible threshold.

Background

• Bill C‑22 would define “subscriber information” as (cl. 4, Code, s. 487.011):
  1. information that may be used to identify the subscriber or client, including their name, pseudonym, address, telephone number and email address;
  2. identifiers assigned to the subscriber by the provider (e.g., account numbers); and
  3. information relating to the services provided to the subscriber, including (i) the types of services provided, (ii) when the services were provided, and (iii) information that identifies the devices, equipment or things used by the subscriber in relation to the services.
• Under s. 17(1) of Bill C‑74 (38-1, 2005), “subscriber information” was considered any information respecting the name and address of a subscriber to a telecommunications service provider’s (TSP) telecommunications services and respecting any other identifiers associated with the subscriber. For purposes of s. 17, the Governor in Council would have had authority to make regulations specifying information to be provided with respect to name, address, or other identifiers, and prescribing other identifiers (ss. 31(1)(e)(i)-(ii)).
• Under s. 16(1) of Bill C‑47 (40-2, 2009) and Bill C‑52 (40-3, 2010), “subscriber information” was considered any information in a TSP’s possession or control respecting the name, address, telephone number, and email address of a subscriber to any of the TSP’s telecommunications services, and the IP address, mobile identification number, electronic serial number, local service provider identifier, international mobile equipment identity number, international mobile subscriber identity number, and subscriber identity module card number associated with the subscriber’s service and equipment.
• Under s. 16(1) of Bill C‑30 (41-1, 2012), “subscriber information” was considered identifying information in a TSP’s possession or control respecting the name, address, telephone number, and email address of a subscriber to any of the TSP’s telecommunications services, and the IP address and local service provider identifier associated with the subscriber’s service and equipment.

Part 1: Production request to foreign service providers

Speaking points

• I understand that several amendments in Bill C‑22 are meant to address issues that law enforcement may encounter when investigating criminal matters, including procedural challenges and delays related to obtaining access to private data stored in other jurisdictions.
• For example, Bill C‑22 would create a new mechanism for law enforcement to make requests to foreign entities to produce transmission data and subscriber information voluntarily.
• While such requests would be subject to Canadian judicial oversight, they raise a number of privacy considerations given the breadth of the Bill’s definition of “subscriber information” and the potential volume of cross-border data-sharing that they would facilitate.

Background

• Like Bill C‑2, Bill C‑22 would amend the Code to enable law enforcement to seek court authorization to request that a foreign telecommunications service provider (TSP) voluntarily produce transmission data (as defined in the Code) or subscriber information (as defined in the Bill), based on a threshold of reasonable suspicion (cl. 7, s. 487.0181).
• However, Bill C‑22 expands the types of foreign entities to whom such requests could be made to include providers of “services by a means of telecommunication” as well as TSPs.
• Given that foreign entities with no physical or virtual presence in Canada are under no legal obligation to comply with Code production orders, the Department of Justice (JUS) maintains that this proposed new tool is necessary “to keep investigations efficient” in light of the “long and cumbersome” mutual legal assistance process that domestic law enforcement currently relies on (JUS Backgrounder on Bill C‑22).
• JUS has also indicated that these provisions, along with Part 1’s amendments to the Mutual Legal Assistance in Criminal Matters Act (MLACMA), are designed to enable Canada to ratify the Second Additional Protocol to the Convention on Cybercrime (2AP), which aims to facilitate cross-border law-enforcement cooperation in criminal matters.
• Among other things, the 2AP requires signatories to implement measures that empower competent authorities to submit orders directly to service providers in other territories – outside the framework of a mutual legal-assistance treaty – in order to obtain subscriber information in their possession or control (Article 7).
• The proposed new foreign production request (and MLACMA amendments) may also be intended to facilitate a Canada-US agreement under the US Clarifying Lawful Overseas Use of Data Act (CLOUD Act), which aims to improve law-enforcement access to electronic data held across borders by communications-service providers.

Part 1: New mutual legal-assistance process

Speaking points

• Certain provisions in Bill C‑22 are designed to enable or facilitate cross-border data-sharing between Canadian and foreign law-enforcement authorities, including the proposed amendments to the MLACMA.
• I am pleased to see that, under the proposed new MLACMA process, foreign bodies would not be permitted to order Canadian service providers to produce transmission data or subscriber information directly. Instead, foreign production orders would have to be approved by the Minister of Justice and a Canadian court.
• However, the new process lacks certain privacy safeguards and also relies on the Bill’s overly broad definition of subscriber information.

Background

• According to a Justice backgrounder, existing processes under the Mutual Legal Assistance in Criminal Matters Act (MLACMA) are “not efficient or effective for the transfer of low-privacy digital evidence to Canada’s international partners.”
• Like Bill C‑2, Bill C‑22 would create a new MLACMA process (cl. 29, s. 22.07) whereby foreign bodies may seek the approval of the Minister of Justice to have a competent authority^{Footnote 3} in Canada apply to a court to enforce a foreign order that would compel a person in Canada to produce transmission data or subscriber information.
• The court could make the foreign order enforceable if satisfied that it meets the Criminal Code’s criteria for the making of production orders for transmission data and subscriber information (i.e., reasonable grounds to suspect).
• As in Bill C‑2, the court would not be able to impose conditions on foreign orders when making them enforceable, and there are no requirements for information-sharing agreements or for the Minister of Justice to report on the use of the new process.
• Together with the new production request to foreign service providers, the MLACMA amendments are likely intended to enable Canada to ratify the Second Additional Protocol to the Convention on Cybercrime and to enter into other data-sharing arrangements with international law-enforcement authorities.

Part 1: Timeframes for challenging Criminal Code production orders

Speaking points

• The Criminal Code currently affords recipients of an order to produce documents or data up to 30 days to give notice of their intention to challenge it.
• Bill C‑2 would have set a standard timeframe to apply for review of just five days after the day on which the order was made.
• This change would have rendered the ability to challenge such orders less meaningful by making it significantly more difficult to do so in practice.
• Bill C‑22 mitigates this concern to some extent by increasing the proposed time limit to ten business days after the day on which the order was received.

Background

• Under the current s. 487.0193 of the Criminal Code, the recipient of a production order made under ss. 487.014 to 487.018 may apply to a justice or judge to revoke or vary it, provided that the recipient gives notice of their intention to do so within 30 days after the day on which the order was made.
• Bill C‑2 would have amended s. 487.0193(1) to require that any such application be made before the deadline specified in the production order, “but not later than five days after the day on which the order was made” (cl. 163). This reduced time limit would have applied to general production orders (s. 487.014); production orders for transmission data (s. 487.016), tracking data (s. 487.017), and financial data (s. 487.018); and the proposed new production order for subscriber information (cl. 159, s. 487.0142).
• In Bill C‑22, by contrast, the proposed time limit for challenging all such production orders has been increased to “not later than 10 business days after the day on which the order was received” (cl. 10, s. 487.0193(1)).
• Although Bill C‑22’s proposed timeline is a distinct improvement over what was contemplated in Bill C‑2, the change from the current standard (which affords recipients up to 30 days to give notice of their intention to apply for review) will still make it more difficult for recipients to mount a challenge.

Part 1: Information “available to the public”

Speaking points

• Part 1 would amend the Code to declare, “for greater certainty,” that law enforcement may collect and use information that is “available to the public” without judicial authorization.
• However, it is not always clear what “publicly available” means in practice. For example, is information that can be purchased from a data broker, that is posted in a registration-only forum, or that has been stolen and leaked on the dark web publicly available?
• In my view, even where an individual has chosen to make their personal information publicly accessible in certain circumstances, they do not automatically relinquish any privacy interest in it more generally.
• For those reasons, I recommend amending the Bill to clarify that “information available to the public” excludes information in respect of which a person maintains a reasonable expectation of privacy.

Background

• Like Bill C‑2, Bill C‑22 would amend the Code to assert that, “for greater certainty,” no production order, warrant, or confirmation-of-service demand is necessary for law enforcement to receive, obtain, and act on “any information that is available to the public” (cl. 11, s. 487.0195(4)). The phrase “available to the public” is not defined in the bill or the Code.
• Regulations under PIPEDA limit the concept of publicly available personal information to certain information in publicly available phone directories; professional or business directories, listings, and notices; government registries; legal documents; and publications.
• The Privacy Act (PA) does not define “publicly available” personal information but excludes such information from the limitations on use and disclosure set out in ss. 7 and 8 (s. 69(2)).
• Conversely, “publicly available information” is defined in the Communications Security Establishment Act to exclude “information in respect of which a Canadian or a person in Canada has a reasonable expectation of privacy” (s. 2). In a 2020 white paper on PA reform, the Department of Justice proposed inserting a definition of “publicly available” personal information with an identical exclusion.
• In an April 2026 white paper on PA reform, TBS has proposed defining “publicly available personal data” to mean data that is “currently available to or accessible by the public at large for free, on request, by subscription or by purchase” (including data published in print or online, in public records, or in a public forum). It would, however, exclude “personal data that has been made public by accident or unlawfully.”

Part 1: “For greater certainty” request provisions and safe harbours

Speaking points

• Police have a common-law authority to make enquiries about matters that are not subject to a reasonable expectation of privacy.
• Like Bill C‑2, Bill C‑22 would confirm this authority by amending the Code to clarify the circumstances in which law enforcement may ask a person or service provider to voluntarily disclose information.
• However, Bill C‑22 improves on its predecessor by clarifying that law enforcement may ask a person to voluntarily disclose information only if they are “not prohibited by law” from disclosing it.
• This change should ensure that organizations do not receive legal immunity if they voluntarily disclose personal information in violation of PIPEDA in response to a request from law enforcement.

Background

• The Code currently asserts, “for greater certainty,” that no production order is necessary for an officer to ask a person to voluntarily provide a document that the person “is not prohibited by law from disclosing,” and that a person who provides a document “in those circumstances” does not incur any criminal or civil liability for doing so (s. 487.0195).
• Bill C‑2 would have amended that provision to assert, “for greater certainty,” that no information demand would be necessary for an officer to ask a service provider to voluntarily disclose any information that could be compelled by an information demand, and that a service provider would not incur liability for disclosing it (cl. 164, ss. 487.0195(1.1) and (2)).
• Since Bill C‑2’s amendments omitted the “not prohibited by law” language in the Code, they would have shielded service providers from liability for voluntarily disclosing personal information in response to a law-enforcement request – even where the service providers were prohibited by law from disclosing it (e.g., by PIPEDA).
• Bill C‑22 has addressed this problem by instead amending the Code to clarify, “for greater certainty,” that no confirmation-of-service demand or production order is necessary for an officer to ask a TSP or person to voluntarily provide a confirmation, document, or information that the TSP or person “is not prohibited by law” from providing or disclosing, and that a TSP or person who does so “in those circumstances” does not incur any criminal or civil liability for doing so (cl. 5, s. 487.0121(12); cl. 11, ss. 487.0195(1) and (2)).
• In R. v. Spencer, 2014 SCC 43, the Court confirmed that police have a “common law authority […] to ask questions relating to matters that are not subject to a reasonable expectation of privacy” and held that “for greater certainty” provisions like s. 487.0195 do not create any police search and seizure powers (paras. 71, 73).

Part 1: Computer-data examination warrant

Speaking points

• The creation of specific rules for the examination of computer data is a positive development in that, as the courts have recognized, computer searches are qualitatively different than other kinds of search.
• However, aspects of the proposed amendments create privacy risk. In particular, a warrant authorizing the examination of computer data would appear to apply not only to data “contained in,” but also “available to,” a computer system.
• As a result, unless the issuing judge or justice limits the scope, a computer-data examination warrant could authorize expansive searches of data stored locally and online.

Background

• Like Bill C‑2, Bill C‑22 would amend the search-warrant provisions of the Code, the Controlled Drugs and Substances Act, and the Cannabis Act to empower a judge or justice to authorize the examination of computer data based on the threshold of reasonable belief.
• These provisions respond to R. v. Vu, 2013 SCC 60, in which the Supreme Court held that law enforcement may not search a computer seized during the execution of a search warrant unless (1) the warrant specifically authorizes such a search based on reasonable belief, or (2) a separate warrant authorizing the search is issued (at paras. 3, 37, 46-49).
• Although the Code already contains preservation and production orders related to computer data, the proposed provisions would create specific rules for computer searches that take place under the authority of the Code’s existing search-warrant provision (s. 487). They would also create a specific computer-data-examination warrant.
• Bill C‑2 would have empowered judges or justices to impose any conditions they deemed “fit” on such examinations (including limiting searches to specific data classes and requiring that extraction be undertaken by a person not otherwise involved in the investigation).
• Bill C‑22 has replaced this language with “any conditions that the judge or justice considers advisable to ensure that the examination is reasonable in the circumstances” (cl. 3, s. 487(2.5)). Owners of the computer system would still need to be notified of the authorization (ss. 487(2.6)-(2.7)).
• Significantly, here as in Bill C‑2, a warrant authorizing the examination of computer data that is “available to” a computer system would appear to include cloud-based data that is accessible from a computer connected to the Internet (cl. 3, s. 487(2.4).
• Moreover, it is unclear if judges or justices reviewing such warrant applications would have sufficient information to assess what restrictions should be placed on computer searches in order to limit their scope and minimize privacy impacts.

Part 1: Expanded tracking-device and transmission-data-recorder warrants

Speaking points

• Part 1’s amendments to the Criminal Code’s tracking-device and transmission-data-recorder warrants could potentially result in the collection of data related to individuals who are not under investigation (e.g., the family, friends, or associates of legitimate targets).
• The amendments would also allow police to obtain related subscriber information based on the Bill’s expansive definition of that term.
• By establishing a process to authorize multiple forms of surveillance under a single warrant, these amendments would amplify the potential invasiveness of the underlying provisions in the Criminal Code.

Background

• Under the Criminal Code, police can seek a warrant to track the location or movement of a thing (such as a vehicle) based on reasonable suspicion (s. 492.1(1)), or of a person (e.g., by way of a device usually carried or worn) based on reasonable belief (s. 492.1(2)).
• Part 1 of Bill C‑22 would expand the scope of the tracking-device warrant to permit police to obtain tracking data that relates to the location of “any similar thing” that is unknown at the time the warrant is issued, if the justice or judge is satisfied that there are reasonable grounds to suspect that the person will use, carry, or wear it (cl. 19, s. 492.1(2.1)).
• Although the judge must first determine that there are reasonable grounds to believe that a tracking-device warrant for personal movement would assist in the investigation, the expanded warrant could authorize the collection of tracking data related to a secondary device that does not belong to the target.
• The Code also allows police to seek a warrant to obtain transmission data (i.e., data that relates to telecommunications functions but does not reveal the substance, meaning, or purpose of the communication) by way of a transmission-data-recorder (TDR) warrant based on reasonable suspicion (s. 492.2).
• Part 1 of Bill C‑22 would likewise expand the scope of this warrant to permit a judge or justice to authorize the acquisition of transmission data relating to any similar means of telecommunication that is unknown at the time the warrant is issued if there are reasonable grounds to suspect that the target will use it (cl. 20, s. 492.2(1.1)).
• Similarly, Part 1 would amend the TDR warrant to allow a judge or justice to authorize the collection of certain “subscriber information” – i.e., para. (a) of the bill’s definition – from any person who provides services to the public, provided that it relates to the transmission data that the warrant has authorized law enforcement to collect (cl. 20, s. 492.2(5.2)).

Part 2: Supporting authorized Access to Information Act

Part 2: Notable differences between Bills C‑2 and C‑22

Speaking points

• The Supporting Authorized Access to Information Act proposed in Part 2 differs from the previous version in Bill C‑2 in several important ways.
• Certain changes are distinct improvements that clearly reflect some of the feedback that the Government received.
• However, other changes have introduced new privacy risks, and some persistent privacy risks have still not been fully addressed.

Background

Part 2: Key privacy risks in the SAAIA

Speaking points

• The new SAAIA incorporates meaningful improvements over the version in Bill C‑2 but also retains and creates significant privacy risks, including:
  • no express requirement that any obligation imposed on ESPs be necessary and proportionate;
  • no express prohibition on compliance with or the making of regulations and orders that would cause a systemic vulnerability;
  • no express prohibition on actions that could render systemic methods of authentication or encryption less effective;
  • no mechanism for an ESP to seek independent expert review, before a capability is imposed, as to whether that capability would cause a systemic vulnerability; and
  • no requirement that regulations and orders be subject to limits on the period during which they are in effect or to periodic review;
  • no authority for ESPs to disclose information to appropriate bodies to enable them to carry out their mandates.
• Despite the Act’s attempt to prevent systemic vulnerabilities, there is also an overarching risk that any capability introduced at the direction of government could be discovered and exploited by unauthorized persons.

Background

• Key recommendations on Part 2:
  • require that any obligation imposed under ss. 5(2) or 7(1), including with respect to the retention of metadata, be necessary and proportionate;
  • stipulate that regulations and orders “must not have the effect of” requiring an ESP to introduce, or of preventing an ESP from rectifying, a systemic vulnerability;
  • amend the definition of “systemic vulnerability” to include any actions that would render systemic methods of authentication or encryption less effective;
  • establish a mechanism for ESPs to seek an independent expert review (up front) as to whether a given capability would create a systemic vulnerability;
  • require that all regulations and orders made under ss. 5(2) and 7(1) be subject to periodic review, and/or impose limits on the period during which they remain in effect; and
  • add an exemption from the confidentiality rules in s. 15 to expressly allow ESPs to disclose information related to orders to appropriate regulatory bodies.

Part 2: Scope and objectives of the SAAIA

Speaking points

• The SAAIA would compel an exceptionally broad range of electronic service providers (ESPs) to assist government in giving effect to lawful authorities to access information under the Code and the CSIS Act.
• It is similar to laws in the US, UK, and Australia that require organizations to build technical or operational capabilities into their systems to enable or facilitate government access to information.
• Although the SAAIA includes important guardrails, obligations imposed under it could have major privacy impacts, both by enhancing the surveillance capabilities of law enforcement, CSIS, and ESPs, and by potentially compromising existing electronic data protections.

Background

• As under Bill C‑2, the SAAIA would require ESPs with a jurisdictional link to Canada to have the means to assist authorized persons in exercising authorities under the Code or the CSIS Act to access information in support of criminal or intelligence investigations.
• To that end, the Act would enable the GIC to impose a range of obligations on classes of “core” ESPs by regulation (s. 5(2)), and the Minister of Public Safety to impose analogous obligations on individual ESPs by order (s. 7(1)), including with respect to:
  • the development, implementation, assessment, testing, and maintenance of operational and technical capabilities;
  • the installation, use, operation, management, assessment, testing and maintenance of any device, equipment, or other thing; and
  • the retention of categories of metadata – including transmission data as defined in the Code^{Footnote 4} but excluding content, web-browsing history, and social-media activities – for reasonable periods of time not exceeding one year (new to Bill C‑22).
• ESPs would not be required to comply with any obligation that would cause a “systemic vulnerability” (ss. 5(5), 7(5)), which is defined as “a vulnerability in the electronic protections of an electronic service that creates a substantial risk that secure information could be accessed by a person who does not have any right or authority to do so ” (s. 2(1)).
• “Electronic service” is defined exceptionally broadly as a service, or a feature of a service, that involves electronic, digital, or other intangible information. An ESP under the SAAIA would be a provider of such services to persons in Canada, or that carries on business activities in Canada (s. 2(1)). Classes of core ESP will be prescribed by regulation (s. 5(1)).

Part 2: Key terms and definitions in the SAAIA

Speaking points

• The proposed definition of “systemic vulnerability” affords some degree of cybersecurity and privacy protection but may be variously interpreted and does not definitively rule out actions that would render systemic methods of encryption less effective.
• I am also concerned by the breadth of the definition of “electronic service provider”: it is difficult to imagine a business today that would not be in scope.
• By contrast, in its 2025 special report on lawful access, NSICOP recommended that legislation to compel intercept capability apply only to “communications service providers.”

Background

• Systemic vulnerability would be defined to mean “a vulnerability in the electronic protections of an electronic service that creates a substantial risk that secure information could be accessed by a person who does not have any right or authority to do so” (s. 2(1)).
• Electronic service would be defined to mean “a service, or a feature of a service, that involves the creation, recording, storage, processing, transmission, reception, emission or making available of information in electronic, digital or any other intangible form by an electronic, digital, magnetic, optical, biometric, acoustic or other technological means, or a combination of any such means ” (s. 2(1)).
• Electronic service provider (ESP) would be defined to mean “a person that, individually or as part of a group, provides an electronic service, including for the purpose of enabling communications,” and that provides the services to persons in Canada or carries on all or part of its business activities in Canada (s. 2(1)).
• Core provider would be defined to mean an ESP belonging to a class of ESPs set out in the (currently empty) schedule to the SAAIA, which the Governor in Council would be empowered to amend via regulation (ss. 2(1), 5(1)).
• Metadata is not specifically defined but would include “transmission data, as defined in section 487. 011 of the Criminal Code,” which includes data that is generated “during the creation, transmission or reception of a communication” and that identifies “the type, direction, date, time, duration, size, origin, destination or termination of the communication.”
• Under s. 47(1)(c) of the SAAIA, the Governor in Council would have the power to make regulations respecting “the meaning of any term or expression” for purposes of the SAAIA.
• In its 2025 special report on lawful access, NSICOP proposed defining communications service providers in such a way as to include “any service provider operating in Canada offering electronic communications services or capabilities.” This definition is much more narrowly focused than the SAAIA’s definition of electronic service provider.

Part 2: The making of regulations and orders under the SAAIA

Speaking points

• The SAAIA would now require the Governor in Council, when imposing obligations on core providers by regulation, to consider the same factors that the Minister must consider when making orders under s. 7.
• I am pleased to see that the Government has also added potential impacts on privacy protection and cybersecurity as a factor and created an oversight role for the Intelligence Commissioner over orders.
• Together, these changes should help ensure that privacy interests receive greater consideration in the making of regulations and orders.
• However, I am concerned by the lack of additional guardrails on the regulation- and order-making powers, including a requirement that obligations imposed under them be necessary and proportionate, and that they be subject to a maximum duration and/or periodic review.

Background

• Subsection 5(2) of the SAAIA would empower the GIC to impose obligations on “core providers” by regulation, while s. 7(1) would empower the Minister of Public Safety to impose obligations on individual ESPs via order.
• “Core provider” would be defined to mean an ESP belonging to a class of ESPs set out in the (currently empty) schedule to the SAAIA (s. 2(1)).
• Under ss. 5(3) and 7(3), the GIC and the Minister would have to consider the following factors when making regulations and orders, respectively:
  1. the benefits to the administration of justice;
  2. the feasibility of compliance;
  3. the costs of compliance;
  4. the potential impact on persons to whom the ESP(s) provide services;
  5. the potential impact on privacy protection and cybersecurity (new to Bill C‑22); and
  6. any other relevant factor.
• Under s. 7(2), a ministerial order would be valid only once approved in writing by the Intelligence Commissioner (IC), who would have to consider the reasonableness of the Minister’s conclusions in reaching the decision to issue the order.
• Unless revoked earlier, such an order would have effect “for the period specified in the order,” which the Minister would have broad latitude to set and extend (ss. 10-11). The SAAIA would prescribe no maximum duration for orders, and regulations under s. 5(2) would have no expiry date (i.e., no sunset provision). The IC’s approval would not be required for the Minister to extend the period during which an order has effect (s. 10(2)).

Part 2: Metadata-retention requirements under the SAAIA

Speaking points

• I am aware that many stakeholders have expressed concerns about the requirements that may be imposed under the SAAIA with respect to the retention of metadata.
• On the one hand, there are privacy-protective exclusions for content, web-browsing history, and social media activities.
• However, metadata can itself be highly revealing, especially in large volumes, because of the connections and inferences about individuals that it may reasonably support.
• For example, these provisions could compel ESPs to retain detailed records of the movements and associations of millions of innocent Canadians for up to a year, subject to no independent oversight.
• In my view, given their potential to interfere with fundamental rights, any obligations imposed under the Act – including with respect to metadata – should have to meet the standards of necessity and proportionality.

Background

• A new s. 5(2)(d) would empower the GIC to make regulations imposing obligations on “core providers” (a subset of ESPs to be named in the schedule) respecting the retention of categories of metadata – including transmission data, as defined in s. 487.‍011 of the Criminal Code – for reasonable periods of time not exceeding one year.
• A new s. 5(4) would clarify that s. 5(2)(d) does not authorize the making of regulations requiring core providers to retain information that would reveal (a) “the content – i.e., the substance, meaning or purpose – of information transmitted in the course of an electronic service,” (b) “a person’s web browsing history,” or (c) “a person’s social media activities.”
• Subsection 7(1) would empower the Minister of Public Safety to make orders with respect to individual ESPs that could impose any obligation that may be imposed via regulation.
• Since state-imposed metadata-retention obligations would restrict an ESP’s ordinary-course disposition of metadata for the purpose of facilitating law enforcement and national security investigations, and since the retention of metadata would expose affected individuals to heightened privacy risks, the imposition of such obligations may amount to a “seizure” for the purposes of s. 8 of the Charter (see Quebec (Attorney General) v. Laroche, 2002 SCC 72, at paras. 50-55).
• The lack of necessity and proportionality requirements and of independent oversight may render any such obligations constitutionally vulnerable.

Part 2: The SAAIA’s treatment of “systemic vulnerabilities”

Speaking points

• The SAAIA recognizes and seeks to mitigate the risk that obligations imposed under it could cause “systemic vulnerabilities.”
• However, in my view, the Act’s mitigation does not go far enough:
  • the definition does not explicitly include actions that would render systemic methods of authentication or encryption less effective; and
  • the Act does not strictly prohibit compliance with, or the making of, orders and regulations that would cause a systemic vulnerability (i.e., ESPs would have discretion “not to comply”).
• Given the challenge of crafting an exhaustive definition, one option would be a mechanism for ESPs to seek an independent assessment as to whether a given capability would cause a systemic vulnerability.

Background

• Under ss. 5(5) and 7(5) of the SAAIA, an ESP would “not [be] required to comply” with a provision of a regulation or order if doing so would require it to introduce – or prevent it from rectifying – a systemic vulnerability relating to its service.
• “Systemic vulnerability” would be defined under s. 2(1) as “a vulnerability in the electronic protections of an electronic service that creates a substantial risk that secure information could be accessed by a person who does not have any right or authority to do so. ” Some commentators have pointed out that, given its focus on “services,” this definition may not capture vulnerabilities in hardware, operating systems, or other underlying architecture.
• Subsection 317ZG(1) of Australia’s Telecommunications Act 1997 provides that a technical capability notice (TCN) “must not have the effect” of requesting or requiring a recipient to implement or build a “systemic vulnerability” into a form of “electronic protection” or of preventing them from rectifying such a vulnerability.
• As defined in the Australian law, the concept of “systemic vulnerability” includes any “actions that would render systemic methods of authentication or encryption less effective” (s. 317ZG(3)).
• Further, the Australian law allows TCN recipients to trigger an arm’s-length review of whether the notice should be given, including whether it would contravene the Act’s “systemic vulnerability” provision and is “reasonable and proportionate,” “practicable,” “technically feasible,” and “the least intrusive measure” available (s. 317WA).

Part 2: Confidentiality requirements

Speaking points

• Although some degree of secrecy is necessary at times for law enforcement and CSIS to do their work effectively, I am concerned that the SAAIA’s proposed confidentiality obligations may be too restrictive.
• Prohibiting ESPs from disclosing that they are subject to a ministerial order, as well as the order’s contents, could impair my Office’s ability to fully investigate certain privacy breaches.
• For example, an organization could be prevented from informing the OPC that a data breach resulted from a malicious actor’s exploitation of capabilities imposed by ministerial order.
• To avoid such scenarios, s. 15 of the SAAIA could be amended to permit ESPs to disclose information to appropriate regulatory bodies for the purpose of exercising their powers or performing their duties or functions.

Background

• Section 15 of the SAAIA would prohibit an ESP, and any person acting on its behalf, from disclosing, among other things, information contained in an order made under s. 7(1) and the fact that the ESP is subject to such an order.
• This prohibition could limit what ESPs are permitted to disclose under s. 10.1 of PIPEDA, which requires organizations to report security breaches involving personal information to the OPC as soon as feasible where it is reasonable to believe that the breach creates a real risk of significant harm to an individual.
• Under the UK’s Investigatory Powers Act 2016, a recipient of a technical capability notice is also prohibited from disclosing its existence or contents without the permission of the Home Secretary (s. 255(8)).
• However, while a recipient of a technical capability notice under Australia’s Telecommunications Act 1997 is generally prohibited from disclosing related information (s. 317ZF(1)), it may do so to oversight bodies, such as the Inspector-General of Intelligence and Security and the Commonwealth Ombudsman (ss. 317ZF(2), (3)(f)-(g)).

Part 2: Transparency and reporting

Speaking points

• I am pleased to see that the Government has added an annual-report requirement to the SAAIA under Bill C‑22.
• Requiring the Minister of Public Safety to publicly report on their activities under the SAAIA each year will help promote transparency and public trust, just as the requirement to provide unredacted copies to NSICOP and NSIRA will help promote accountability.
• However, transparency could be further strengthened by requiring the government to report annually on its use of the new lawful-access tools under Part 1 of the Bill, as is the case under lawful-access legislation in certain other jurisdictions.

Background

• A new s. 49 of the SAAIA introduced in Bill C‑22 would require the Minister of Public Safety to prepare an annual report containing the following:
  1. the number of orders made, along with information about the classes of ESPs subject to those orders and the obligations imposed;
  2. the number of orders made but not approved by the Intelligence Commissioner, along with same additional information;
  3. information about compliance orders and enforcement actions;
  4. the number of requests for assistance made under s. 14(1) and the classes of persons to whom assistance was provided; and
  5. other prescribed information.
• The minister would have to make a redacted version of the report available to the public and provide an unredacted version to NSICOP and NSIRA (ss. 49(3)-(4)).
• In Australia, law-enforcement and national security agencies have extensive reporting obligations under multiple statutes regarding their use of lawful-access tools, such as interception warrants, surveillance-device warrants, data-access warrants and authorizations, international production orders, etc.
• In the UK, the Investigatory Powers Commissioner is required to report annually to Parliament (via the Prime Minister) regarding the use of lawful-access tools under the Investigatory Powers Act 2016 (s. 234).
• Significantly, NSICOP’s 2025 special report on lawful access found no “clear, empirical data to substantiate claims by Canada’s security and intelligence organizations that they face serious lawful access challenges because of rapidly evolving technology” (para. 168).

Part 2: New oversight role for the Intelligence Commissioner

Speaking points

• The creation of an oversight role for the Intelligence Commissioner (IC) over ministerial orders under the SAAIA is one of Bill C‑22’s most notable improvements.
• Importantly, the IC would be charged with assessing the reasonableness of the Minister of Public Safety’s conclusions in deciding to make an order, including with respect to its potential impacts on privacy protection and cybersecurity.
• Given the IC’s longstanding focus on privacy issues and compliance with s. 8 of the Charter, this new oversight function should provide meaningful protection for Canadians’ privacy interests.
• However, the inclusion of a requirement that any obligation imposed under the SAAIA – whether by order or regulation – be necessary and proportionate would help ensure that they are narrowly tailored to minimize privacy impacts and withstand judicial review if challenged.

Background

• Under a new SAAIA s. 7(2), a ministerial order imposing obligations on individual ESPs under s. 7(1) would be “valid” only if it has been approved in writing by the IC.
• Under a new s. 19.1 of the Intelligence Commissioner Act (ICA), the IC would be charged with reviewing the reasonableness of the minister’s conclusions – with respect to each of the factors set out under SAAIA s. 7(3) – on the basis of which a ministerial order was made (cl. 43).
• Pursuant to (SAAIA s. 7(3)(e), the “potential impact of the order on privacy protection and cybersecurity” is one of the factors that the minister must consider when deciding whether to make an order.
• Under a revised s. 22 of the ICA, the IC’s annual report would have to include statistics relating to ministerial orders under the SAAIA that were approved or not approved (cl. 45).
• In previous annual reports, (IC Simon Noël has repeatedly described the IC’s role as holding the government to account by ensuring that it preserves the required balance between national security interests and respect for the rule of law, the Charter, and the privacy rights of Canadians and persons in Canada.
• At SECU’s May 7 meeting on Bill C‑22, Justice Noël recommended amending s. 7(3) to specify that the decision to issue a ministerial order must be made based on the standard of “reasonableness and proportionality” so as to ensure an appropriate balancing of factors.

Part 2: Obligations to assist under the SAAIA

Speaking points

• I support the changes made to s. 14 of the SAAIA in Bill C‑22.
• Limiting who may request and receive assistance; requiring that a request be in writing and identify its purpose; and clarifying that assessment and testing must not have the effect of granting access to personal information are all meaningful improvements from Bill C‑2.
• The last change, in particular, would help ensure that s. 14 is not used as a backdoor for accessing personal information.

Background

• Under Bill C‑2, s. 14 of the SAAIA would have compelled ESPs to provide “all reasonable assistance” to permit the “assessment or testing of any device, equipment or other thing that may enable an authorized person to access information” upon a request by the Minister of Public Safety, a peace officer, or an employee of CSIS, the RCMP, or another police force.
• Under Bill C‑22, only the Minister of Public Safety would be empowered to make a request for assistance under s. 14(1), and assistance could be provided only to the above-mentioned officials.
• A new s. 14(3) would require that any such request be made in writing and set out the purpose of the assessment or testing and any related limits or conditions.
• Finally, a new s. 14(4) would provide, “[f]or greater certainty,” that the assessment or testing “must not have the effect of granting access to personal information.”

Context / background

Public Safety engagement with the OPC on Bill C‑22

Speaking points

• I met with the Minister of Public Safety in October 2025, during which I was invited to submit a letter outlining my concerns with Bill C‑2.
• Representatives from my Office were later invited to a working-level meeting at Public Safety to review proposed changes to Part 2 of Bill C‑22 (the SAAIA).
• Certain changes in Bill C‑22 are broadly consistent with some of the advice that my Office provided. However, in the final analysis, most of the recommendations were not taken up.

Background

• Bill C‑2 was tabled by the Minister of Public Safety in June 2025. The OPC was not consulted ahead of time.
• In a November 2025 letter to the Minister, the OPC proposed a series of amendments to address key issues in the bill pertaining to scope, thresholds, definitions, timelines, notification and reporting requirements, and information-sharing (among other things).
• Bill C‑22 was tabled by the Minister in March 2026. It incorporates changes consistent with some of the OPC’s recommendations on Bill C‑2, including:
  • changes to narrow the scope of the former “information demand”;
  • changes to extend the time period within which recipients of production orders under the Code can apply for review;
  • changes to require the GIC, when making regulations under the SAAIA, to consider the same factors that the Minister must consider when making orders;
  • the addition of potential impacts on privacy and cybersecurity as a factor that the GIC and the Minister must consider under the SAAIA; and
  • the introduction of an annual report requirement under the SAAIA.
• However, although the written feedback to Public Safety on proposed SAAIA amendments reiterated and expanded on several OPC recommendations, the majority of the recommendations were not implemented.
• The Department of Justice, which is the lead on the proposed amendments in Part 1 of Bill C‑22 (formerly Part 14 of Bill C‑2), did not engage with the OPC.

The case for lawful-access legislation

Speaking points

• The Government has argued that Canada is the only Five Eyes and G7 country without a lawful-access regime and that we need to “catch up” or risk falling further behind.
• I note that the Criminal Code and the CSIS Act already contain a range of lawful-access tools, including data-preservation orders, production orders, wiretap provisions, and authorities to compel companies to assist in executing such orders.
• To the extent that Canadian law enforcement and national security agencies need additional tools that are available in other jurisdictions, those tools should be suitably adapted to Canada’s legal context, which includes the rights enshrined in the Charter.
• At a minimum, this means ensuring that such tools are subject to appropriate legal thresholds, necessity and proportionality requirements, and adequate judicial oversight, where appropriate.

Background

• During second reading of Bill C‑22, the Justice Minister observed: “When I look around the world, it is clear that Canada needs to catch up. Every other G7 partner has established a lawful access regime. Each of our other Five Eyes partners has established a similar regime, and it is time for Canada to do the same.”
• During second reading of Bill C‑22, the Minister of Public Safety repeated the claim that Canada is “the only Five Eyes and G7 country not to have a formalized lawful access regime.”
• The Criminal Code contains provisions governing the intercepting of communications (Part VI); preservation demands (s. 487.012); preservation orders (s. 487.013); general production orders (s. 487.014); production orders to trace communications (s. 487.015), for transmission data (s. 487.016), tracking data (s. 487.017), and financial data (s. 487.018); and assistance orders (s. 487.02).
• Similarly, the CSIS Act contains provisions governing preservation orders (s. 20.3); production orders (s. 20.4); the intercepting of communications (s. 21); the obtaining of information, records, documents, and things (s. 22.21); and assistance orders (s. 22.3).
• It is worth noting that NSICOP’s 2025 special report on lawful access found no “clear, empirical data to substantiate claims by Canada’s security and intelligence organizations that they face serious lawful access challenges because of rapidly evolving technology.”

NSICOP special report on lawful access (September 2025)

Speaking points

• NSICOP’s special report on lawful access recognizes that the right to privacy is “fundamental to Canadian society” and that the government has an obligation to protect it when discharging its responsibility to ensure public safety and protect national security.
• As I pointed out when I appeared before NSICOP in connection with that report, privacy and security are not incompatible.
• Incorporating what NSICOP refers to as the key principles of necessity and proportionality into Bill C‑22 would help ensure that it provides government with the tools it needs to protect Canadians while also minimizing impacts on their privacy.

Background

• NSICOP launched its lawful-access review in August 2022 and provided its final report to then Prime Minister Trudeau in March 2025. A redacted version was tabled in Parliament in September 2025.
• The report’s key findings included (pp. 54, 65-66):
  • Canada’s security and intelligence organizations do not systematically track how often they encounter technological challenges in national security investigations (e.g., cases where communications content could not be accessed because of encryption);
  • There is consensus among stakeholders that legislation to compel the creation of encryption “backdoors” is “neither required nor desired”;
  • The government’s “failure” to implement a solution to the Supreme Court’s decision in Spencer is impeding responses to national security threats;
  • Without a general legal requirement for communications service providers (CSPs) to retain metadata for specified periods, there is a risk that data sought pursuant to a warrant will be unavailable; and
  • The absence of legislation requiring CSPs to maintain lawful intercept capabilities puts all stakeholders at unnecessary risk.
• The report’s key recommendations included (pp. 67-68):
  • The government should develop and implement a comprehensive strategy to address lawful access challenges that affirms “key principles, such as legitimacy, necessity, and proportionality”;
  • The government should create new legal authorities to enable the production of “basic subscriber information” and consider data-retention legislation; and
  • The government should compel CSPs to maintain intercept capabilities, but legislation should be encryption-neutral and not include a decryption requirement.

NSIRA’s recommended SAAIA amendments

Speaking points

• I understand that NSIRA has expressed concerns that, in its current form, the SAAIA does not provide a clear role for the agency.
• They have therefore recommended amendments that would require the Minister of Public Safety to notify and provide them with specified information in certain circumstances.
• I support those amendments and the underlying rationale to facilitate independent review of government actions under the SAAIA by ensuring NSIRA has the information it needs to effectively do its work.

Background

• The SAAIA currently provides that a ministerial order under s. 7(1) would be valid only if approved by the Intelligence Commissioner (IC) under s. 20(1)(a) of the Intelligence Commissioner Act. Although NSIRA would receive a copy of the IC’s decision, the Minister would not be required to provide NSIRA with a copy of any supporting documentation.
• Accordingly, NSIRA has called for:
  • A new s. 9(3) that would require the Minister, within 30 days of receiving a decision from the IC regarding an order under s. 7(1), to provide NSIRA with a copy of the order and all information that was submitted to the IC.
• Under s. 24(1) of the SAAIA, a person designated by the Minister can issue a compliance order to an ESP if there are reasonable grounds to believe that there is or is likely to be a contravention of any provision of the Act or the regulations. There is no requirement that such orders and related information be provided to NSIRA.
• Accordingly, to enable it to better assess areas of non-compliance, NSIRA has called for:
  • A new s. 27(3) that would require the Minister to notify NSIRA of compliance orders and related information within 30 days after the expiry of the period within which an ESP may request ministerial review of the order; and
  • A new s. 27(4) that would require the Minister to notify NSIRA of any decision by the Minister with respect to such a review within 30 days.
• In contrast to the SAAIA, Bill C‑8 retains requirements for the government to notify NSIRA of certain orders under the Telecommunications Act (s. 15.22) and the Critical Cyber Systems Protection Act (s. 20(5)), which SECU added to Bill C‑26 during the last Parliament (44-1).
• As NSIRA points out in their April 2026 letter to SECU, under s. 317MAB of Australia’s Telecommunications Act 1997, the Attorney-General must, within 7 days, notify the Inspector-General of Intelligence and Security of certain technical capability notices.

Privacy safeguards in previous Canadian lawful-access bills

Speaking points

• Bill C‑22’s provisions regarding access to subscriber information differ materially from those in other lawful-access bills put forward by previous governments over the past 20 years.
• Notably, unlike past bills, Bill C‑22 does not include designated-person limitations, recordkeeping obligations, use restrictions, or audit requirements.
• Together with my other recommendations on Part 1, the addition of such safeguards to Bill C‑22 could increase public trust, transparency, and accountability.

Background

• Bills C‑74 (2005), C‑47 (2009), C‑52 (2010), and C‑30 (2012), which were also put forward to facilitate access to subscriber information by law enforcement and national security agencies, each included the following safeguards:
  • Designated-person limitations: only designated employees of the RCMP, CSIS, the Commissioner of Competition, and provincial police services would have been authorized to request subscriber information (ss. 17(1) to (5) of C‑74; ss. 16(1) to (5) of C‑47, C‑52, and C‑30);
  • Recordkeeping obligations: any requester of subscriber information would have had to keep a record of the duty or function in performance of which the request was made and the relevance of the information sought (s. 17(6) of C‑74; s. 18 of C‑47, C‑52, and C‑30);
  • Use restrictions: without the consent of the individual to whom it relates, any recipient of subscriber information would have been prohibited from using it except for the purpose for which it was obtained or for a consistent use (s. 19 of C‑74, C‑47, C‑52, and C‑30);
  • Mandatory internal audits: the RCMP, CSIS, the Commissioner of Competition, and provincial police services would have had to conduct internal audits regarding the recordkeeping obligations and use restrictions (ss. 20(1) to (3) of C‑74, C‑47, C‑52, and C‑30); and
  • Audit powers for oversight bodies: the OPC and the former Security Intelligence Review Committee (now NSIRA) would have been empowered to audit compliance with the proposed recordkeeping obligations and use restrictions (ss. 20(4) to (5) of C‑74, C‑47, C‑52, and C‑30).

Bill C‑22 and section 8 of the Charter

Speaking points

• Certain powers and authorities in Bill C‑22 would allow law enforcement and other state actors to gain access to Canadians’ private information, including potentially sensitive personal information in which they have a reasonable expectation of privacy.
• Laws empowering the government to collect such information implicate the constitutionally protected right to privacy under s. 8 of the Charter.
• In such cases, it is essential to ensure that the government’s powers are narrowly tailored and subject to rigorous thresholds and appropriate oversight so that they can withstand constitutional scrutiny.
• In my view, certain powers and authorities in Bill C‑22 are subject to thresholds that are too low, rely on concepts that are too broad, and are not tempered by adequate independent oversight.

Background

• Section 8 of the Charter provides that “[e]veryone has the right to be secure against unreasonable search or seizure.” The decision in Hunter v. Southam Inc., [1984] 2 S.C.R. 145, at p. 159, established that s. 8 protects the right to privacy; including personal, territorial, and informational privacy (R. v. Tessling, 2004 SCC 67, at para. 20).
• State action that interferes with a “reasonable expectation of privacy” engages s. 8 (R. v. Wise, [1992] 1 S.C.R. 527, at p. 533). An expectation of privacy is reasonable where the public’s interest in being left alone by the state outweighs the state’s interest in intruding on the individual’s privacy to advance its goals, notably those of law enforcement (R. v. Bykovets, 2024 SCC 6, at paras. 31, 52-53).
• This is a normative assessment based on the totality of the circumstances and guided by four lines of inquiry: (1) the subject matter of the alleged search or seizure; (2) whether the claimant had a direct interest in the subject matter; (3) whether the claimant had a subjective expectation of privacy in the subject matter; and (4) whether this subjective expectation of privacy was objectively reasonable (R. v. Edwards, [1996] 1 S.C.R. 128, at para. 45; Tessling, at para. 32).
• The closer the subject matter of an alleged search lies to the “biographical core” of personal information – including, but not limited to, information that tends to reveal intimate details of the lifestyle and personal choices of the individual – the more likely there is to have been a search (R. v. Plant, [1993] 3 S.C.R. 281, at p. 293; Tessling, at para. 26; R. v. Cole, 2012 SCC 53, at para. 46).
• A warrantless search or seizure is presumptively unreasonable; to rebut that presumption, the state must show that the search was nevertheless reasonable because (1) it was authorized by law; (2) the law itself is reasonable; and (3) the manner in which it was carried out is reasonable (Hunter, at p. 161; R. v. Collins, [1987] 1 S.C.R. 265, at para. 23).

R. v. Spencer (2014)

Speaking points

• The Supreme Court’s decision in Spencer established that subscriber information associated with an IP address attracts a reasonable expectation of privacy, and that a request by the state for such information therefore constitutes a search under s. 8 of the Charter.
• Bill C‑22’s proposed production order for subscriber information thus aligns with Spencer in that judicial pre-authorization would be required.
• However, the Bill’s proposed definition of “subscriber information” is significantly broader than the information at issue in Spencer.
• Taking into account the breadth of that definition, and the similarly broad range of service providers that would be subject to the production order, a court could potentially find that Bill C‑22’s proposed threshold of reasonable suspicion may not be adequate in all cases.

Background

• In R. v. Spencer, 2014 SCC 43, the Court held that a reasonable expectation of privacy attaches to subscriber information associated with an IP address and, therefore, that a request by the state for that information constitutes a “search” under s. 8 of the Charter (paras. 5-6, 66; R. v. Bykovets, 2024 SCC 6, at para. 2).
• The Court stressed that the disclosure of subscriber information relating to an IP address “will often amount to the identification [i.e., linking] of a user with intimate or sensitive activities being carried out online” (para. 66).
• The subscriber information at issue in Spencer consisted of the “name, address, telephone number, account number, and current billing particulars” of an individual associated with an IP address identified by the police (R. v. Spencer, 2011 SKCA 144, at para. 8).
• By contrast, Bill C‑22 would define “subscriber information” as (cl. 4(2), Code, s. 487.011):
  1. information that may be used to identify the subscriber, including their name, pseudonym, address, telephone number and email address;
  2. identifiers assigned to the subscriber by the provider (e.g., account numbers); and
  3. information relating to the services provided to the subscriber, including (i) the types of services provided, (ii) the period during which the services were provided, and (iii) information that identifies the devices, equipment or things used by the subscriber in relation to the services.
• Moreover, under Bill C‑22, a production order for such information could be served on any “person who provides services to the public” (cl. 6, Code, s. 487.0142).

R. v. Bykovets (2024)

Speaking points

• In Bykovets, the Supreme Court held that an IP address attracts a reasonable expectation of privacy, and that a request by the state to obtain one therefore constitutes a search under s. 8 of the Charter.
• For that reason, the Court ruled that police require judicial pre-authorization to request an IP address.
• Bill C‑22’s proposed production order for subscriber information (which would include IP addresses) thus aligns with Bykovets in that judicial pre-authorization would be required.
• However, to date, the Court has not ruled directly on whether reasonable suspicion – the threshold proposed in Bill C‑22 – would be adequate to obtain access to subscriber information.
• Given Bill C‑22’s definition of subscriber information, which goes well beyond IP addresses, as well as the broad range of persons that could be compelled to produce it, a court could rule that reasonable suspicion is inadequate in some cases.

Background

• In R. v. Bykovets, 2024 SCC 6, the Court held, in a narrow (5-4) majority decision, that a reasonable expectation of privacy attaches to an internet protocol (IP) address and, accordingly, that a request by the state for an IP address constitutes a “search” under s. 8 of the Charter (para. 14).
• IP addresses identify internet-connected activity and enable the transfer of information from one source to another. They are unique identifiers that are necessary to access the internet and that are assigned to every device that is connected to it.
• The Court likened IP addresses to a “digital breadcrumb” capable of revealing the “trail of an Internet user’s journey through cyberspace” (paras. 9, 13, 69, 91). The Court reasoned that, because an IP address “may betray deeply personal information, even before police try to link the address to [a] user’s identity,” “access to IP addresses without judicial pre-authorization poses intense privacy risks” (para. 60).
• On this basis, the Court held that police are required to obtain prior judicial authorization before seeking or obtaining an IP address (paras. 85, 87). As Justice Karakatsanis wrote for the majority: “Judicial oversight in respect of an IP address is the way to accomplish s. 8’s goal of preventing infringements on privacy” (para. 88).
• In obiter commentary explaining why requiring police to obtain judicial authorization would not be an “onerous investigative step,” the Court pointed to s. 487.015(1) of the Code, which sets out a production order for transmission data concerning a specified communication, based on reasonable suspicion (para. 85).

International comparators (SAAIA)

Speaking points

• Elements of the SAAIA are inspired by laws in other jurisdictions, some of which include privacy-protective safeguards that the SAAIA lacks.
• When the Government imports tools from other legal systems and traditions, they must be adapted to our own particular legal context, which includes the rights enshrined in the Charter.
• In particular, any such tools must respect the fundamental right to privacy protected under s. 8 of the Charter.
• This means that they should be subject to adequate legal thresholds, necessity and proportionality requirements, and judicial oversight, where appropriate.

Background

• The Government has acknowledged that elements of the SAAIA were inspired by comparable legislation in the UK and Australia, including the concept and definition of “systemic vulnerability,” which draws from similar provisions of Australia’s Telecommunications Act 1997 (ss. 317B, 317ZG).
• However, unlike technical capability notices (TCNs) under the UK’s Investigatory Powers Act 2016 (s. 253(1)) and Australia’s Telecommunications Act 1997 (ss. 317V, 317ZAA), the SAAIA would not expressly require that obligations imposed on ESPs be necessary and proportionate.
• The UK (Investigatory Powers Act 2016, ss. 255(5A)-(5B)) and Australia (Telecommunications Act 1997, s. 317TA) prescribe maximum periods during which TCNa may remain in effect; the SAAIA would impose no such limits on the duration of regulations or orders.
• Processes exist in both the UK (Investigatory Powers Act 2016, s. 257) and Australia (Telecommunications Act 1997, s. 317WA) whereby the recipient (or intended recipient) of a TCN may formally challenge it at an early stage, with input from technical experts; the SAAIA would provide no comparable recourse.
• Australia’s law requires prompt (within 7 days) notification to review bodies following the issuance of a TCN (Telecommunications Act 1997, s. 317TAB); the SAAIA would require only that the Minister of Public Safety provide NSIRA and NSICOP with an unredacted annual report after the end of each calendar year (s. 49).
• The US Communications Assistance for Law Enforcement Act (CALEA) – which expressly excludes “electronic messaging services” from its scope – does not permit the government, when imposing intercept capabilities, to require a telecoms carrier to adopt “any specific design” for its equipment, facilities, services, etc., or to prohibit the adoption of any equipment, service, feature, etc. by a telecoms service provider or equipment manufacturer (ss. 103(b)(1), (b)(2)(A)). It also prohibits the government from compelling telecoms carriers to decrypt, or to ensure the government can decrypt, end-to-end-encrypted communications (s. 103(b)(3)).

Australian definition of “systemic vulnerability”

Speaking points

• The SAAIA’s definition of “systemic vulnerability” draws on a similar, but considerably more technical and detailed, definition in Australia’s Telecommunications Act 1997.
• In contrast to the Australian approach, the SAAIA’s definition does not explicitly include actions that would “render systemic methods of authentication or encryption less effective.”
• Expanding the SAAIA’s definition in this way could help alleviate concerns regarding the possibility of encryption backdoors.

Background

• Section 317ZG of Australia’s Telecommunications Act 1997 provides that a technical capability notice “has no effect” to the extent that it requests or requires a recipient to implement or build, or prevents them from rectifying, a “systemic vulnerability” in a form of “electronic protection.”
• “Systemic vulnerability” is defined to mean a vulnerability that affects a “whole class of technology” (s. 317B).
• However, it does not include a vulnerability that is selectively introduced to one or more target technologies connected with a particular person, unless that action involves an act or thing that will, or is likely to, jeopardize the security of information held by any other person (ss. 317B, 317ZG(4B) and (4C)).
• It is this latter aspect of the Australian definition – i.e., a material risk that otherwise secure information can be accessed by an unauthorized third party – that forms the basis of the SAAIA’s proposed definition.
• The notion of implementing or building a systemic vulnerability into a form of electronic protection in s. 317ZG of the Australian law expressly includes:
  • implementing or building a new decryption capability in relation to a form of electronic protection (s. 317ZG(2)); and
  • any action that would render systemic methods of authentication or encryption less effective (s. 317ZG(3)).
• On the one hand, Australia’s definition has been criticized as confusing, imprecise, and overly complex. However, others have said that it “appears to succeed in preventing agencies from mandating [that] providers implement encryption backdoors and wholesale cybersecurity weaknesses [in]to their products.” (Peter Davis, “Decrypting Australia’s ‘Anti-Encryption’ legislation: The meaning and effect of the ‘systemic weakness’ limitation” (2022) 44 Comp. L. & Sec. Rev.

Technical capability notices: Australia

Speaking points

• Australia has adopted analogous legislation to the SAAIA (the Telecommunications Act 1997) that empowers the government to impose lawful-access capabilities on telecommunication service providers, device manufacturers, software developers, and other entities via “technical capability notices” (TCNa).
• However, in contrast to the regulation- and order-making powers under the SAAIA, Australia’s law requires that TCNa be “reasonable and proportionate,” expire after 12 months, and be promptly reported to review bodies.
• Incorporating similar requirements into the SAAIA would ensure greater protection for Canadians’ privacy interests and promote public trust and accountability.

Background

• Australia’s Telecommunications Act 1997 empowers the Attorney-General (AG) to issue “technical capability notices” (TCNa) compelling telecommunications service providers, device manufacturers, software developers, etc., to implement new capabilities to facilitate lawful access to communications, data, and devices (s. 317T).
• The AG may issue a TCN only with the approval of the Minister for Communications (s. 317TAAA) and after consulting the intended recipient (s. 317W).
• The AG must be satisfied that a TCN is “reasonable and proportionate” and that compliance with it is “practicable” and “technically feasible” (s. 317V).
• When considering whether a TCN is “reasonable and proportionate,” the AG must consider, among other things, “whether the requirements it imposes are necessary” and the “legitimate expectations of the Australian community relating to privacy and cybersecurity” (s. 317ZAA).
• All TCNa must relate either to serious offences under Australian or foreign criminal law or to the safeguarding of national security (s. 317T(3)).
• A TCN may remain in effect for no longer than 12 months (s. 317TA).
• Generally, the existence of a TCN, and its contents, must be kept secret (s. 317ZF). However, after issuing a TCN, the AG must promptly notify the Inspector-General of Intelligence and Security or the Commonwealth Ombudsman (s. 317TAB).
• The Home Affairs Minister must report annually to Parliament on the TCNa issued during the year (s. 317ZS).

Challenging technical capability notices: Australia

Speaking points

• The Australian equivalent to the SAAIA incorporates several privacy-protective features that the SAAIA lacks.
• This includes a process whereby the prospective recipient of a “technical capability notice” may trigger an arm’s-length assessment as to whether the notice should be issued, and whether the required capability would comply with the Act’s safeguard requirements.
• Adding an analogous mechanism to the SAAIA could help address disagreements about whether a certain capability would create a risk that meets the SAAIA’s definition of “systemic vulnerability.”
• An upfront review process could be faster and less expensive than initiating a formal judicial proceeding after the fact.

Background

• Under Australia’s Telecommunications Act 1997, before a technical capability notice (TCN) can be issued, the Attorney-General must give the intended recipient a written “consultation notice” inviting it to make submissions (s. 317W).
• Similarly, s. 8 of the SAAIA would require the Minister of Public Safety to consult affected ESPs before an order is made. However, in Australia, the recipient of a consultation notice may request an “assessment” of “whether the proposed [TCN] should be given” (s. 317WA(1)).
• Upon receiving such a request, the Attorney-General must appoint two assessors:
  • a person with security clearance and sufficient knowledge to assess whether the proposed TCN would contravene s. 317ZG (i.e., the Act’s “systemic vulnerability” provision) (s. 317WA(4)); and
  • a retired judge with at least five years of experience (s. 317WA(5)).
• The assessors must then consider not only whether the proposed TCN would contravene s. 317ZG, but also whether it is “reasonable and proportionate,” “practicable,” “technically feasible,” and “the least intrusive measure” available (s. 317WA(7)).
• The assessors’ report must be shared with the intended TCN-recipient, the Attorney-General, and the Inspector-General of Intelligence and Security or the Commonwealth Ombudsman, depending on the circumstances (s. 317WA(6)).
• In deciding whether to proceed with the TCN, the Attorney-General must “have regard to” the assessors’ report but is not strictly bound by it (s. 317WA(11)).

Technical capability notices: United Kingdom

Speaking points

• The UK has adopted analogous legislation to the SAAIA (the Investigatory Powers Act 2016) that empowers the government to impose lawful-access capabilities on telecommunications operators via “technical capability notices” (TCNa).
• However, in contrast to the regulation- and order-making powers in the SAAIA, the UK law requires that TCNa be “necessary” and “proportionate” and provides that they expire by default after two years.
• Incorporating similar requirements into the SAAIA would ensure greater protection for Canadians’ privacy interests and promote public trust.

Background

• Under s. 253 of the UK’s Investigatory Powers Act 2016, the Home Secretary may issue TCNa compelling telecommunications operators to provide and maintain any of the capabilities specified in the Investigatory Powers (Technical Capability) Regulations 2018. These include, among other things, intercept capabilities, capabilities to disclose data in an intelligible form where reasonably practicable, and capabilities to remove electronic protections applied by or on behalf of the operator where reasonably practicable.
• “Telecommunications operator” is defined in the Act to include a person who provides a telecommunications service to persons in the UK or who controls or provides a telecommunication system which is in the UK, controlled from the UK, or is used by another person to provide a telecommunications service to persons in the UK (s. 261(10)).
• To issue a TCN, the Home Secretary must conclude that it is “necessary” and “proportionate” and obtain the approval of a judicial commissioner (a current or former judge) (ss. 227-228, 253(1)).
• The judicial commissioner must review the Secretary’s conclusions regarding necessity and proportionality (s. 254(1)). If the judicial commissioner refuses to approve, the Secretary may ask the Investigatory Powers Commissioner to approve instead (s. 254(5)).
• Before issuing a TCN, the Secretary must consult the intended recipient and consider several factors, including its likely benefits and the technical feasibility and cost of complying with it (ss. 255(2)-(3)).
• Unless varied or renewed (which in some cases requires a judicial commissioner’s approval), a TCN ceases to have effect after two years (ss. 255(5A)-(5B), 256A). In the interim, the Secretary must keep the TCN “under review” to ensure that it remains necessary and proportionate (s. 256(2)).
• The recipient of a TCN must not disclose its existence or contents without the Secretary’s permission (s. 255(8)).

Challenging technical capability notices: United Kingdom

Speaking points

• The UK equivalent to the SAAIA (the Investigatory Powers Act 2016) sets out a process whereby the recipient of a “technical capability notice” may refer it back to the UK Home Secretary for review.
• By contrast, the SAAIA lacks any comparable mechanism for an ESP to formally challenge an obligation outside of judicial review.
• Adding an analogous mechanism to the SAAIA could help address disagreements about whether a certain capability would create a risk that meets the Act’s definition of “systemic vulnerability.”
• An upfront review process could be faster and less expensive than initiating a formal judicial proceeding after the fact.

Background

• Under the UK’s Investigatory Powers Act 2016, the recipient of a technical capability notice (TCN) may refer it, or any part of it, back to the Home Secretary for review (ss. 257(1)-(2)). The recipient is not required to comply while the review is pending (s. 257(3)).
• Before “deciding the review,” the Secretary must consult a Technical Advisory Board and a “judicial commissioner,” i.e., a current or former judge (ss. 227-228, 257(5)).
  • The advisory board must comprise a balance of representatives of law enforcement and intelligence agencies and representatives of persons that could receive a TCN (s. 245).
  • The board must consider the TCN’s “technical requirements” and “financial consequences” for the recipient (s. 257(6)), while the judicial commissioner must consider whether the TCN is “proportionate” (s. 257(7)).
  • The board and the judicial commissioner must then report their conclusions to both the recipient of the TCN and the Secretary (s. 257(8)).
• The Secretary must consider those conclusions in determining whether to revoke the TCN or to vary or confirm its effect. The latter two options require approval from the Investigatory Powers Commissioner, who must in turn review the Secretary’s conclusions with respect to the TCN’s necessity and proportionality (ss. 257(9)-(10), 258(2)).
• The recipient of a TCN may subsequently file a complaint with the Investigatory Powers Tribunal regarding the issuance or varying of a TCN, or the failure to revoke a TCN (Regulation of Investigatory Powers Act 2000, ss. 65(4), (5)(czj), and (5)(czl)(iii)).
• Apple reportedly invoked this process after receiving a TCN requiring it to develop a capability to provide the UK government with access to iCloud users’ encrypted data.

UK-Apple dispute over government access to encrypted iCloud data

Speaking points

• The recent dispute between the UK and Apple over government access to iCloud users’ encrypted data illustrates the potential risks associated with the SAAIA’s definition of “systemic vulnerability.”
• The UK has reportedly issued multiple technical capability notices seeking to compel Apple to develop backdoors into iCloud users’ encrypted data.
• Rather than comply, Apple has now ceased offering its privacy-protective Advanced Data Protection (ADP) feature in the UK.
• To avoid such a scenario playing out in Canada to the detriment of Canadians’ privacy, I recommend amending the SAAIA’s definition of “systemic vulnerability” to clarify that it includes any action that would render systemic methods of authentication or encryption less effective.

Background

• On February 7, 2025, The Washington Post reported that the UK government had issued a technical capability notice (TCN) to Apple in January of that year demanding that Apple develop the capability to provide the UK government with access to all content that any Apple user worldwide had uploaded to Apple’s online iCloud storage service.
• On February 21, 2025, Apple announced that it was withdrawing Advanced Data Protection in the UK, thus removing the ability of UK users to end-to-end encrypt their backups, photos, notes, voice memos, and other iCloud data.
• That same month, US Director of National Intelligence Tulsi Gabbard described the TCN as an “egregious violation” of US citizens’ privacy. President Trump in turn likened it to “something that you hear about with China” and reportedly registered his objections with UK Prime Minister Keir Starmer.
• On March 4, 2025, the Financial Times reported that Apple had filed a complaint with the UK’s Investigatory Powers Tribunal challenging the TCN (a process set out under the UK’s Regulation of Investigatory Powers Act 2000). The existence of Apple’s complaint was confirmed on April 7, 2025, when the Tribunal released a decision rejecting the UK Home Secretary’s request to keep the case secret.
• On August 19, 2025, Tulsi Gabbard announced that the UK had withdrawn the TCN. However, on October 1, 2025, the Financial Times reported that the UK government had issued a new TCN to Apple in September 2025 demanding access to all British citizens’ encrypted iCloud data.

Salt Typhoon hack of major US telcos

Speaking points

• Salt Typhoon’s incursions into the networks of several major US telecommunications companies illustrate the danger that lawful-access capabilities may be exploited by unauthorized third parties, including state-sponsored threat actors.
• The Salt Typhoon hack, which reportedly targeted systems designed to provide US law enforcement and intelligence agencies court-approved access to communications, apparently allowed the attackers to access the telephone calls, text messages, and call records of millions of Americans.
• Requirements for Canadian electronic service providers to implement similar lawful-access capabilities, and to retain potentially vast quantities of sensitive metadata, could leave them vulnerable to precisely such attacks.
• It is therefore essential that any obligations imposed under the SAAIA be required to meet the standard of necessity and proportionality.

Background

• In early October 2024, media outlets reported that Chinese state-sponsored hackers known as Salt Typhoon had infiltrated US telecommunications and internet service companies, including AT&T and Verizon.
• Public reporting suggests that the hackers targeted systems installed and maintained on the direction of law enforcement and intelligence agencies to enable court-approved access to communications and metadata under the Communications Assistance for Law Enforcement Act (better known as CALEA).
• The hackers were reportedly able to listen in on telephone conversations, read unencrypted text messages, and steal customer-call data. Millions of Americans may have been impacted, including government officials and politicians.
• The Canadian Centre for Cyber Security has since acknowledged that Salt Typhoon has likely also targeted Canadian telecommunications companies and their clients.
• More generally, the Cyber Centre has warned that “hostile state actors very likely rely on access to telecommunications service providers (TSPs) and telecommunications networks around the world as a key source of foreign intelligence collection. TSPs carry telecommunications traffic and collect and store large amounts of customer data that have intelligence value, including communication, location, and device data.”

Data-retention obligations in EU jurisprudence

Speaking points

• European courts have repeatedly ruled against data-retention laws on privacy grounds in recent years.
• However, they have also recognized that, in some cases, such laws can be compatible with privacy rights, provided that they incorporate minimum safeguards grounded in the principles of necessity and proportionality, including strict limits on the scope and duration of retention, as well as purpose limitations.
• Obligations imposed under the SAAIA – particularly those pertaining to metadata retention – should at minimum be required to meet the standards of necessity and proportionality to ensure that they respect Canadians’ privacy rights and withstand judicial scrutiny.

Background

• In Digital Rights Ireland (2014), the European Court of Justice (ECJ) declared the Data Retention Directive (2006) invalid due to its incompatibility with privacy rights guaranteed by the European Charter of Fundamental Rights (para. 71). The Directive required member states to oblige providers of electronic communications services (ECSs) to retain various categories of traffic and location data for all users for periods from six months to two years, for purposes of combatting “serious crime.”
• In subsequent rulings interpreting the EU’s ePrivacy Directive (2002) in relation to data-retention laws in Sweden, the UK, France, Ireland, and Germany, the ECJ has similarly held that laws providing for the “general and indiscriminate” retention, “systematically and continuously,” of all types of traffic and location data for all users of ECSs, are incompatible with privacy rights (see Tele2 Sverige (2016), at paras. 97, 134; La Quadrature (2020), at paras. 141-143, 168; An Garda Síochána (2022), at paras. 67, 101; SpaceNet AG (2022), at paras. 74-75, 132).
• However, in those same decisions, the ECJ has also held that laws may validly provide for: the “general and indiscriminate” retention of traffic and location data for limited periods to confront serious threats to national security; the time-limited retention of traffic and location data targeted based on “objective” criteria (e.g., a geographic area); the “general and indiscriminate” retention of IP addresses for limited periods; the “general and indiscriminate” retention of data identifying users of ECSs (without time limits); and expedited data-preservation (“quick freeze”) orders. In such cases, retention must be subject to “clear and precise rules” and “minimum safeguards,” including that retention be only for the purposes of “safeguarding national security,” “combating serious crime,” or “preventing serious threats to public security.”
• The ECJ has also stressed that state-imposed obligations to retain data interfere with privacy rights, irrespective of limits placed on the state’s subsequent access to the data (see, e.g., An Garda Síochána, at paras. 46-47; La Quadrature, at paras. 115-116). Similarly, a Canadian court could rule that metadata-retention obligations imposed under the SAAIA engage the “seizure” portion of s. 8 of the Charter, even though the government would require court authorization to access the data.

Second Additional Protocol to the Convention on Cybercrime (2AP)

Speaking points

• The second “additional protocol” to the Budapest Convention on Cybercrime has been in development since 2017, with various drafts circulated to member states and observers for comment.
• One of its goals is the creation of a regime to allow police in one country to request personal data directly from a company in another country, without needing to rely on the formal mutual legal assistance process or to obtain a court order in the company’s home country.
• However, in light of the Supreme Court of Canada’s decisions in Spencer and Bykovets, it is difficult to envision such a regime being compatible with Canadian law.
• For that reason, I am pleased to see that Bill C‑22 would require prior judicial authorization for both domestic and foreign law enforcement to access subscriber information, notwithstanding my concerns regarding how that term is defined in the bill.

Background

• Canada is one of 54 signatories to the original Budapest Convention, having signed it in 2001 and ratified it in 2015. Canada signed the 2AP in June 2023.
• Article 7 of the 2AP would require parties to the 2AP to empower law enforcement or other competent authorities in their jurisdiction to obtain subscriber information directly from a service provider in another jurisdiction.
• In a March 2024 submission to the Department of Justice regarding the 2AP, the OPC’s primary recommendation was that Canada consider opting out of Article 7 on the basis that it would likely not be compatible with Canadian law.
• The following provisions in Bill C‑22 would empower domestic and foreign law enforcement to obtain access to subscriber information with judicial authorization, based on reasonable suspicion:
  • cl. 6, Code, s. 487.0142: production order for subscriber information;
  • cl. 7, Code, s. 487.0181: requests to foreign service providers for voluntary production of transmission data or subscriber information;
  • cl. 20(1), Code, s. 492.2(5.2): obtaining subscriber information under a transmission-data-recorder warrant; and
  • cl. 29, MLACMA, s. 22.07: enforcement in Canada of foreign production orders for transmission data or subscriber information.
• The enactment of these provisions would likely facilitate Canada’s ratification of the 2AP.

US Clarifying Lawful Overseas Use of Data Act (CLOUD Act)

Speaking points

• I understand that formal negotiations between Canada and the US for an agreement under the US CLOUD Act have been ongoing since 2022, and that certain provisions in Bill C‑22 may be intended to facilitate such an agreement.
• I would encourage Canadian negotiators to bear in mind the general privacy principle that intrusive measures should be as precisely and narrowly targeted as possible and focused on the most serious and pressing problems that the government is aiming to address.
• It is also imperative that any Canada-US agreement under the CLOUD Act incorporate adequate investigative thresholds and judicial oversight.

Background

• The CLOUD Act was enacted in 2018 to facilitate US law enforcement access to digital evidence stored outside the US and to reduce delays under formal mutual legal assistance processes.
• The CLOUD Act requires US service providers to comply with orders under the Stored Communications Act to preserve, backup, or disclose the contents of a wire or electronic communication, as well as any record or other information pertaining to a customer or subscriber within their possession, custody, or control, “regardless of whether such communication, record, or other information is located within or outside” the US (s. 103(a)(1); 18 U.S.C. § 2713).
• US service providers may also produce information in response to an order from a foreign government that has entered into an agreement with the US that meets certain requirements and contains certain safeguards prescribed in the CLOUD Act, including that “the domestic law of the foreign government […] affords robust substantive and procedural protections for privacy and civil liberties” (s. 105; 18 U.S.C. § 2523(b)).
• To date, the US has entered into CLOUD Act agreements with two countries: the UK (in force since 2022) and Australia (in force since 2024).
• The Global Privacy Assembly’s 2021 resolution on “Government Access to Data, Privacy and the Rule of Law” articulates several principles applicable to government access to personal data held by the private sector for national security and public safety purposes, including the need for necessity and proportionality requirements; transparency reporting; rights of access, correction and deletion; independent oversight; and limitations on use and onward sharing.
• Bill C‑22’s provisions governing international production requests (cl. 7, Code, s. 487.0181) and the enforcement of foreign production orders in Canada (cl. 29, MLACMA, s. 22.07) could facilitate an agreement between Canada and the US under the CLOUD Act.