Usually discord ignores all issues related to invisibility leaks but responds very fast to other types of issues which is why i decided not to wait for weeks for a fix, instead publish it and watch it get fixed.
You're right, but in this case I think some narrative liberty was justified, especially since Valve basically delegated triaging bug reports to HackerOne, but this relationship might not be immediately obvious to some readers. Suppose a nightclub contracts its bouncers from some security security firm. You get kicked out by the contract security guard. I think most people would think it's fair to characterize this situation as "the nightclub kicked me out" on a review or whatever.
It doesn't look to me like Valve delegated triaging bug reports though, rather triaging security reports. It seems fair to me that the security reporter vendor triaged this as not a security report. It feels like saying "the wedding venue kicked me out" when actually the third party bartender just cut you off.
>It doesn't look to me like Valve delegated triaging bug reports though, rather triaging security reports.
That was a typo on my side, should be "security".
>It seems fair to me that the security reporter vendor triaged this as not a security report. It feels like saying "the wedding venue kicked me out" when actually the third party bartender just cut you off.
For all intents and purposes getting your report marked as "informative" or whatever is the same as your report being rejected. To claim otherwise is just playing word games, like "it's not a bug, it's a feature". That's not to say that the OP is objectively correct that it's a security issue, but for the purposes of this argument what OP wrote (ie. 'Valve: "WontFix"' and Valve closed it as "Informative.") is approximately correct. If you contact a company to report a bug, and that company routes it to some third party support contractor (microsoft does this, I think), and the support contractor replies "not a bug, won't fix", it's fair to characterize that as "[company] rejected my bug report!", even if the person who did it was some third party contractor.
> If you contact a company to report a bug, and that company routes it to some third party support contractor
That is not what happened, though. You can contact Valve/Steam directly. They specifically went to the third-party vendor, because the third-party vendor offers a platform to give them credit and pay them for finding security exploits. It is not the responsibility of the third-party vendor to manage all bug reports.
>They specifically went to the third-party vendor, because the third-party vendor offers a platform to give them credit and pay them for finding security exploits. It is not the responsibility of the third-party vendor to manage all bug reports.
I don't know, the wording on their site suggests hackerone is the primary place to report security issues, not "if you want to get paid use hackerone, otherwise email us directly".
>For issues with Steam or with Valve hardware products, please visit HackerOne — https://hackerone.com/valve. Our guidelines for responsible disclosure are also available through that program.
No, you are correct, that is a HackerOne employee filtering the report before someone at Valve looks at it, a lot of companies have this set up and it's not great.
I would be surprised if responsible Valve staff would agree that this is not something they should fix at some point.
It's still on Valve though. They chose to delegate this and H1 basically becomes their voice here. I wish it was made more clear, but I don't think it's wrong.
That sounds to me like they're acknowledging that the feature doesn't work as advertised ("may not align with user expectations"), but also that it was reported as a exploit/security vulnerability, while it's actually a privacy leak. Maybe HackerOne isn't the right channel for reporting those issues?
In this context, 'Logoff' triggers whenever the socket disconnects. So every time you shut down your PC or put it to sleep, that timestamp is updated and broadcast, even if you never explicitly clicked 'Sign Out'.
Still, I dont run steam on my laptop and on my gaming system that I let my kids use it never sleeps and restarts only as a result of windows update. The monitors do turn off but unless that counts as sleep as well I dont really see how this would be a thing at least as how we use steam.
True, but a tracking pixel is an active attack that leaves a visible trail. This leak is passive surveillance; I can silently graph the sleep cycles of 200 friends without ever interacting with them. Trust shouldn't imply consent for invisible, automated logging.
Do you really need an LLM to talk on HN? Genuinely, this research seems cool but its hard to trust your findings when there's clearly AI being used heavily in writing the article and in your comments here.
It's about when your friends were last signed-in in their account. From my understanding:
Invisible = Sign-in but do not broadcast the games you are playing (though your profile will show that you signed-in)
Offline = Stay offline and do not sign-in
Incorrect. "Invisible" is a privacy control, not just a UI filter. While the official client freezes the text, the backend still broadcasts live last_logon and last_logoff Unix timestamps in the ClientPersonaState packet. This leaks exact real-time sleep/wake cycles via the socket, completely bypassing the privacy toggle.
Nope, going into standby is the same as logging off, since your client doesn't send keep alive packets anymore. (Not sure if macOS is an exception, because I think my MBP doesn't go into proper sleep if I keep Steam running)
I got one from work that I don't use much outside of travel and haven't changed in any way past initial setup. It stays connected to WiFi and continuously broadcasts various discovery packets for the past month and a half since I last opened it up.
