# Push Attack: Binding Virtual and Real Identities Using Mobile Push Notifications
## 2 Background: How Push Notifications Work  
### Built-In Push Notification Service  
Both Android ([[https://developers.google.com/cloud-messaging/](https://developers.google.com/cloud-messaging/)]([https://developers.google.com/cloud-messaging/](https://developers.google.com/cloud-messaging/))) and iOS ([[https://developer.apple.com/notifications/](https://developer.apple.com/notifications/)]([https://developer.apple.com/notifications/](https://developer.apple.com/notifications/))) operating systems provide a built-in service for push notifications. Vendors like Google and Apple offer application developers access to this service through a set of APIs that connect to an infrastructure in charge of delivering a message to mobile devices. In a typical usage pattern, push notifications start with a third party app server that contacts the vendor server (e.g., gateway.push.apple.com) using a push notification service API. It asks to deliver a given structured message to a certain registered user of an application, identified by a device ID. The push notification server contacts the mobile device passing the push notification to the operating system when the device is online. When offline, the OS stores the notification for a limited period of time, eventually delivering it to the device, when it becomes available. When a push notification reaches the device, it can be typically (but not mandatorily) shown on the notification bar and optionally trigger application code (this behavior strictly depends on the limits of the mobile operating system). The benefits of implementing push notification at the system level are two-fold: (i) provide an easy way for application developers to have almost synchronous communication between server and application clients; (ii) optimize power consumption by avoiding several persistent connections (one per app), keeping only one shared connection for all apps, multiplexing, en-queuing and possibly stacking all messages directed to the same mobile device. Although this general schema is valid, the specific implementation of the push notification service varies by the vendor. In what follows, we briefly describe the case of Android and iOS. Google Cloud Messaging (GCM) ([[https://developers.google.com/cloud-messaging/](https://developers.google.com/cloud-messaging/)]([https://developers.google.com/cloud-messaging/](https://developers.google.com/cloud-messaging/))) was built in 2012 by Google to provide application short messages (up to 4 kB) from a server to Android devices. Even if the source code of the implementation has not been released (being part of the Google Play Store application), some details were publicly and officially released. Android push notifications work through one persistent TLS connection opened on port 5228 connecting a device with the GCM servers. This connection is monitored and kept open with periodic heartbeats (e.g., every 240 s) and re-established every time the phone connects to a network. The status of this connection is easily accessible by typing \"##426##\" on the phone (Figure 1a). Apple Push Notification ([[https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html)]([https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html))) (APN) works similarly. Each notification is limited to 2 kB. Unlike GCM, APN makes it mandatory for software developers to let their server software notify their user when applications are closed, since there is no way of creating persistent sockets. APN though sets no limit to the number of notifications. APNcomes from a ciphered channel (TLS peer-to-peer authentication) on ports 5223 or 443.