Email or username:

Password:

Forgot your password?
dansup's posts Post Back to profile
Top-level
feld
@grishka @dansup

> If you instruct app developers to create separate API keys just for push notifications, no harm could be done with them

Is this allowed? And does Apple/Google allow you to share your keys like that?
3 October at 22:30 | Wall-to-wall | Open on friedcheese.us
6 comments
Григорий Клюшников

feld, what do you mean by "allow"? They do both tell you to "keep them secure", but I can't imagine them revoking the keys that are useless without device tokens anyway.

3 October at 22:34
dansup

@feld @grishka What are you talking about?

This is literally how every Mastodon/Pleroma app works, the developer uses a proxy server to forward requests from Mastodon/Pleroma/Pixelfed to APNS/FCM.

The API keys are for signed requests to my proxy server

3 October at 22:43 | Open on mastodon.social
dansup

@feld @grishka I want to further clarify that the ExpoToken that the app generates and sends to the server is useless unless you have our expo API key, so you can't abuse access to FCM or APNS

3 October at 22:56 | Open on mastodon.social
feld
@dansup @grishka I mean if I pull up the source of Husky or whatever on GitHub the key will be in there? I thought it was only in the officially built and distributed app
3 October at 23:06 | Open on friedcheese.us
Григорий Клюшников

feld, no. That's not how it works with Mastodon (and Pixelfed). No currently existing apps do this.

The usual implementation of native mobile app push notifications involves three things:
- A server API key. It's hardcoded on the server that sends push notifications. It's used for authentication when making requests to FCM/APNS. Normally kept secret.
- A client ID. It's hardcoded in the app, used for getting a device token. Google calls it the "FCM sender ID", not sure if Apple has an equivalent or they just use bundle IDs. Mastodon Android app has it hardcoded here.
- A device token. Dynamically obtained by the app at runtime from the system, then sent to the app server. The server then passes this together with the server API key to the Google/Apple server when it wants to send a push notification to this particular device. So, the server API key and the device token together uniquely identify this particular app on this particular device. (The name "device token" might be misleading, because it's also unique per-app on the same device.)

Normally, this server API key is kept secret. I'm proposing to allow app developers to publish theirs to avoid the need for a proxy server whose primary purpose seems to be to keep that key secret (secondary being to not make Mastodon/Pixelfed/whatever implement all the proprietary push APIs).

feld, no. That's not how it works with Mastodon (and Pixelfed). No currently existing apps do this.

The usual implementation of native mobile app push notifications involves three things:
- A server API key. It's hardcoded on the server that sends push notifications. It's used for authentication when making requests to FCM/APNS. Normally kept secret.
- A client ID. It's hardcoded in the app, used for getting a device token. Google calls it the "FCM sender ID", not sure if Apple has an equivalent...

3 October at 23:23
feld
@grishka @dansup there was a misunderstanding on my end; I agree with your description, that's how I understand it. We made a push proxy called Charisma for apps we were working on along side Pleroma so this is familiar.

if there was the ability to *not* have a push proxy run by the app developers it would be great. I strongly support your proposal.
4 October at 0:26 | Open on friedcheese.us
Go Up