Open liusining opened 4 years ago
Where should this encryption happen? In the WebView? Could you please describe a possible use case?
A probable working scenario:
My use case:
TL;DR: encrypt geolocation data to provide additional confidence about the data's authenticity.
I am developing a bot providing some location-based service. I know that location is not fully supported now on Messenger of Android and related features are still in developing, so I'm talking about things afterward.
I have heard that Messenger will have a special API to let developers get a user's geolocation. But as long as the geolocation is given by plain latitude and longitude numbers, I cannot find a way for my backend to make sure its authenticity. That being said, a user may upload any latitude and longitude value by calling my backend APIs through an HTTP client.
However, if the geolocation data can be encrypted by a private key that users are difficult to read, I should be more confident that it is provided by a real Messenger app.
Although I'm still not able to say that a piece of geolocation info is 100% authentic and correct, with the protection of the encryption API, much fraudulence should have been kept from my application.
This could be done along with https://github.com/MixinNetwork/mips/issues/8, we have added user Ed25519 key in the API.
Other suggestions Allow Mixin Messenger to encrypt personal sensitive data stored in Mixin Cloud(Maybe decentralized cloud).
It's said that Messenger will support E2EE (#8) for bot conversations, while bots will receive users' public session keys. Under these conditions, an extra feature can be very useful for bot developers:
Why this is useful?
Knowing
A developer will be more confident that a request of the user is from a real mobile Messenger app since it's not easy to get the underlying private key without breaking the above conditions.
Messenger may allow calls to the API only from a bot context, such as the context triggered through clicking on a bot icon, and ignore calls from plain windows.
Things will be even better if the planed E2EE uses a different private session key for each bot conversation, because fraudulent bots will be hardly possible to mimic others. (Of course, this will be much more expensive)
At least, bot developers can use this API to protect some sensitive user info with ease.