Stated goals of the App

What are the stated goals of the App?

Side effects of the App

Are there any others goals, not stated by the App Creators, that they are known to also accomplish with this App, or that they could also accomplish with this App in the future?

The App Creators can establish a (partial) social graph with time annotations as the full contact history of an Exposure Contact (called F1 in the white paper) is uploaded to the Cloud Components Source: [whitepaper], checked on 2020-05-19 .

Are there any other goals that others (not App Creators) could also accomplish because this App exists, or is used by certain Users?

  • Anybody can track App Users as they go about their daily lives. This is described in more detail in Contact tracing with static Contact IDs.

  • Any correlation between a Contact ID and the App User's identity unmasks the App User with respect to all activities performed during the entire time they have run before and after it occurred. This is described in more detail in Contact tracing with static Contact IDs.

  • Smart phone theft is facilitated, because the emitted beacon points thieves to the location of an smart phone (e.g. on a person, or left in a car or office).

Are there notable side effects in the use of this App?

Social context of using the App

Is usage of the App required under some circumstances? If so, by whom? What are the consequences of not using it?

Not known.

Are there non-trivial incentives (e.g. financial, access) for using the App? Are there social pressures to use the App?

Not known.

Is a minimum penetration of App usage required in some population before the App can start to be effective?

  • “The Ministry of Information and Communications and the Ministry of Health recommend that the whole country install Bluezone for themselves and for 3 others” Source: [website], checked on 2020-05-18

  • Presumably the number of concurrent App Users in a certain region must be a significant percentage of people in that area. This is true for all technical approached to contact tracing.

Are there social pressures on the App User resulting from the use of the App, or from information shown by the App? (E.g. if the App indicates that the App User has likely been infected.)

The App website states: “According to the rule (App Assay interpretation: government policy), a person who has been identified as infected with COVID-19 will be put in quarantine and get treatment, so there is no way you can accidentally “get close” to such a person and Bluezone does not have this feature as well.” Source: [website], checked on 2020-05-18 . This implies that users who are known to be infected will be put into mandatory quarantine. (This itself is not a consequence of the App, but of government policy.) It is unknown whether contacts of known infected people, as identified by this App, will also be subject to this policy; if it is, it would be a direct consequence of using the App. Note other consequences of technical Contact Tracing. Source: [technical-analysis], checked on 2020-05-18

Are there social pressures on anybody resulting from information shown by the App run by another App User? (e.g. pressures on an App User's family or friends if the App identifies the App User as likely infected)

Not known.

Is the App available in all languages and localizations most appropriate for the intended App User population?

Available in Vietnamese and English, which are the primary languages for the intended region. Source: [technical-analysis], checked on 2020-05-18


Describe the principle of operation

Usage metrics

How many App Users are currently using the App?

~193,000 users (unclear whether installs or active). Source: [api-invocation], checked on 2020-05-18

Effectiveness metrics against the disease

Not known.


How are new App Users onboarded on the App? What information do they need to provide to be able to use the App?

Vietnamese mobile phone number is strongly requested but not required. Source: [technical-analysis], checked on 2020-05-18

How long is collected data retained, and where?

Not known.

Are any Backups being made whose retention is longer than the declared Data Retention Period? How is it guaranteed that Backups are deleted on time?

Has a Privacy Impact Assessment been performed, and if so, where can it be obtained? Which recommendations have been implemented, and which not? If no such assessment has been performed, why not?

No known privacy assessment beyond the self-assertions of the App Creators in the White Paper etc.

Is the App compliant with local regulations on privacy, in particular on privacy of health-related information?

Not known.

Is the App consistent with global best practices on privacy, in particular on privacy of health-related information?

No. The use of a permanent Contact IDs that is broadcast for as long as the App User runs the App is clearly inconsistent with best practices. For better approaches, see Contact tracing.

What assurances exist that the App will be shut down promptly when appropriate (e.g. when the pandemic has passed, or better approaches for combating the disease have been found)?

None found.

Is any data collected by the App transmitted beyond the App? If so:

  • Who is the receiver of the data?
  • What is the data that is being transmitted?
  • What are the terms under which the data is transmitted, and what are the safeguards that guarantee the terms are not being violated?
  • Can the transmitted data be correlated by the received with other data they may have or may be able to obtain?

The following data is being transmitted:

  • The App User's Contact ID’ is broadcast continually (24x7) by the App User's smartphone via Bluetooth. This broadcast is available to anybody who cares to listen, and can easily be impersonated by anybody as no provisions against Replay Attack or other Attacks seem to have been implemented. No safeguards have been implemented (nor could be implemented with the approach taken). Source: [whitepaper], checked on 2020-05-18

  • No information is available on whether or not data held by the Cloud Component is ever transmitted beyond the App. This data contains the phone number of infected App Users.

Is any data imported by the App from other sources? If so:

  • What data is being imported, and from which sources?
  • How does that increase the effectiveness of the App?
  • Does it potentially increase risks or downsides of the App, and if so, how?

No information is available on data imported on the Cloud Component. On the mobile phone, a record of all Contact IDs broadcast by other App Users is kept, as well as a record of all Bluetooth MAC Addresses found for as long as the App User runs the App.

Can identities of App Users be tied to, or can they be correlated to specific individuals, and if so, by whom?

User education, consent, support and agency

How do new App Users discover, and obtain access to the App?

If the App performs several distinct functions, can the App User opt-in to some and opt-out of others?

Not applicable: the App performs only one significant function.

How is user support handled?

How is the user experience, user understanding, and technical performance of the App being monitored in the field?

Not known.

Can App Users request a copy of the data that has been retained about them? Is the process simple and quick? Is the obtained data easy to understand, verify and use?

Can previous App Users request a permanent deletion of the data collected about them? Is the process simple and quick?

Can App Users request a correction of data about them? Is the process simple and quick?

No such process has been found. This means that if App Users pass their phone to a different person, or change phones during the pandemic, effectiveness and correctness of contact tracing may be impacted. It is unclear what would happen if an App User were to change their phone number.

Can parents or guardians act on behalf of their children in all aspects of the App?

The App makes no distinction between adult and minor users. No parental consent, or withdrawal of consent is supported.

Is there an effective complaint process by which App Users can raise issues with the App, or issues with the impact of the use of the App has on them? (not bugs, not technical issues; that is handled in the support question)

None found.

Are App Users being educated about what it means to use the App, and give their informed consent prior to using the App?

Partially. No information is provided on the actual effectiveness of the App, nor on risks for abuse.

Can the App User deactivate and delete the App?
If the source code is available, under which license is it available?


Are the user-facing components of the App built in a way that minimizes potential user mistakes that could be detrimental towards effectiveness or avoidance of risks and harms for themselves and others?

The user interface appears straightforward and understandable.

Is the App accessible?

Default OS features for accessibility.

Managed or processed data

What data does the App handle? Where in the Architecture is which data stored or processed? Is all data handled by the App strictly required for the stated goals?

Federation with other Apps

Is the App a standalone system (“stovepipe”) or is it intended to be used in Federation with other Apps created by others? If so, what are the supported Federation technologies (e.g. protocols/standards), operations and governance?

Not intended to be used in a federation.

Service Providers used with the App

What third-party Service Providers are used for the App?

Are all Service Providers under legal obligations consistent with the needs of the App? This may particularly be an issue if a Service Provider is subject to a different jurisdiction than the App Creators or App Users, or if the Service Provider can be legally compelled in their jurisdiction to break their obligations to stakeholders of the App.

Not known.


What are the key non-standard communication protocols the App uses? Explain. (These are highly dependent on the App's features.)

  • “For the role of a broadcasting device, we generate a random Bluezone ID (BLID) (App Assay note: Contact ID) for each smartphone. Each BLID has 6 characters (explained below). BLID of this broadcasting device will be recorded and stored by other dvices for the sake of later close contact identification in case F0 (App Assay note: App User) gets confirmed (App Assay note: as having been infected). The format of a broadcasted BLE packet is as follows:

    • There are 16 bytes containing UUIDs. To distinguish between Android and iOS, we use 1 UUID for Android Bluezoner and 1 UUID for iOS Bluezoner
    • We decide to integrate BLID into BLE broadcast packet to transmit BLID without connection between devices to transmit and receive BLID. This will save time (which requires very fast execution) and energy consumed for connecting the devices. While with some other solutions, they perform all such connecting operations, lead to slow contact detection and battery drain.
    • On Android devices, there are 2 ways to fill information in the remaining 15 bytes after UUID. The first is naming the device, but in practice there are some types of devices that we cannot get the desired information. So, our team decided to use the second option, which is filling in that 15 bytes with Manufacture Name. However, it takes use 3 bytes to write the Manufacture number, so there will be only 12 bytes left for BLID, enough for the transmission of 6 BLID characters.
    • On iOS, integrating BLID into the name of BLE is much easier and does not requires as many as calculations as on Android.” Source: [whitepaper], checked on 2020-05-18
  • “If the desired signal is received, BLID (App Assay note: Contact ID) will be writen (App Assay note: recorded), as so its time of recording and RSSI information. Such received signal strength indicator will help determine the relative distance between the two smartphones.” Source: [whitepaper], checked on 2020-05-18

  • “A problem occurs during the reception of signals from iOS devices: In the event that Bluezone on the broadcasting device operates in the background, other iOS devices will not be able to read the full BLID (App Assay note: Contact ID) as expected. We solve this by requiring connection between the two devices, then the broadcasting device transmits BLID through Characteristic field for the receiver to record. Source: [whitepaper], checked on 2020-05-18

  • “To increase the ability of recording close contact with devices without Bluezone, we decided to add a method for receiving Bluetooth Classic signals to record Bluetooth MAC Address of the devices. This address is a fixed value on all phones since shipped. With the MAC Address obtained, in the event that F0 (App Assay note: infected App User) does not install Bluezone beforehand, health authorities can still put this MAC Address onto the system to notify Bluezone-installed phones to check possible close contact with such F0.Source: [whitepaper], checked on 2020-05-18

  • “We recognize that BLE solutions of other groups/organizations in the world that have been implemented in reality are not complete due to insufficient contact records. Specifically, if iOS users want to keep track of their contacts, they need to let the Bluetooth Low Energy (BLE) application run in foreground to record other devices. To solve this issue, the teams recommend that users always turn on the app in the foreground, which means users must run the app and keep the screen light all the times. This is an unrealistic approach that few people can cope with. First, it wastes battery when the screen has to be constantly on. Second, users can do nothing else with their smartphone when the application is always in foreground. First of all, we have resolved this problem to make the iOS Bluezone version able to record contacts (if any) with other Android devices even when in background mode. The results are positive. Next, Android Bluezone is also designed to recognize iOS Bluezone devices while running in the background. Finally, foreground-running iOS Bluezone can recognize other background-running iOS devices (Refer to the table of contact cases in section 7.1). By using the bridging principles like this, we can trace almost all user contacts without requiring the iOS app to be always turned on in foreground mode. Source: [whitepaper], checked on 2020-05-18


How are decisions made about technology and operations of the App?

Not known.

How are decisions made about governance of the App?

Not known.

Is there a public roadmap for the App, and if so, where can it be found?

With the exception of a sparsely populated public issue tracker on Github: No.

Is there a whistleblower process for people involved in any aspect of the development, operation, or governance of the App? If not, why not?

Not known.

Should assertions by App Creators prove to be false, or their behavior to be negligent, what are the remedies available to App Users?

Not known.

Validation by third parties

Which third parties have researched the effectiveness of this App against the disease? Are their reports publicly available, and if so, where?

None known.

Which third parties have researched the potential downsides or risks of this App? Are their reports publicly available, and if so, where?

See ./sources.

Has any third-party audit been performed of the App? Who performed the audit, are their reports publicly available, and if so, where?

None known.

Are any major discrepancies known between self-assertions by the App Creators and Inference or Audits by third parties?

Are all relevant technologies, processes, governance and their internal and public documentation periodically and timely updated?

There appear to be inconsistencies between white paper, and code. No updates have been made to either for some time.


Is there an audit trail of what happens in the App? Can it be accessed by the App User or entities on their behalf?


Validation by third parties

If source code is available, where can it be found?

Other notes

Any other notes that may be of interest