3 ms·

>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT

>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).

marcosdumay 3y ago
It's not only security, it's correctness. It's about your software staying running and doing the right thing. I can believe HFT developers think they don't need it.
- infamouscow 3y ago
  First, 100% of HFT are businesses trying to make money above all else. Security and correctness are secondary to the business requirement of making money, especially when you are uniquely situated to have financially quantified their risk when things go wrong to remain within controlled error bands. Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to some example where their favorite toy is used at some organization, but that's besides the point. The tools for getting code on those FPGAs is horrible and unless Xilinx adopts Rust internally I doubt much will change. Rust can be adopted elsewhere, but that's not what's making the organization money. HFT folks are not persuaded even slightly by these arguments about security and correctness. Jane Street is not a HFT firm and they will gladly tell you that. It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. Of course, this will simply be downvoted by the pathetic and unimpressive. Nobody views this as an opportunity to even try disputing the argument or use it as a legitimate data point that Rust should strive for. They simply want obedience and mindlessness in the monoculture because they lack the tools needed to handle conflict of any kind. It's also why so many features are perpetually stuck as nightly rather than stable. The project does nothing but stultify talent into leaving for genuine innovation.
  - throw10920 3y ago
    > It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. I think that it's a little unlikely that the Rust community is mostly composed of "amateurs and unemployable extremists" - a lot of the working software engineers I know are interested in or actively use it. However, "assuming they're identical and them swiftly demonizing anyone that dissents" is an excellent characterization of, at least, the parts of the Rust community that I see on HN and Reddit.
almatabata 3y ago
> Or the ones writing code where security doesn't matter, like HFT and video games A lot of games have a multiplayer mode nowadays, that opens it up for exploits. I do not want to get my PC hacked because I connected to a game server. If you mean only single player offline games, I guess yes security is less of an issue.
amlozano 3y ago
Complicated video games, especially ones with transactions or multi-player aspects, require a lot more security code than you might expect.
- bigyikes 3y ago
  Is video game security an entire subfield of its own? I imagine there are categories of exploits in video games which simply don’t exist in other areas of software
  - kaoD 3y ago
    Yes. Basically cheats and anti-cheats became their own thing security-wise and huge amounts of effort are spent (by both sides) on this cat and mouse game. Although both cracking (as in "software cracking") and cheats were very similar security fields back in the day (both boiled down to reverse engineering) cheating has diverged enough (due to modern anti-cheats and anti-piracy becoming very different countermeasures) that I'd consider them vastly different nowadays. Some categories of exploits unique to games: - Aim hacking (pointing the mouse cursor to enemy heads) - Recoil/spread cheats (mouse compensating for weapon recoil or bullet spread) - Botting/botfarming (playing resource-intensive games automatically) - Wallhacking (showing players through walls, or making walls semi transparent) - Miscellaneous passive assistance (like overlaying a predicted path for a ball in a game, drawing precise location for footsteps/other player sounds, etc.) - Modification of game state (like sending your character's position at will, allowing you to fly or go through walls) Some of these have analogues in app security: - Botting detection is probably very similar in both MMOs and CloudFlare) - Hidden information is not very different from what we do in web apps (only send the state that the client needs and has access to) - Preventing game state modification is solved by having a strongly authoritative server (again pretty normal in app land) But even in those, what makes games very unique compared to other apps is that they're hard real time: you have hard requirements for each frame time; it's expensive to calculate in-server all things that a player should be able to see every single frame; packets take time to travel over the internet so you have to give it some slack (or enemies could pop out of nowhere when crossing doors); client sometimes needs information that you'd like to remain private (you need player positions even behind walls to provide 3D sounds)... Modern anticheats usually resort to just scanning the memory for running cheats, trying to detect a cheat reading/modifying the game memory, etc. but cheats have come to great lengths like having actual cheat hardware (DMA devices on PCIe[0]) that cannot be detected since it's running outside of the computer software. [0] https://blog.esea.net/esea-hardware-cheats/ https://blog.esea.net/esea-hardware-cheats/
jerf 3y ago
Others have corrected you about gaming; I would point out that for HFT if you write a memory error, you are reasonably likely to encounter it because of the sheer number of swings of the stick you get at hitting the bug. And if that code's concurrent at all, and it probably is, it had even moreso better get it right. You do not want to discover memory errors at run time. I'd bet HFT has already got all the best static analysis money can buy, not that they're cowboying it more than anybody else. Memory safety isn't just about "security". Sure, that's a huge issue, but it's also about not spending a month debugging why the login fails one out of a thousand logins because the user's password gets replaced by what seems to be a pointer, but one that doesn't point at anything, starting with the 5th character, or why your HFT code should have ordered 10,000 shares but instead ordered a pointer's worth of shares, or why the second level crashes after precisely the 1023rd frame with completely incomprehensible errors, or any number of other things. I do not know why any sane developer that has worked through such a thing even once would be willing to entertain the notion of programming without it if it weren't utterly forced on them. I enjoy reading such tales of diagnostic heroism; I don't enjoy being in them anywhere near as much as some programmers apparently do.

marcosdumay 3y ago

It's not only security, it's correctness. It's about your software staying running and doing the right thing. I can believe HFT developers think they don't need it.

infamouscow 3y ago
First, 100% of HFT are businesses trying to make money above all else. Security and correctness are secondary to the business requirement of making money, especially when you are uniquely situated to have financially quantified their risk when things go wrong to remain within controlled error bands. Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to some example where their favorite toy is used at some organization, but that's besides the point. The tools for getting code on those FPGAs is horrible and unless Xilinx adopts Rust internally I doubt much will change. Rust can be adopted elsewhere, but that's not what's making the organization money. HFT folks are not persuaded even slightly by these arguments about security and correctness. Jane Street is not a HFT firm and they will gladly tell you that. It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. Of course, this will simply be downvoted by the pathetic and unimpressive. Nobody views this as an opportunity to even try disputing the argument or use it as a legitimate data point that Rust should strive for. They simply want obedience and mindlessness in the monoculture because they lack the tools needed to handle conflict of any kind. It's also why so many features are perpetually stuck as nightly rather than stable. The project does nothing but stultify talent into leaving for genuine innovation.
- throw10920 3y ago
  > It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. I think that it's a little unlikely that the Rust community is mostly composed of "amateurs and unemployable extremists" - a lot of the working software engineers I know are interested in or actively use it. However, "assuming they're identical and them swiftly demonizing anyone that dissents" is an excellent characterization of, at least, the parts of the Rust community that I see on HN and Reddit.

almatabata 3y ago

> Or the ones writing code where security doesn't matter, like HFT and video games A lot of games have a multiplayer mode nowadays, that opens it up for exploits. I do not want to get my PC hacked because I connected to a game server. If you mean only single player offline games, I guess yes security is less of an issue.

amlozano 3y ago

Complicated video games, especially ones with transactions or multi-player aspects, require a lot more security code than you might expect.

bigyikes 3y ago
Is video game security an entire subfield of its own? I imagine there are categories of exploits in video games which simply don’t exist in other areas of software
- kaoD 3y ago
  Yes. Basically cheats and anti-cheats became their own thing security-wise and huge amounts of effort are spent (by both sides) on this cat and mouse game. Although both cracking (as in "software cracking") and cheats were very similar security fields back in the day (both boiled down to reverse engineering) cheating has diverged enough (due to modern anti-cheats and anti-piracy becoming very different countermeasures) that I'd consider them vastly different nowadays. Some categories of exploits unique to games: - Aim hacking (pointing the mouse cursor to enemy heads) - Recoil/spread cheats (mouse compensating for weapon recoil or bullet spread) - Botting/botfarming (playing resource-intensive games automatically) - Wallhacking (showing players through walls, or making walls semi transparent) - Miscellaneous passive assistance (like overlaying a predicted path for a ball in a game, drawing precise location for footsteps/other player sounds, etc.) - Modification of game state (like sending your character's position at will, allowing you to fly or go through walls) Some of these have analogues in app security: - Botting detection is probably very similar in both MMOs and CloudFlare) - Hidden information is not very different from what we do in web apps (only send the state that the client needs and has access to) - Preventing game state modification is solved by having a strongly authoritative server (again pretty normal in app land) But even in those, what makes games very unique compared to other apps is that they're hard real time: you have hard requirements for each frame time; it's expensive to calculate in-server all things that a player should be able to see every single frame; packets take time to travel over the internet so you have to give it some slack (or enemies could pop out of nowhere when crossing doors); client sometimes needs information that you'd like to remain private (you need player positions even behind walls to provide 3D sounds)... Modern anticheats usually resort to just scanning the memory for running cheats, trying to detect a cheat reading/modifying the game memory, etc. but cheats have come to great lengths like having actual cheat hardware (DMA devices on PCIe[0]) that cannot be detected since it's running outside of the computer software. [0] https://blog.esea.net/esea-hardware-cheats/ https://blog.esea.net/esea-hardware-cheats/

jerf 3y ago

Others have corrected you about gaming; I would point out that for HFT if you write a memory error, you are reasonably likely to encounter it because of the sheer number of swings of the stick you get at hitting the bug. And if that code's concurrent at all, and it probably is, it had even moreso better get it right. You do not want to discover memory errors at run time. I'd bet HFT has already got all the best static analysis money can buy, not that they're cowboying it more than anybody else. Memory safety isn't just about "security". Sure, that's a huge issue, but it's also about not spending a month debugging why the login fails one out of a thousand logins because the user's password gets replaced by what seems to be a pointer, but one that doesn't point at anything, starting with the 5th character, or why your HFT code should have ordered 10,000 shares but instead ordered a pointer's worth of shares, or why the second level crashes after precisely the 1023rd frame with completely incomprehensible errors, or any number of other things. I do not know why any sane developer that has worked through such a thing even once would be willing to entertain the notion of programming without it if it weren't utterly forced on them. I enjoy reading such tales of diagnostic heroism; I don't enjoy being in them anywhere near as much as some programmers apparently do.