Urgent upgrade notice at launch

[roihershberg]

Hello! This is an amazing project! Thank you for that!
As I stumbled upon the TokTok/c-toxcore#426 security issue and the reimplementation of the handshake as been worked on in TokTok/c-toxcore#1561 and the possibility of being no backwards compatibility as a result of that combined with the fact that aTox is going to get a new big release after long time so the possibility of almost all users to upgrade is high, I suggest to inject a little thing to the app.

If the Tox Protocol is going to change and have no backwards compatibility it is important to encourage users at the launch of the app to upgrade to the new version of the app that will have the new protocol so everyone will be on the new protocol that will be much more secure. So I suggest adding a code to the app that after the unlocking of the profile, it will fetch a URL and if an urgent message is available, it will display it.
That URL needs to be static in a domain whose control would probably not be lost. If that page will return a valid JSON object with the required attributes, the message will be displayed, otherwise no message will be displayed. So for example, if the page would return an empty content (which should be the current behaviour) or the request gets a 404 response (unfortunate loss of domain) or any other error, the app will display no dialog.
The JSON object should have an id attribute for identifying the message and a title and message attributes for the title and message to display in the dialog.
The dialog itself should have an OK and a DON'T SHOW AGAIN buttons and I suggest putting the OK button in the far-right of the dialog (the default location) and the DON'T SHOW AGAIN in the far-left so that the two buttons won't be near each other to prevent misclick on the DON'T SHOW AGAIN and also to indicate that this is not just another "cancel" button. I think that for this to happen the OK button needs to be assigned to the Positive Button and the DON'T SHOW AGAIN to the Neutral Button but not sure about this.
The OK button offcourse just dismisses the dialog but the DON'T SHOW AGAIN button should store the current message ID in a preference. Everytime the app fetches that URL and receives a valid JSON object the app should check if the message ID corresponds to the one optionally stored in the preference. If so, then no dialog will be shown, otherwise the new message will be shown and if the user chooses the DON'T SHOW AGAIN button again, the app will just override the preference with the new message ID as the last one is not relevant anymore.
An example of a valid response from that static URL is:

{"id": 1, "title": "Urgent upgrade", "message": "The Tox Protocol has received an important security fix which is not compatible with previous versions. Please upgrade the app for migrating to the new protocol. Note that whether you choose to upgrade or not, your contacts must choose the same as you if you want to keep chatting with them."}

As this change means revealing to listeners on the network everytime you open the app and unlock the profile, user anonymity must be respected. So if a proxy like Tor is defined in the settings of the app, this fetching of the URL should be requested through that proxy.
Thank you.

Edit:
If it's possible to get the code of the currently used system language then supporting multiple languages would be nice, with fallback to English. In this case the JSON structure could be that the title and message attributes would be in an object as a value and the language code as a key. Example JSON:

{"id": 1, "en": {"title": "Urgent upgrade", "message": "The Tox Protocol has received an important security fix which is not compatible with previous versions. Please upgrade the app for migrating to the new protocol. Note that whether you choose to upgrade or not, your contacts must choose the same as you if you want to keep chatting with them."}, "fr": {"title": "...", "message": "..."}, "it": {"title": "...", "message": "..."}, "ru": {"title": "...", "message": "..."}, ...}

[robinlinden]

Hopefully we'll find some bit in the handshake to allow us to run both the new and old one for a transition period, but if not it will be a very breaking change. :(

You don't think it's enough that you get an update notice from FDroid/GPlay?

I'll have to think about this feature request for a bit. It would be good to be able to notify users about a protocol-breaking change like that, but I'm also a bit uncomfortable introducing a centralized server like that, especially since it'd also be a form of tracking. If implemented, it would also need to include safe-guards so it doesn't ping the remote server before the user's had a chance to set up a proxy if they want.

[roihershberg]

I don't think that the update notice is enough. It is important to clearly state to the user before he upgrades that this isn't a regular upgrade and his contacts must upgrade too in order to keep communication between them, or they should both decide not to upgrade.

You're right about the centralized server issue. So maybe a different approach would be to add a functionality to the bootstrap nodes that they can return an important notice to the client. I think that in this case the nodes would fetch the centralized server for you and return the notice to you if it exists, so there isn't a big change in the clients except for checking for additional notice payload.
However, AFAIU it requires a collaborative change in the protocol. And if some bootstrap node didn't upgrade to the latest software that supports the notice payload, or some clients don't support it, then no dialog will be shown.

[roihershberg]

This should be closed right?
At best if it's really necessary we can publish a new release before the release of the migration that contains a static dialog similar to what I described just without the fetching of the server (With DON'T SHOW AGAIN, etc.).

[robinlinden]

Yeah, I don't think we'll be doing anything with this anytime soon. Implementing it in a way that won't make me feel icky feels difficult. :P Publishing a release just before a hypothetical protocol-breaking change would hopefully be good enough.

[robinlinden]

Closing as per the discussions.