Proposal: Push Notification Based Signaling Channel

Proposal: Push Notification Based Signaling Channel Modern Operating Systems and Browsers support push notifications that can include data in their payload. This provides a uni-directional communication channel from the client to the server if the client does not have a push receiver running, or a bidirectional communication channel if the client has a push receiver running.

As we have seen in recent block happened in Russia, even with domain fronting, adversaries are able to block fronting domains without significant consequence as in the case of meek-azure. We might want to diversify our signalling channels to prevent blocking

Advantages

Collateral Damage Maximization

These pushing channels have no substitutions and offer a functionality that is observable to users. Once the pushing service is blocked, all apps(with servers hosted in the region) and websites will be influenced.

Asymmetrical

When WebPush is used, a single codebase that interacts with a browser in a standardized way can be used on all browsers. The adversary will need to block a significant amount of service while we don't need to do anything vendor-specific.

Plausible Fingerprint

For a push notification sender, it is expected to interact with applications that send requests from a non-browser environment. For push receivers, the proxy software won't interact with push service directly, thus no chance of being recognized for fingerprint.

Disadvantages

Special Environment for Receiver

Push notification receiver requires a running operating system or browser. This means it would be difficult to ship it with the client. The message from server to client may need an alternative channel such as to reply with source address forging.

Special Setup Requirement

iOS-based push notification requires an Apple Developer account. This is not required by Web Push in most cases.