Public-Mesh-Research-Report.md

@@ -958,12 +958,12 @@ TODO
 
 ### Combining Transport Layers
 
-There is no single transport layer that works for all devices without user interaction:
+There is no single transport layer that works for all our test devices without user interaction:
 
 * Bluetooth RFCOMM requires either making the device temporarily discoverable (which requires user interaction) or knowing the device's own address (which requires API level < 27 or "bro mode").
 * BLE peripheral mode isn't supported on some older devices.
 * BLE L2CAP CoC requires API level >= 29 and a Bluetooth 5 chipset.
-* NSD and LSD use multicast, which is not supported by some devices and LANs.
+* NSD and LSD use multicast, which is not supported by some devices and LANs. NSD resolution is buggy and attributes aren't received on API level < 24.
 * Connecting to a Wi-Fi Direct device requires user interaction with a confusing user experience.
 * Connecting to a Wi-Fi network exposes the user to the soft AP attack, unless the network is a Wi-Fi Direct legacy mode access point and the client is using API level >= 29.
 * Ad hoc Wi-Fi isn't widely supported and has no Android API.
@@ -975,12 +975,13 @@ Each transport layer also has its own trade-offs (eg BLE GATT is slower than Wi-
 
 By combining transport layers, we can create abstractions that may offer better performance than each individual transport layer on its own.
 
-For example, a device could create a Wi-Fi Direct legacy mode access point and then advertise the network name and password via BLE advertising and Wi-Fi Direct service discovery.
-Nearby devices running Android version 10 or later (API level >= 29) could use the Wi-Fi Direct API to connect to the access point, and could then use NSD or LSD to discover other clients connected to the same access point.
-Nearby devices running older versions of Android could instead use BLE GATT to connect to the advertiser, with an allocator characteristic being used to manage concurrent connections.
-The advertiser could inform connected centrals of their own Bluetooth classic addresses ("bro mode"), enabling those devices in turn to advertise their classic addresses via BLE, Wi-Fi Direct service discovery and NSD in order to receive RFCOMM connections.
+For example:
+* A device could create a Wi-Fi Direct legacy mode access point and then advertise the network name and password via BLE advertising and Wi-Fi Direct service discovery.
+* Nearby devices running Android version 10 or later (API level >= 29) could use the Wi-Fi Direct API to connect to the access point, and could then use NSD or LSD to discover other clients connected to the same access point.
+* Nearby devices running older versions of Android could instead use BLE GATT to connect to the advertiser, with an allocator characteristic being used to manage concurrent connections.
+* The advertiser could inform connected centrals of their own Bluetooth classic addresses ("bro mode"), enabling those devices in turn to advertise their classic addresses via BLE, Wi-Fi Direct service discovery and NSD in order to receive RFCOMM connections.
 
-The soft AP attack unfortunately rules out some interesting options, such as using the `WifiManager` API to connect to a legacy mode access point on Android versions 9 and earlier (API level <= 28), or using BLE advertising and Wi-Fi Direct service discovery to share the network name and password of an access point that a device is connected to.
+The soft AP attack unfortunately rules out some interesting options, such as using the `WifiManager` API to connect to a legacy mode access point on API level < 29, or using BLE advertising and Wi-Fi Direct service discovery to share the network name and password of an access point that a device is connected to.
 
 ### Evaluate Briar's Threat Model