The Telegram ban order misses the tech-law nuance

The Delhi High Court's decision in Telegram FZ LLC v. Union of India is important not only because it concerns the temporary blocking of one of the world's largest messaging platforms in India, but also because it tests a basic question of statutory architecture under the Information Technology Act, 2000.

Section 69A is usually discussed as a censorship provision, a national security provision, or a public order provision. In this case, the more important question is narrower and more technical: what exactly does Section 69A allow the government to block?

The central argument of this piece is that technology law goes wrong when legal categories are made to absorb technical categories they were not designed to regulate.

Telegram, as an app, service, software stack, cloud-based messaging architecture, bot ecosystem, storage layer, user interface and delivery infrastructure, is not merely one piece of information or offending information. It is a computer resource, or at least a collection of computer resources, through which information is generated, transmitted, received, stored and hosted. Section 69A permits blocking public access to information through a computer resource. It does not, simpliciter, create the overarching power to block the computer resource itself.

The facts recorded by the Court make this distinction more important. The government's case arose from the alleged misuse of Telegram in connection with NEET UG 2026. The Union Ministry of Electronics and Information Technology (MeitY) first shared identified URLs with Telegram. The platform's case was that those URLs were taken down; after the impugned order, 900 out of 1300 URLs communicated by MeitY were disabled. The order nevertheless directed Telegram and associated URLs to be blocked across India, required Telegram to disable its message-editing feature and directed app stores and internet service providers to block or disable access to Telegram.

The argument here is that the one-hour takedown point should have been the doctrinal hinge of the case. If the State identifies a channel, account, bot, post, file, message, database entry or URL which contains unlawful information and satisfies the statutory grounds, Section 69A can be used to block access to that information. The government may insist on speed, and it may invoke the emergency route under the 2009 Blocking Rules, where delay is unacceptable. But the object of the direction remains the information, not the entire technological environment in which the information once appeared.

The statutory text supports this distinction. Section 69A empowers the government, subject to reasons recorded in writing and prescribed safeguards, to direct blocking of any information generated, transmitted, received, stored or hosted in any computer resource. Section 2(1)(v) separately defines ‘information’ broadly to include data, messages, text, images, sound, voice, codes, computer programmes, software and databases, while Section 2(1)(k) defines ‘computer resource’ to mean a computer, computer system, computer network, data, computer database or software. These definitions overlap, but they are not meaningless. The computer resource is the environment through which information exists or travels. The information is the regulatory object. Collapsing the two categories rewrites the structure of the provision.

Much has been argued about Telegram's infrastructure in this case, but with utmost respect, most of that argument has treated infrastructure as a set of product features rather than as a technical architecture. The Union's submissions referred to Telegram's cloud-based infrastructure, large public channels, automated bot ecosystems, concealment of identifiers, large-volume file sharing, self-destructing messages, message editing, backup channels, rotated handles, burner accounts and mirror channels. Those facts may be relevant to public order, exam integrity, platform responsibility, due diligence, or the design of a future regulatory power. But the more the case depends on infrastructure, architecture and product features, the more obvious it becomes that the case has moved beyond ‘information’ blocking.

Telegram's own documentation is more useful. It describes the platform as a cloud-based messenger with seamless sync across phones, tablets and computers; a service supported by multi-data-centre infrastructure; an open platform with APIs and code through which developers can build Telegram apps; and a system that includes mobile clients, desktop clients, web access, bots, channels, groups, cloud chats, server-side storage, local storage, encryption, network implementation and developer-facing libraries. This is not the description of one item of the Section 2(1)(v) ‘information’. It is rather the description of a ‘computer-resource’ environment: software, databases, computer networks, client applications, server APIs, protocols and storage systems through which information is made available, moved and acted upon.

The point becomes clearer when Telegram's documentation is read against Section 69A's own verbs. Telegram's MTProto documentation says that the protocol is designed for access to a server API from applications running on mobile devices; that API queries and responses are converted into binary messages; that messages are encrypted before being transmitted; and that the client and server exchange messages inside sessions attached to the client application. The Bot API separately describes bots as interfaces for code running on a server, with requests served over HTTPS, incoming updates stored on the server until retrieved and updates including messages, edited messages, channel posts, reactions and webhook calls. TDLib is described as handling network implementation, encryption and local data storage for Telegram clients.

In other words, information on Telegram is generated by users, bots and clients; transmitted through MTProto, HTTPS and other transport protocols; received through clients, APIs, updates and webhooks; stored in cloud chats, local databases and server-side systems; and hosted through Telegram's distributed infrastructure. Telegram is the resource environment in which those verbs operate, not the information to which those verbs attach.

The High Court answered this question by relying on the breadth of the definition of ‘information’. It held that ‘information’ should not be confined to individual accounts, channels, posts, files or messages; that an application or platform, in its ordinary sense, is a computer programme or software; and that because codes, computer programmes and software fall within the definition of ‘information’, there is no reason to exclude an application or platform from the expression. I would like to argue that the problem is not that the definition of ‘information’ is narrow. The problem is that breadth is being used to erase statutory structure to extend ‘information’ to a ‘computer resource’, which the legislature clearly distinguishes.

A better reading is available. Section 69A can reach information in different technical forms, including code, files, messages, databases, links, posts, accounts, channels and bot outputs, provided the statutory grounds and procedural safeguards are satisfied. Section 69A clearly identifies that ‘information’ is present in a ‘computer resource’. Such a wide reading is technologically neutral without becoming technologically unlimited. It ensures that the government is not defeated merely because unlawful information appears in a dynamic digital form. But it still respects the distinction between the ‘information’ to be blocked and the ‘computer resource’ through which the information is generated, transmitted, received, stored or hosted.

That reading is also consistent with the structure of the Blocking Rules. The Rules speak of blocking information or part thereof, sample content of the alleged offending information, the computer resource on which such information is hosted and directions to block the offending information generated, transmitted, received, stored or hosted in a computer resource. They assume that the decision-maker can identify the offending information and the resource hosting it. They do not read like a general product-regulation code for disabling platform capabilities.

Shreya Singhal reinforces the same discipline. The Supreme Court upheld Section 69A and the 2009 Blocking Rules because the provision was narrowly drawn, reasoned and accompanied by safeguards. Junglee Games is useful too, in another reason. It shows that Indian law does not lack the vocabulary to regulate an app, virtual platform, software layer, cyberspace or computer resource when that is the legislative object. Section 69A uses a different vocabulary – which has to be understood to be the legislature’s intent. The better view is not that Telegram becomes information merely because it is made of code, software and databases; it is that Telegram is the computer-resource environment through which information moves, and Section 69A cannot block that environment by relabelling it as the information itself.

The same system-content distinction appears, cautiously, in comparative technology law. In Google LLC v. Oracle America, Inc, the US Supreme Court described a software platform as infrastructure that enables programmers to develop programs and applications, and treated APIs as functional interfaces within a computing environment. In Van Buren v. United States, the Court distinguished access to a computer system from obtaining information located in particular files, folders or databases. EU platform-liability law similarly treats platforms and hosting services as the environment, while the legally actionable object remains specific information or user-uploaded content. None of this decides Section 69A, but it confirms the tech-law understanding that the platform is the environment and information is the object moving through it.

I must confess there could be a fair counterargument. Digital platforms are not static containers. A channel, bot, account, database entry, software module and application interface may operate together to produce harm, and in a fast-moving public order situation, targeted blocking may allow a harmful network to regenerate faster than the State can respond. The facts recorded by the Court - including mirror channels, burner accounts, bots and message editing - make this concern real.

But acknowledging the concern does not answer the statutory question nor does it redraft the law. If parliament wants a platform-risk power that allows temporary disabling of an app, restriction of a product feature, or emergency architecture-level directions, it can legislate for that power with appropriate thresholds, duration limits, notice rules, evidence standards, review, transparency and remedies. That would be a serious policy choice, one that lies squarely within legislative prerogative. What should not happen is the quiet conversion of an information-blocking provision into an infrastructure-blocking provision through interpretation.

The answer is not to deny the State's responsibility to respond to fraud, exam manipulation, child sexual abuse material, cybercrime or public order threats. The answer is to keep legal powers matched to the technical object they regulate. Information blocking should block information. Intermediary due diligence should regulate intermediary conduct. Cybersecurity powers should address security incidents and protected systems. If India needs an emergency platform-risk regime, it should be designed as such, not reinvented inside Section 69A by treating computer resources as indistinguishable from the information flowing through them. The distinction may look technical, but in technology law, technical distinctions are often where the rule of law actually resides.

Kaustubh Shakkarwar is the Global DPO and Founder of Data>Nuance Consulting.