D. Fifield, C. Lan, R. Hynes, P. Wegmann, V. Paxson, “Blocking-resistant communication through domain fronting,” in Proc. Privacy Enhancing Technologies Symposium, (PETS), 2015, landing.
V. Mavroudis, S. Hao, Y. Fratantonio, F. Maggi, C. Kruegel, G. Vigna; The Ultrasound Tracking Ecosystem; In Some Venue; 2016; 4 pages.
tl;dr → a summarization and advocacy opinion-editorial; no code was developed; no systems were measured; opinement only.
The ultrasound tracking ecosystem is a relatively new and emerging set of technologies that use in-audible beacons to track users and devices. Our work is the first comprehensive security analysis of this little known ecosystem.
- uBeacons → Ultrabound beacon audio signals.
- XDT → Cross-Device Tracking.
- uXDT → ultrasound Cross-Device Tracking.
- SDK → Software Development Kit (i.e. a library, a jarfile of Java culture).
- Google Cast.
- Google Chromecast.
- A new permission for Android, iOS & Chrome.
- Like Bluetooth Low Energy (BLE) beacons.
- Require root to send or access ultrasonic signals.
- Require a “central service” on the box to send or access ultrasonic signals.
- A Chrome extension
blocks inaudible (audio) signals (Flash still dodges the restrictions)
Something might happen…
<quote>Using [this] technique an attacker can easily mount beacon-injection or beacon-replay attacks, which will cause the nearby ultrasound-enabled devices to capture and report beacons of her choice. For 2instance, for the beacon-injection attack, imagine an attacker equipped with a simple beacon-emitting device (e.g., smartphone) walking into Starbucks at peak hour. As a result, all customers with an ultrasound-enabled app installed on their devices will be receiving the beacons and unknowingly forward them to the advertiser’s backend. In the “replay” variation of this attack, the adversary captures and replays existing beacons (e.g., to influence an analytics campaign). </quote>