Important announcement that may affect your project

[luciopaiva]

Hey folks,

I'm a backend engineer at Zwift and want to bring to your attention some upcoming changes that are likely to affect your project.

In July we are rolling out a new encryption protocol that will affect all UDP and TCP communication between client and server, and also between client and the Zwift Companion app (ZC), in order to meet a new requirement from Google Play (they recently changed their user data safety policy).

The rollout will span several days and you may see both encrypted and unencrypted clients running concurrently during that period. It is expected that by July 20th we will have all our communication fully encrypted.

After July 20th, unencrypted clients will be considered deprecated, but still supported. Eventually, however, Zwift will enforce encryption for all clients, but that date is still to be determined.

How exactly that affects your project will depend on what it does:

• server clones: they won't be affected by encryption while unencrypted communication is still supported. Encrypted clients must negotiate encryption with the server, and they will simply fall back to unencrypted communication if the server doesn't know any better. When encryption is enforced, however, these projects will stop working;

• ZC clones: they won't be affected during that initial phase either. Encrypted clients must also negotiate encryption with ZC, and they will also fall back to unencrypted in case of pre-encryption ZCs. When encryption is enforced, however, these projects will stop working;

• client sniffers: those will be immediately impacted when rollout starts. Not only is the protocol specification changing, but the very payload being sniffed by those projects is now encrypted. Logic that relies on reading user data from network packets will simply fail if the data is encrypted, as one would expect;

• BLE and ANT+ devices: projects that emulate either BLE or ANT+ devices won't be affected, not even after encryption is enforced (unless of course they also fit any of the roles aforementioned). We are not changing those communication protocols in any way.

Please note that this change is required to secure user data, not to discourage community projects. We are internally discussing if and how we can help community projects go through the change and continue working. That said, please have in mind that this is not merely an engineering decision, but it must also involve other departments like Product and Legal. We will post further updates here as soon as we have any news.

We'll also try our best to answer questions, depending on the availability of our backend engineering team. You can trust replies from any of the engineers listed here.

Ride On!

[mayfield]

A sad day for Zwift add-on developers but understandable.

[mayfield]

@luciopaiva I have a few questions.

Is there a place where this can be discussed more broadly so as to involve more add-on projects?

My understanding is Zwift Power uses client based bots and sniffing to acquire game data, if so, how will they continue to function?

Will Zwift consider adding an in-game or server API for getting a mirror of the world-updates/player-states as we achieve today with packet sniffing? This could be done securely and with proper consent from the user with authentication.

What encryption protocols are going to be used for the game proto and the ZC proto? I.e. is it just wrapped with TLS and trusting the cert chains the operating systems trusts, or something else not involving cert authorities and hidden key material?

Thanks in advance, Justin

[mayfield]

Refs to possibly link any discussions...

Ref to same post at zwift-offline: zoffline/zwift-offline#190 Ref to same post at ZwiftActivityMonitor: ruffk/ZwiftActivityMonitor#16 Ref to same post at Climber: vincent290587/Climber#9 Ref to same post at zwifit-incline-tracker: RasPelikan/zwifit-incline-tracker#4

[oldnapalm]

Refs to possibly link any discussions...

https://github.com/sandermvanvliet/RoadCaptain/issues/91

[snicker]

Likely that this will also affect https://github.com/jsmits/zwift-client Issue created there https://github.com/jsmits/zwift-client/issues/315

That library is based on https://github.com/Ogadai/zwift-mobile-api Issue created there https://github.com/Ogadai/zwift-mobile-api/issues/32

I maintain the Zwift Homeassistant integration which relies on @jsmits implementation: https://github.com/snicker/zwift_hass

Neither of these have really been maintained in a while. I'd be motivated to build on @jsmits work for a Python3 library if there is a path forward for client masquerading when encrypted, or if the Zwift engineers are open to exposing an API for users to authenticate.

[mayfield]

Likely that this will also affect https://github.com/jsmits/zwift-client Issue created there jsmits/zwift-client#315

I think this lib might be unaffected from a quick look at the code. It appears to use the public REST API and not the "developer" API that zwift-mobile-api moved to.

[snicker]

Likely that this will also affect https://github.com/jsmits/zwift-client Issue created there jsmits/zwift-client#315

I think this lib might be unaffected from a quick look at the code. It appears to use the public REST API and not the "developer" API that zwift-mobile-api moved to.

Aye, I think you may be correct- I was thinking of "ZC Clones" as Zwift Client rather than Zwift Companion. Will let @luciopaiva confirm here.

FWIW, if we have the attention of backend devs, I'd still advocate for a more "official" API where the user can grant an application an access token rather than relying on their credentials

[Fleshi1981]

I maintain the Zwift Homeassistant integration which relies on @jsmits implementation: https://github.com/snicker/zwift_hass

Hopefully there is a fix for this integration in the future? I use this one a lot.

[mayfield]

What encryption protocols are going to be used for the game proto and the ZC proto? I.e. is it just wrapped with TLS and trusting the cert chains the operating systems trusts, or something else not involving cert authorities and hidden key material?

From scanning public GitHub history looks like TLS (tcp) and DTLS (udp) are likely.

[mayfield]

@luciopaiva Under the presumption that TLS and DTLS are the encryption protocols, would Zwift be open to providing functionality like Chromium and CURL's SSLKEYLOGFILE? In theory this would be a very low impl cost to Zwift and still maintain compliance with Google Play and keep consumers protected from unwanted eavesdropping while allowing on-device 3rd party apps to extend functionality. Doing the decrypt from the packet capture would be our problem but easily completed.

[felipenasc]

Is there a place where this can be discussed more broadly so as to involve more add-on projects?

Hi @mayfield , Not right now, but we are currently discussing it after receiving your question. Suggestions are welcome as we look into this further.

[felipenasc]

My understanding is Zwift Power uses client based bots and sniffing to acquire game data, if so, how will they continue to function?

We’ve reached out to the ZP team and they confirmed it no longer requires sniffing, so everything will continue working as expected there.

[felipenasc]

What encryption protocols are going to be used for the game proto and the ZC proto? I.e. is it just wrapped with TLS and trusting the cert chains the operating systems trusts, or something else not involving cert authorities and hidden key material?

We can’t share many details at this point, but rest assured we are using industry standard encryption to comply with Google Play’s requirements.

[felipenasc]

I think this lib might be unaffected from a quick look at the code. It appears to use the public REST API and not the "developer" API that zwift-mobile-api moved to.

Any projects that are exclusively using Zwift APIs will continue to work as usual. This change only affects UDP and non-HTTP TCP communication. APIs run securely via HTTPS, so they are not being touched by this change.

[felipenasc]

Likely that this will also affect https://github.com/jsmits/zwift-client Issue created there jsmits/zwift-client#315

I think this lib might be unaffected from a quick look at the code. It appears to use the public REST API and not the "developer" API that zwift-mobile-api moved to.

Aye, I think you may be correct- I was thinking of "ZC Clones" as Zwift Client rather than Zwift Companion. Will let @luciopaiva confirm here.

FWIW, if we have the attention of backend devs, I'd still advocate for a more "official" API where the user can grant an application an access token rather than relying on their credentials

Yes, we love the idea and that is being discussed internally as well.

[felipenasc]

Will Zwift consider adding an in-game or server API for getting a mirror of the world-updates/player-states as we achieve today with packet sniffing? This could be done securely and with proper consent from the user with authentication. would Zwift be open to providing functionality like Chromium and CURL's SSLKEYLOGFILE?

@mayfield Thanks for the input suggesting ways to solve this. You folks are on the right track there. We do have a possible quick solution for projects that rely on sniffing packets, but the engineering part is the easy one - it needs to involve other teams. We expect to have more details on that soon. We are doing the best we can because we truly believe community projects like yours are awesome. Just have in mind that we also have to take into account company priorities.

[mayfield]

Looks like it's started.

New ports are 3024 and 3025, udp and tcp respectively.

[jeroni7100]

Hi,

It's Jesper from ZwiftHacks here.

• client sniffers: those will be immediately impacted when rollout starts. Not only is the protocol specification changing, but the very payload being sniffed by those projects is now encrypted. Logic that relies on reading user data from network packets will simply fail if the data is encrypted, as one would expect;

This breaks ZwiftMap and a couple of other tools from ZwiftHacks.

I would be very interested in hearing about your plans for letting us restore the many community add-ons this impacts.

[mayfield]

@luciopaiva how are these internal discussions going?

[ursoft]

New ports are 3024 and 3025, udp and tcp respectively.

There is also new ZCA securePort 21588 (TCP, protobuf) - in addition to old unsecure fallback port 21587.

[sandermvanvliet]

I’ve managed to get the encrypted connection working in RoadCaptain. Working on the docs now so it becomes easier to implement for others too 👍

[luciopaiva]

@luciopaiva how are these internal discussions going?

No news, unfortunately. Not representing Zwift here, but what I can say is that external communication coming from a company this big usually involves many people reviewing and approving messages, so it's not as fast as we'd like.

Nevertheless, I'm happy to see that @sandermvanvliet got it working. It looks like zoffline also has a PR open.

[ursoft]

It looks like zoffline also has a PR open.

Yes, we've already done a small inter-ocean secure multiuser ride (with ZCA's attached), everything seems to be working fine.

[sandermvanvliet]

I’ve written some docs on how the encryption works here: https://github.com/sandermvanvliet/RoadCaptain/blob/main/docs/ZwiftEncryption.md

feedback is appreciated 👍