Unable to block riders from accessing my data via Sauce

[tanant]

Describe the bug I recently became aware that riders using sauce likely have access in-ride to information about me that'd be above and beyond what I'm comfortable sharing and I have not been able to find any way to remove access to what I'd consider personal, private information.

To Reproduce n/a

Expected behavior I expect my data to be unavailable until i explicitly grant access.

Screenshots n/a

Desktop (please complete the following information): n/a

Additional context n/a

[mayfield]

Hi @tanant

I can't control what zwift sends but if you send me a sha256 hash of of your zwift ID I can add it to this exclusion list that the sauce zwift module uses to determine if it should drop data coming from zwift.

https://github.com/SauceLLC/SauceLLC.github.io/blob/master/products/sauce4zwift/exclusions.json

[tanant]

Coolies, easy enough - 2353f863b61e50ba00b219bb950a9832afb13f5eead4ef4a31a6b61410b07f42

For other less technical riders who might not be aware of this, where should I be directing them? I was unable to find any pages around https://www.sauce.llc/ describing a procedure or noting that it's possible to do so.

[tanant]

Also, for a longer-range question, since this is in a json, this doesn't seem like it's dynamic and would require a new build to update - how do we go about toggling this state (for example, if i'm participating in a sauce-enabled race where race org has OKd sauce usage).

(If that's a feature request I can write that up too)

[mayfield]

An email to support at sauce.llc with their zwift id (or a sha256 hash) works best.

[mayfield]

Also, for a longer-range question, since this is in a json, this doesn't seem like it's dynamic and would require a new build to update - how do we go about toggling this state (for example, if i'm participating in a sauce-enabled race where race org has OKd sauce usage).

(If that's a feature request I can write that up too)

That exclusions.json is from the public website repo hosted by github. The sauce app fetches it on startup.

Event organizers can toggle sauce behavior with some custom event tags in the description of their event. I made a small page describing that here: https://www.sauce.llc/products/sauce4zwift/event_hashtags

[tanant]

That exclusions.json is from the public website repo hosted by github. The sauce app fetches it on startup.

Ah gotcha, so it's not build related, as long as the build knows to fetch the file it'll be up to date with whatever it fetches at startup time.

I think I might be wanting to do the inverse of those tags - if race org has chosen to endorse sauce for riders, then I'd like to, for that race, allow my data to be picked up. Those tags look like they're expecting to filter down from an default position of all data being available, whereas I'm starting from not having data available, and wanting to opt in.

[mayfield]

To clarify the hierarchy, if an athlete is in the exclusions.json, sauce will drop data for them in every context. The filter takes place at the start of incoming packet processing. The event tags are handled further down the chain.

https://github.com/SauceLLC/sauce4zwift/blob/3dd9dbef3747cf9b8d696bdf4dc072c1924d64aa/src/zwift.mjs#L1842-L1859

[tanant]

Righto, now I understand how this hangs together, would this be something you want written up as a feature request?

[mayfield]

Sure. It would require a new file besides exclusions.json since folks on that ledger won't want an event organizer to bypass it. But it could be achieved with another ledger and a new custom tag on the event like #sauce. One caveat is that the filter would need to take place further down the processing pipeline. So things like API calls looking for your followers would work differently (more permissive) than the current implementation of exclusions.json.

[tanant]

Yeah, i imagine the design is going to be a bit messy but let me see if i can wrangle up a spec that sounds reasonable, cram it into a feature request and then see where things can go. For the short term no big challenge or anything.