CC-BY International to be adopted ready for potential LFPH adoption.

From https://github.com/vmware/herald/blame/6fe526d2b20b9d3dad5515daf7ae3f9a3d2473bd/background/index.md#L143-L145

This mentions a downside of a decentralised approach being that only first-order contacts can be notified.

This issue impacts all systems that do not have a way to check logs of all participants in the system at all times, and has nothing to do with a decentralised approach. However, "fixing this" tends to fall afoul of privacy expectations in most democratic countries, which will also impact the adoption of any app.

From https://github.com/vmware/herald/blame/6fe526d2b20b9d3dad5515daf7ae3f9a3d2473bd/background/index.md#L150-L155

This references a Forbes article which reports on a paper describing attacks on ENF-based contact tracing apps being a threat to US elections.

This is played down in the article by Ron Rivest:

MIT professor Ron Rivest helped lay the foundation for what later became GAEN with a class he taught on Apple’s Find My Phone feature. Rivest, who helped invent the public-key cryptography used in bitcoin and more in 1977, downplays the threat, saying a simple campaign on Facebook or Twitter would be a much easier and cheaper way to achieve the same voter suppression. “If you have the desire to affect voter turnout, you can suggest to people that the poll sites might be contaminated, might be havens of disease,” he says. “Social medias of various sorts would be the way to do it today.”

Looking at information about its citation and status, it appears it has not been accepted into any journal, or gone through peer review. I was only able to find one other paper that cites it, which describes a block-chain based black market that would allow COVID-19 positive patients to sell their upload tokens.

The circumstances described both papers do not appear to be a problem that is unique to any decentralised contact tracing system, but rather an attack on Bluetooth based contact tracing systems in general. It would be possible to attack any protocol, even a centralised one, through either leaking upload tokens given to COVID-19-positive individuals, or by replaying or proxying the various Bluetooth protocols that they use between venues.

From https://github.com/vmware/herald/blame/6fe526d2b20b9d3dad5515daf7ae3f9a3d2473bd/background/index.md#L156-L164

This says that a decentralised protocol cannot operate across international borders, specifically citing travellers between Ulster and the Republic.

Both Northern Island and the Republic of Ireland agencies already share this data across borders with their ENF based system: https://www.bbc.com/news/uk-northern-ireland-52736896

As a counter-point, the Australian government has adopted a centralised protocol originally based on Singapore's system (which had support for international interoperability after server federation). However, this is not possible for Australian app users, as the protocol has been modified by the Australian authorities in incompatible ways.

There is nothing to stop any agency from sharing data in an in a decentralised data model, so it should not be listed as a "disadvantage". If anything, whether two countries or regions use the same system is more important than whether it is centralised or not.

People in UK with smartphones, those with BLE 4.0+, those with advertising, those with up to date OS -> total amount

Java and iOS, multiple versions shown (previous major versions, current beta version)

[Who] As a Herald contributor
[What] I need accurate and relevant information in order to reproduce (and fix) bugs, and understand feature requests
[Value] So I can quickly fix bugs and add functionality

• Android
• iOS
• C++
• Analysis
• Website
• Calibration
• Hardware

Guide currently assumes a copy/paste of code. Change this to only documenting using it as a library.

The 'open issues' link is broken on the homepage.

https://vmware.github.io/herald/ -> https://vmware.github.io/herald/issues

As Herald is a connectable peripheral, the default GAP service will be available to any client. This includes the "Device Name" characteristic, which is a user-configurable value (e.g. "Jim's Pixel 2").

This makes the device trackable, as it exposes a value that is likely to be relatively unique.

It's very difficult to suggest an effective mitigation for this. See this blog post for more information https://github.com/vteague/contactTracing/blob/master/blog/2020-06-22OutstandingPrivacyIssues.md#unique-phone-names-eg-names-iphone

As this is a well known issue, I'm not raising it as a security vulnerability (although it really is). However, it's very important that anyone implementing Herald should definitely be made aware of this, so it would be good to add to the documentation.

COVIDSafe has a workaround for this (only on Android) but I do not think it is particularly effective as the message is confusing, and requiring the user to rename their phone has an unfortunate usability cost for other Bluetooth scenarios.

I am less familiar with the iPhone, but although iOS hides this value (always reporting "iPhone"), I think while investigating CVE-2020-12856 I saw that the hiding is disabled while the pairing prompt is being shown to the user. (So an attacker can initiate pairing and quickly read the value). Of course on iPhone, it's worth being aware of Bleee https://hexway.io/research/apple-bleee/

For LFPH adoption, ideally we need to move to Apache 2.0 instead of MIT license.

Can all code contributors please reply to this issue with the phrase "I consent to allowing all my contributions to move from the MIT to Apache 2.0 license"? (Or that you don't consent, of course).

Once agreed we'll look to double check that no code used was from a non-Apache 2.0 source, or replace where there is a need.

[Who] As a standards body or academic writer
[What] I need to provide a permalink to sections that are consistent over time
[Value] In order to maintain a valid deep-link to content I wish to cite

E.g. via a jekyll plugin like: https://github.com/allejo/jekyll-anchor-headings

Note: MUST be accessible, not mess up screen readers, and not require JavaScript

This should be done as a one off AND built in to CI/CD. Build should FAIL and NOT PUBLISH if it fails accessibility checks.

This is a call to existing significant contributors to volunteer for the role of Project Committer in The Herald Project. This requires a vote of the existing committers, date provisionally set as Friday 2nd July 2021. If you wish to be considered as a committer then please add a comment to this issue, ideally with a brief introduction on your experience for the post.

Committers are project members with special privileges to merge Pull Requests, respond to bug reports and feature requests, and engage in meetings with adopters. It's an important role, and ensures The Herald Project is well governed. Committers also get to vote for the project's Technical Steering Committer (TSC) Chair once a year (our next vote on that is early 2022). Only committers are eligible for the TSC Chair position.

Please ensure your name with a note asking to be considered is in a comment to this issue before 12:00 (midday) UK time (+0100) on Friday 2nd July. Voting shall then commence via this comment process. Current committers that can vote are @adamfowleruk and @RobbieJVMW . Voting deadline is Friday 9th July at 12:00 (midday) UK time (+0100).

E.g. theheraldproject/herald-for-android@v1.3.0...v2.0.0
Useful for a full bugfix list

• Include advantages over QR code manual check-in
• Ensure it is obvious that this can be used independently of the phone-to-phone protocol in use (i.e. Herald Beacon detection can live side by side with GAEN/Robert/other protocol on a GAEN/Robert/other powered app)

Keep the payload info pages simple, but create a specifications area on the website for formal documentation.

Hi,

Could you please provide instructions on reporting security/privacy issues in Herald? I don't see any guidelines in the GitHub repos (e.g. security.txt) or anything at https://vmware.github.io/herald/

Ideally a BugCrowd or HackerOne, and a disclosure procedure - see https://disclose.io/ for reference.

In the meantime is the VMWare security contact described here the correct address to use?
https://hackerone.com/vmware?type=team It's not clear exactly the relationship between Herald ("a VMWare-backed project") and the rest of VMWare i.e. "a VMWare product".

Thanks!

Please refer to this issue raised against COVIDSafe's proposed Herald integration.

https://github.com/AU-COVIDSafe/mobile-android/issues/31

There are some technical inaccuracies that should be corrected, but also it is important that current (and future) implementors of Herald understand what is and isn't realistic.

NEW content that people have requested. All basic, so just opening one issue for it.

• 'Support' page (under Reference) lists support statement and hardware/versions
• 'System requirements' (either separately, or with, the support page) - RAM, chipset, last test result, release number, gotchas/known issues, link to hex/release with instructions
• Add mission statements to main page and DCT page
• Published Datasets BRIEF description page under Research
• Calibration robot page under research
• OpenABM page under research

[Who] As a Herald app creator
[What] I would like to see best practice for apps built on Herald, even if not strictly a Herald best practice
[Value] To help me implement an effective and secure app based on Herald

Acceptance criteria:-

• Best practice area/page on the website in the implementation guide section 'Bluetooth app best practices'

Initial content:-

• Mention the CVE fix for Android BLe pairing (until we have this built in ourselves) - See theheraldproject/herald-for-android#88
• Mention app auto updates - See theheraldproject/herald-for-android#89

Just leaving an issue here to remind us to clean up

[Who] As a project team
[What] We want to highlight specific areas we'd like feedback from the tech / user community on our website
[Value] To get external feedback on key and emerging issues

Current idea:-

• Add helps table to the community page on the website
• Document the helps each as a 'help wanted' issue on the relevant GitHub repository/ies
• High level 'new','in progress', and 'complete! Thanks!' statuses on the webpage
• Consistent link so people can link to the community helps page

Look through all old notes and find complete list of issues overcome so other teams can benefit

Validate existing Jekyll action

As of Friday 26 February 2021 the Herald project was officially signed over to LFPH, and the Herald Project Charter was adopted. As per this charter the current committers may elect a TSC Chair for the Herald project for a period of 1 year. Only the current project committers (not contributors) are eligible to vote. These are currently:-

• Adam Fowler - @adamfowleruk
• Robbie Jerrom - @RobbieJVMW

The vote shall be carried out in the following stages:-

1. Those committers above can choose to submit themselves (or rule themselves out) of consideration for the TSC Chair position.
2. Once 1 week has passed (Mon 8th March 11:00 GMT) or all committers have responded I shall place a comment on this issue listing those who have been proposed and asking for a vote.
3. Once 1 further week has passed (Mon 15th March 12:00 GMT) or all committers have voted I shall place a comment on this issue announcing the result, and closing the issue once complete.

As such, please can all committers now put themselves forward or rule themselves out via a comment on this issue?

Use a BLe sniffer to grab the advertisements and data from Herald powered devices and describe what is actually seen over the wire, bandwidth use, prevention of replay/relay (of Secured payload) etc.

As per CII best practice. Also codify coding standards. Provide link to Miro around release process.

Base on the way the Zephyr project lays out their accreditation information:-

• https://docs.zephyrproject.org/latest/security/index.html

Also be mindful of comments raised in the below:-

• theheraldproject/herald-for-android#95
• theheraldproject/herald-for-android#190
• theheraldproject/herald-for-android#118
• theheraldproject/herald-for-android#110

• C++ API docs link
  • Missing on this page: https://vmware.github.io/herald/docs
  • Wrong relative URL on this page: https://vmware.github.io/herald/guide/api
• About CT page has wrong nav and not linked from main nav in about: https://vmware.github.io/herald/background/
• Also the GitHub homepage link here is wrong: https://github.com/vmware/herald (points to github.io/herald which doesn't exist)

• Colour scheme
• Font (Metropolis)
• Add new Herald logo
• Rework home page
• Add more prominent links to GitHub repos / quick start guides
• Blog link working

These numbers are all different:

From https://vmware.github.io/herald/

Herald supports 100% of the phones in the UK that support advertising, as well as the 35% of Android phones that cannot act as ‘advertisers’ and so remain unseen by advertising-only based protocols.

This one looks like an error, as if trying to factor in Android market share into numbers that were already Android-only.

From https://vmware.github.io/herald/protocol/

Supports phones and Operating Systems with known Bluetooth performance issues
Especially those ~14% of UK phones that do not support Advertising, and so cannot be served by other protocols (E.g. GAEN) - via the write characteristic approach

And then later in the same page, there's a different number:

Uses a ‘write characteristic’ allowing phones that cannot advertise (16% approx of UK phones) to tell other phones they are neaby (sic), and still provide regular distance estimation data

All of these numbers are unclear as to whether they refer to:

• percentage of total phone models available in the UK market

  Using this as a metric would inflate the prominence of unpopular phone models over popular ones.

  Some models also have dozens of SKUs (different storage capacity, carrier-specific models, dual SIM, etc.) which could further skew the statistics, depending on how they are counted.

• percentage of total phones sold in the UK market in the last N year(s)

  Using this as a metric would have the effect of inflating recently sold phone models, and over-represent consumers who buy a new phone every 1-2 years.

• percentage of total Android phones in active use in the UK market this year

  Using this as a metric would accurately demonstrate the impact of the issue – ie: N% of UK Android users can't use Advertising-based protocols.

These numbers should be consistent, and be explicit about what they're referring to, so as not to unintentionally mislead or seed distrust in the reader. 😄

Thanks for your updates so far on #14; I've opened this as a new issue because I think my last comment was missed. The original consistency problems were addressed, so really these are a "new" issue:

• Figure W2: which is based on number of Android models, that isn't called out as "models" rather than devices actually in use.

• I'm unclear as to whether has excluded non-phone Android devices, such as tablets and set-top boxes, which are unlikely to be used for any sort of Bluetooth contact tracing app, but are secondary devices that may be used for a BBC app. Some of these non-phone devices also appear in the AltBeacon list.

• Calling the advertising support data used in this calculation merely "a little old" is an exceptionally charitable characterisation. Given the egregious data problems, the documentation still doesn't make clear how this was reconciled.

  Even if one cannot get access to the same (BBC) data you used, it should be possible to use another data source to plug those numbers through the same process, to determine what fraction of devices do or don't support advertising.

• There is also a statement about new low end devices "possibly" not supporting full Bluetooth functionality, there is no data given to support this claim.

  As a counter-point, these low-end devices are likely to have other problems with their Bluetooth stack, such as being unable to support multiple connections, to which GATT-based apps like Herald is are not immune: we've seen interference on low-end devices impacting continuous blood-glucose monitors and other Bluetooth devices.

  And since then, I notice that theheraldproject/herald-for-android#112 has some workarounds for unexpected behaviour on some Samsung Exynos devices, which only impact GATT-based systems.

At present, Herald's website makes an exceptionally bold claim about the reach of other contact tracing solutions on Android. While the changes made thus far are a significant improvement, there's still a gap in these numbers, and these options come with significant trade-offs that are not fully elided in the technical documentation.

Per https://github.com/vmware/herald/blob/e223942bcca4495d551bff82a682592e37ffa382/specs/protocol.md#manufacturer-id

Herald is currently using a manufacturer data area ID of 65530 (0xFFFA big endian) for the Pseudo Device Address. The Herald Project MAY change this to one registered with the Bluetooth Standard SIG.

Per https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers/

Please note: all other decimal and hexadecimal values are reserve​d.

Using unassigned identifiers risks clashing with other Bluetooth users, potentially triggering undesired operation in Herald or other systems.

VMware doesn't appear to have any assigned company identifier, despite being an Adopter member of Bluetooth SIG. However, one may wish to consider using Service Data, 16-bit UUID instead, in order to allow VMware to use its company identifier in other applications.

• Results for 4 phone over 13.5 hrs using latest development code
• Location permission enabled
• Cross-protocol interop features available but disabled
• BLEDevice instance reuse on iOS for efficiency
• Alignment of SensorDelegate events across Android and iOS
  • iOS now only reports didDetect for Android device with new BLE address and pseudoDeviceAddress
  • iOS now only reports didRead for actual over-the-air payload reads, excluding payload data copy from local cache for Android devices with fast rotating BLE addresses
  • Mean time between RSSI has reduced from 1.44s (previous results) to 1.93s due to this change of event reporting on iOS, not protocol change
• Average battery usage reduced from 2.2% to 1.5% per hour due to efficiency improvements

• For DCT app developers - USING the API
• For Analysis algorithm developers - CREATING an analysis WITH the API

• Envelope header
• Simple payload
• Secured payload (draft)
• Check-in payload (draft)
• Bluetooth Mesh messaging interop payload (draft)