When device connects to a network (wired or WiFi), it exposes its MAC address - a unique identifier for its network interface. Vendors, like Apple or Sony have patterns of MAC addresses, allowing Fingerbank to use that information for device identification.
Moreover, a device will generally issue a DHCP request on the network upon connection. It is the DHCP client of the operating system that issues a DHCP request on the network. When doing so, it asks for DHCP options (like DNS Server, WINS server, default gateway, etc.). The order in which the DHCP client asks for those options is relatively unique and identifies the specific operating system version. That allows Fingerbank to use one more information for device identification. The same principle applies to DHCPv6 where those options are also asked in a specific order and an enterprise identifier is submitted in the DHCP packet.
Also, Web browsers (or HTTP clients in general) used on devices also leave a fingerprint - their User-Agent. The User-Agent gives information to the Fingerbank project on the operating system, HTTP client software and more.
Finally, unique device patterns while communicating using TCP sockets gives Fingerbank an additional information that can confirm the other ones listed above in order to detect spoofing.
All these information sources allow Fingerbank to be accurate in identifying devices on the network.
We are looking at adding more sources in a near future. For example, SSL options ordering, UAProf checks and more.