Upon the release of Google Cloud Messaging (GCM), Google provided an option to restrict push notifications by IP address. Using this feature, the owner of the Google push notification account could configure the Google settings (via the Google user interface) to limit push notification deliveries to senders from specific IP addresses. For example, an organization could configure rules to say “Accept pushes only if the sending IP address is one of the following: 188.8.131.52, 184.108.40.206, 220.127.116.11,…”
Google subsequently required all push notification users to move from Google Cloud Messaging (GCM) to Firebase Cloud Messaging (FCM) in 2017. During this migration, Google push notification users were provided the option to convert to new Google server keys OR to continue using "legacy keys." If a Google push notification account chose to continue the use of the legacy keys, the original whitelisting restrictions continued to be enforced. The new Google server keys did not enforce whitelisting.
What is happening?
Some Acoustic Campaign customers chose to make use of the Google whitelisting and legacy key capabilities. As Acoustic performs infrastructure upgrades to the Acoustic Marketing Platform, Acoustic expects the IP addresses of our push notification servers to change. As a result, Acoustic is providing guidance about whitelisting requirements that may impact these Google push notification customers.
What do I need to do?
If your organization uses legacy key credentials in your Acoustic app keys AND if your organization set up whitelisting with GCM, please choose one of the actions noted below in order to avoid a service interruption to your organization's push notifications:
- Convert from using legacy 48-byte keys in your app keys to Google server keys (150+ bytes). This is the solution recommended by Google. (https://firebase.google.com/docs/cloud-messaging/http-server-ref).
- Disable whitelisting on your legacy keys using the Google UI. This will allow Acoustic push notification servers to send pushes on your behalf without restricting by IP address. This is likely the least disruptive change.
Failure to perform one of these actions will prevent Acoustic from sending push notifications on your organization's behalf after your pod's infrastructure upgrades are complete.
If your organization does not use legacy keys OR your organization did not set up whitelisting with GCM, you can safely ignore this message.