Every character you type results in some sort of hit to their telemetry server. It will include the actual letter you typed, if you or your org are not configured to be in EU. With their EU configuration option (pulled from server every launch) it will only report the fact that you typed _something_.
Now if that's not fun enough, their telemetry also covers mouse movements. Go ahead and watch your CPU as you spin your mouse in circles around the Teams window.
For extra fun, block their telemetry server and watch Teams bloat in RAM, to as much as your system has, as it keeps every action you take in local memory as it waits for the ability to talk to that telemetry server again.
If you're going to block their telemetry its best to fake an accept via some mitm proxy and send back a 200 code.
I do not know exactly how much this applies to iPad version, compared to their desktop apps. Mobile offers both more and less data possibilities. It's a different context.
So they’re running a keystroke logger and masquerading it as “telemetry”? That should be outlawed. It’s not a drafts feature, it’s not an online word processor, it’s just a straight up keystroke logger.
I’m in the EU and should have the EU configuration.
The problem mainly occurs when I mention someone in a reply to a thread. Once I type @<name> the text input just slows down so much I can type much faster than it can render the text.
It's still going through the same telemetry action, it just omits the actual character you typed. And yes, it is character by character. That collection (eg, the timestamp you hit the character, channel/person it was to, etc) is the inefficiency causing your typing to slow.
If it was a straight text box that they polled contents of _occasionally_ or after you hit 'send', it would be a much better user experience.
Haha what exactly does it protect me from? If they see that I typed something to someone, and see the chat history of me having sent a particular message at a particular time, it doesn't take a genius to put things together.
As much as I dislike overbearing telemetry in the context of an M4 or even an N95 the computer should be more than capable of logging a few kb of telemetry about inputs per second without even a notice on the performance statistics. The problem remains that every single thing in the app is just implemented god awful slow and would still be regardless if it's also recording telemetry on the input data or not.
...do you have any source verifying this? Setting aside how insane of an issue it'd be network-wise/privacy-wise/etc, this is like a day one "debounce the call" fix.
I'm not even saying I doubt you, I'm just curious how you ascertained this exact behavior.
Mainly this was just myself getting irritated at MS Teams and trying to figure out what it was doing. It was a couple years ago and my current company doesn't use teams, thankfully, so I can't really see if its still valid.
From what I remember..
There are files on the disk that get updated/overwritten with pulls from the server every time it launches. Somewhere in AppData I think. A few of these are config files (with lots of interesting looking settings, including beta features).
One of the config entries specifies a telemetry endpoint (which, you _could_ figure out with a network tracing tool but there are a ton of MS telemetry endpoints your machine is probably talking to. Best to just grab the one explicitly being used from the config like this). I forget the full name of the setting but the name pretty clearly indicates its for telemetry, and the file is clearly a config file. If you can't find it just by browsing the structure, try a multi-file search tool and look for 'telemetry' or URL/hostnames.
You can't really change the value on disk and make it just take effect from there, since it gets downloaded from the server and overwritten before Teams loads. There might be some tricks you can do locally to persist the change but nothing seemed to work for me. You could override response from server via mitmproxy but that requires finding where it comes across the wire at launch time and then building a script/config to replace it.
Anyway, you can block that telemetry endpoint from a firewall and see your memory bloat. Or you can intercept that endpoint in any mitm proxy. I went with this [mitmproxy](https://mitmproxy.org/). From there you can capture the content it sends to the endpoint, or even change the response the server sends (Teams just seems to expect a 200 code back).
The telemetry data itself is some kind of streaming event format. I think I even found documentation on the structure on some microsoft website, so its likely a reused format.
It's pretty straightforward.
I couldn't spend too much time on it and now it's not something I even use, but some cool things you might want to try if you dive deeper into this:
- Overwrite the config file as it returns from the server, to turn on EU data protection, change various functionality you're not supposed to, or flip some feature flags.
- Figure out if there's a feature flag or even other overwrite to fully disable the metrics so they aren't even collected, from anywhere in the app.
- Intercept telemetry, return an 'OK' response and drop the data from telemetry, or maybe document what they collect more definitively if you think there's interest somewhere. This keeps your privacy but doesn't really do anything for performance.
- Interfere with the data before actually returning it, maybe try playing with event contents and channel/user indicators. Microsoft probably won't like this if they notice, but it's unlikely they'll even notice.
No clue why they're even doing this and not just sampling after the fact. There's no way they are gleaning anything useful that they couldn't more efficiency (and anonymously) capture.
Ah, that's right, Chrom* based things look at the system store by default and it's the Firefox based things that don't (without configuration at least). Thanks.
Edit: and that reminds me I should probably run this test on new Teams, where it now uses the built in WebView2
Is the telemetry really that big of a load? Having a persistent connection and sending data over it is pretty standard for games going back decades, even AOL instant messenger had this feature for typing.
Asana used to sometimes have textareas that would take a full three seconds to display each key press. On then-current MacBook pros. You know, something that had nearly zero latency on first-gen single-core Pentium chips. Hell it may still do that, I never saw them fix it, I just finally got to stop using it.
Never underestimate the ability of shitware vendors to make supercomputers feel slower than an 8086. These days it usually involves JavaScript, HTML, and CSS.
Now if that's not fun enough, their telemetry also covers mouse movements. Go ahead and watch your CPU as you spin your mouse in circles around the Teams window.
For extra fun, block their telemetry server and watch Teams bloat in RAM, to as much as your system has, as it keeps every action you take in local memory as it waits for the ability to talk to that telemetry server again.
If you're going to block their telemetry its best to fake an accept via some mitm proxy and send back a 200 code.
I do not know exactly how much this applies to iPad version, compared to their desktop apps. Mobile offers both more and less data possibilities. It's a different context.