Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 675
    • Issues 675
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #62

Closed
Open
Opened Dec 01, 2015 by akwizgran@akwizgranOwner
  • Report abuse
  • New issue
Report abuse New issue

Reduce information leaked by polling

Polling for connections to contacts may reveal the number of contacts and their identities to a local observer. For example, anyone monitoring Bluetooth traffic near a Briar device will see periodic bursts of connection attempts from the device's MAC address to certain other MAC addresses. The observer will learn how many contacts the device has, and if the observer knows who owns any of the other MAC addresses then contact relationships will be revealed.

There are several techniques we can use to reduce information leaks.

  1. Poll at random intervals

Instead of polling all contacts at regular intervals, poll each contact at exponentially distributed intervals.

This should reduce the information about contacts leaked to a local observer. The shorter the observation period, the less likely it is that connection attempts to all contacts will be observed.

  1. Don't poll unreachable contacts

Plugins should store contextual information to help them decide which contacts may be reachable, and contacts who are unreachable should not be polled. Contacts who are rarely reachable via a given transport may be polled less frequently.

  1. Don't poll at all

Polling probably contributes to Briar's battery and bandwidth consumption, and for short-range transports it may not be the most efficient way of connecting to nearby contacts. The user knows when contacts are nearby, and may be able to connect to them more quickly by triggering a scan manually than by waiting for the next poll.

To reduce the amount of information leaked by a manual or automatic scan, the scan should detect nearby contacts and then try to connect to any that are nearby, as opposed to the current approach of trying to connect to all contacts. The rationale for the current approach is that we can't make an Android device permanently discoverable via Bluetooth, and making the device temporarily discoverable requires confirmation from the user each time. But if the scan is triggered manually, user confirmation may be acceptable. It may be possible to make a device permanently discoverable via Bluetooth LE or Wi-Fi Direct, in which case we could scan multiple transports with a single manual trigger.

Edited Nov 21, 2020 by Cleopatra
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#62