CARLOS LASTRES CONTACT

Does Japan's External Transmission Rule Apply to Your Website?

Since June 16, 2023, Japan's amended Telecommunications Business Act requires some websites and apps that send user data to third parties through tags or SDKs to disclose what is sent, to whom and why. According to the Ministry of Internal Affairs and Communications, corporate websites and stores selling their own products are out of scope, while news and information sites, social networks and search are in. Where the line falls, and how to write the notice on screen.

Japan's external transmission rule, 外部送信規律, comes from a June 2022 amendment to the Telecommunications Business Act and has applied since June 16, 2023. It tends to come up halfway through a site or app review, and the first question is usually whether it covers the company at all.

The Ministry of Internal Affairs and Communications publishes an explanation page for businesses, and this article follows that page closely. I am not a lawyer. I design and build the screens where this notice ends up, and that is the angle I am writing from. If you are unsure, check the ministry's material and ask a specialist.

What the rule says

Most websites and apps include analytics tags, ad tags or SDKs that make the user's device send information to a third party. The ministry calls this external transmission.

The rule requires anyone running a telecommunications business to let users see, in advance, what information will be sent when they deliver a program that tells the user's device to transmit it. There are four ways to comply: notify the user, publish the information where users can easily find it, get consent, or offer an opt out.

When you notify or publish, you show three things:

  • what information about the user will be sent
  • the name of whoever will handle that information
  • what it will be used for

Is your website covered?

This is the question I hear most. The ministry's page says the rule mainly applies when these services are offered through a browser or an app:

  • services that relay messages
  • social networks
  • search services
  • online provision of information, such as news sites and curation sites

The same page says these are not telecommunications businesses, so the rule does not apply:

  • selling your own products online
  • running a company website or a personal blog

So a corporate site, or a store that sells only its own products, is out of scope on its own. What deserves a second look is everything else the same company runs. An owned media site publishing industry news, a community where members message each other, or an app where users can post all move toward the covered categories. The ministry provides a flowchart for whether a service counts as online provision of information, and notes that services can fall under the rule in other ways too. If you run several services, check each one separately.

What you do not have to disclose

Not every transmission counts. According to the ministry's page, you do not need to notify or publish:

  • information genuinely needed to provide the service, such as OS, display and language settings, browser information, keeping what the user typed, user authentication, security and network management
  • an identifier the service itself sent to the user and stored in a first party cookie

Analytics and advertising tags are not on that list. They are usually what the notice is about.

How to write it on screen

The ministry sets conditions for the wording that apply to both notification and publication. The text should be in Japanese, avoid technical terms, use plain expressions, and be displayed at a readable size without the user having to zoom.

If you publish, on a website the information goes on the page that sends the program or on a page easily reached from it. In an app it goes on the first screen or one easily reached from it. If you notify, you show the information itself, or a link to the screen that has it, in something like a pop up.

If you choose consent, the ministry says plainly not to use methods where the user cannot be said to have actively agreed, such as a checkbox that is ticked in advance.

From the design side, "no technical terms" and "readable without zooming" carry the most weight. A table of tag names with English descriptions buried deep in a privacy policy is hard to square with those conditions. I would write one line per recipient, saying which company receives what and why, and make that list reachable in one step from the footer and from the settings screen.

Where to start

If you are not sure whether you are covered, this order is the quickest.

First, list every service you run and check each against the categories the ministry names. Next, for the services that look covered, list the tags and SDKs that are actually installed. The contents of your tag manager and the SDK list for your apps are enough. Finally, try writing who receives what and why for each recipient, without technical terms.

The third step is where most teams get stuck, and it is often the moment someone notices that nobody knows why a particular tag is there. Removing tags you no longer use counts as compliance work too.

READ NEXT

← All insights