I agree that security on PC's isn't as mature as it should be. There just should not be a case that Riot running a kernel-mode driver -based anticheat just for

I agree that security on PC's isn't as mature as it should be. There just should not be a case that Riot running a kernel-mode driver -based anticheat just for _their_ games. Hell, I was ready to flame about it not working with virtualization enabled in BIOS as I installed Valorant a few days ago, but it actually does. Still kind of pissed to have to run it in the background (this one actually runs even when not running Riot's games btw, unlike the one in the article!) Though I don't see a situation where one would need to "root" their PC just to run custom software a good situation either. >Running always-on software when the game isn't running and talking to resources on the internet is incredibly suspicious. From what I read (actually reading a few articles longer than the general observer does while filling their FUD meter) the anticheat simply doesn't run unless the game itself is running. Which makes it comparable to just being a library contained in the game executable, but separate for whatever technical reasons. Note that Vanguard for example isn't as nice. I did not mention that leaving tons of crap in the filesystem is normal. I mentioned registry which seems to be more prone to spam. As a developer I think there should be some reasonable "scoping" in installs to limit this, leaving it for every developer to do more painstakingly just ends up in the littery situation, which I do not prefer but just mention to be the status quo. Hell, if I was in position to design something on system-level, I would just force apps to declare: -paths it writes to -registry keys it writes to -devices like webcam and other abilities it accesses while at it, like on mobiles This would then be read by installer/uninstaller and user could choose to keep this data or remove it when installing/removing software. Could also prevent writing outside of these as a general rule (unless some dev mode or similar is activated of course) About the tray icon, my point is that the situation with it ends up being kind of like an armed guard visibly carrying a weapon causing more harm in fear, and the result being them just hiding the weapons, which of course is not a dynamic that should exist. Things being done visibly should be the thing every developer by default would choose but at worst with this dynamic they will feel the need to hide things to avoid the potential FUD. This can cause behavior that is not beneficial to the user but is actually done to alleviate fear. Kind of like disabling developer stuff in games (because user will break their game and complain or some shit) which I have several times successfully argued against. >The right way to handle this is to say sorry we screwed up we wont punish people for liking a review in the future. Is more useful to think about how this could have been avoided and how this could be avoided in the future. If the deletion wouldn't been done yet, I agree that some kind of joint message could be the best. Maybe in the format: <start of review section> <NameOfUserWhoDidTheScaryReview><Time/Date> <Header box> <Text like: X developer regrets the angst caused. Valve investigated these claims. No foul play is apparent. Companion software does not run outside of the game's run time. However note that anti-cheat measures by their nature go beyond the game executable itself, while not sending unnecessary PII.> <original review text> <other reviews> <end of review section> Probably the reason this ended up in just deletion of the comment is a clusterfuck of inability to communicate or spend time on developer-user-platform owner communications only after something becomes a PR nightmare. I commented because it is a bit sad that the blame / output of this situation simply isn't constructive (does not cause awareness / pressure for things to actually to go in a better direction). In a way I see parallels to when Anthem was released and there was shock articles of the game "bricking your ps4!" when I reasonably confidently know the issue was caused just by ps4's bad SDK design which easily causes filesystem-corrupting bugs when doing the simplest of savegames. This then caused a chkdsk-type popup and a crazy dangerous-sounding SFX on the ps4's next boot but didn't seem to cause any actual damage, outside of probably losing the specific savegames from what I collected. But no constructive discussion in to that direction (how to not design your console OS/SDK) was seen anywhere in relation to that news item. >Lastly this is your only comment on this site and it seems to be a tad slanted. Do you work for a party involved in this? Fair note, but I do have reason for my tone. No I am not involved. But am a developer with too much free time currently who has worked with multiple kinds of similar stuff so I feel the reason to lament as the discussion around this seems off center. I tend to be a heavy lurker on sites I frequent, HN being one. I've visited HN probably every day for several years, mostly without an account. But when I write a comment it tends up taking so much focus I avoid internet arguments as a rule. But sometimes I make an exception like now.