# Push Attack: Binding Virtual and Real Identities Using Mobile Push Notifications
## 5 Measurements  
Being a side channel attack, we are interested in the following information:  
* How strict is the temporal binding between the notification triggering and the packet's arrival on the network?
* What is the user identification false positive ratio?  
To answer the first question, we repetitively trigger Facebook friendship request notifications and measure the time between the triggering and notification delivery to the mobile device, to estimate the application level round trip time (RTT). Figure 7 reports the empirical distribution of the RTT for a sample of 50 friendship requests. In particular, we recognize the first packet of the push notification that, in turn, triggers other connections responsible for fetching accessory data needed to properly  
Figure 6: iPhone trace: the push notification is the last spike. The inability to separate Facebook push notifications from other app notifications makes recognition harder than with Android.  
display the notification (e.g., fetching the requester's profile image). Therefore, even if the notification is viewed on the mobile device after several seconds, the packet of interest can be captured after, on average 1.08 s. Despite it being far bigger than the end-to-end network delay (measured at 12 ms), the application RTT is fast enough to enable quite a precise correlation between the triggering of the mobile notification and the packet's detection on the network.  
As for the second question, we point out that while the attack is performed, victims can also receive push notifications originated by regular application behavior (e.g., a regular friendship request). The attacker can mistake these push notifications for the ones they originated for the attack. In this case, the attacker may erroneously associate a user's identity with the wrong virtual identity, leading to a false positive detection.  
Because the attacker knows the length of the push notification that they are searching for, the false positive ratio depends in turn on the distribution of the lengths of push notifications received by users. For instance, a push notification of 196 bytes can be erroneously attributed to a friendship request event.  
To estimate the false positive rate and to tune the parameters of the attack, we conduct a measurement campaign in several different environments: a bar, a concert hall, a popular fast-food restaurant, a square, a library. We choose environments where most users connect to the free WiFi with their mobile phones, and we analyze 2 GB of mobile traffic. We extrapolate from the captured data the distribution of the lengths of the push notification messages from Facebook servers to clients. As we can see from Figure 8, the high spike at 66-97 bytes derives from the keep-alive mechanism. The other lengths are quite evenly distributed from 100 to 430 bytes. This fact, on the one hand, suggests the possibility of forging custom length notifications (e.g., private messages) to better cope with a possible false positive detection. On the other hand, the relatively low number of notifications in 2 GB of sniffed traffic demonstrates that application-specific push notifications are quite rare events. This ensures a high degree of precision even in the case of fixed size notifications such as friendship requests.  
Figure 7: Empirical PDF of round trip time of Facebook friendship request push notification.