Opened 4 years ago

Last modified 3 years ago

#17023 new defect

Investigate fingerprinting of mouse/pointing events

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting
Cc: elypter, gk, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arthuredelstein)

MouseEvent, WheelEvent, and DragEvent may reveal properties of the connected pointing device. Let's examine if we can suppress some of this fingerprintability.

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by gk

Cc: gk added

comment:2 Changed 4 years ago by mcs

Cc: brade mcs added

comment:3 Changed 4 years ago by arthuredelstein

Things that worry me:

  • MouseEvent.mozInputSource is designed to report the type of pointing device being used. Maybe we should always spoof this to MouseEvent.MOZ_SOURCE_MOUSE?
  • MouseEvent.buttons reports if the user is using a mouse with unusual buttons ("Browser Forward", "Browser Back"). Suppress all but left, right, middle buttons?
  • MouseEvent.movementX/Y: Are these movements quantized in a hardware-dependent manner?
  • MouseEvent.mozPressure: Do we want to reveal that the user is using a touch-sensitive pointing device?
  • WheelEvent.deltaX/deltaY/deltaZ: Are these quantized in a hardware-dependent way?
  • WheelEvent.deltaWheel: Is this value determined by hardware or platform?

(I don't see any additional potential problems for DragEvent).

comment:4 Changed 4 years ago by arthuredelstein

Description: modified (diff)

comment:5 Changed 4 years ago by elypter

MouseEvent.which and MouseEvent.metaKey could reveal hardware specific buttons like ö
WheelEvent.deltaY and WheelEvent.deltaZ could reveal hardware because not every device has them.

not revealing the pointing device at all is difficult if the movement can be tracked. touchscreens jump mouses move pen tablets move or jump and touchpads and balls move,stop,move. x/y could only be revealed if the cursor isnt moving but i dont know if this could be circumventd with tons of hidden mouse over events.

comment:6 Changed 4 years ago by kernelcorn

This threat could be reduced if we disabled some of this functionality via the security slider.

comment:7 in reply to:  6 Changed 4 years ago by gk

Replying to kernelcorn:

This threat could be reduced if we disabled some of this functionality via the security slider.

I hear this kind of argument more often recently. Keep in mind that this slider is a *security* slider not a *privacy* slider on purpose. I think we should give the best privacy protections we can to all users independent of the security level they've chosen.

comment:8 Changed 4 years ago by cypherpunks

Please make sure the mouse functionality still works.

I.e. the back/forward buttons result in the proper browser navigation. The web page doesn't need to see the mouse events for that. One possibility would be to emulate Alt+<cursor key> behavior.

Note: See TracTickets for help on using tickets.