Father, Hacker (Information Security Professional), Open Source Software Developer, Inventor, and 3D printing enthusiast

  • 2 Posts
  • 110 Comments
Joined 2 years ago
cake
Cake day: June 23rd, 2023

help-circle
  • Hall effect sensor expert here! No, the magnets in the joycons that are used to attach to the display/body of the Switch 2 would not interfere with hall effect analog sticks.

    Two reasons:

    • The magnets are too far away (sensors are usually only sensitive to magnets within 10-12mm directly above/below)
    • The mounting/attachment magnets would be perpendicular to the magnets in the analog sticks (if you imagine the flux lines they wouldn’t cross the sensory boundary).

    Regardless, it would be trivial to place a tiny little piece of ferromagnetic blocking tape wherever necessary to prevent interference.




  • Says the guy that won’t allow Meta Quest developers the same level of access to their own hardware. Example: How would someone develop a 3rd party controller for the Quest VR headsets? You can’t. They haven’t exposed that API (or the cameras fully!).

    They don’t even let you set the clock on your Quest headset! Need to change timezones? Factory Reset













  • It is impossible to do these types of checks on serverside.

    If the client can make a determination as to whether or not to draw a player the server can too (and refuse to send those packets). It’s not impossible, just more computationally intensive and thus, more expensive (on the server side of things).

    Naive way: Render exactly what the player will see on the server. Do this for every client and only send the data to the client if the another player enters the view.

    More intelligent way: Keep track of the position and field of view of each player and do a single calculation to determine if that player can see another. If not, don’t send the packets. It will require some predictions but that’s no different than regular, modern game-specific network programming which already has to do that.

    Servers these days have zillions of cores. It really isn’t too much to ask to dedicate a thread per player to do this kind of thing. It just means that instead of one server being able to handle say, 500 simultaneous players you can only handle say, 100-250 (depending on the demands of your game).

    If your players host their own servers then it’s really no big deal at all! Plenty of cores for their personal matches with their friends or randos from the Internet. If you’re a big company with a game like Fortnite then it’s a huge burden compared to the low-effort system currently in place.



  • Excellent defense: “You sent me the packets revealing where all the other players were. If you didn’t want me to know they were behind walls why did you tell me precisely where they were?”

    Yeah, doing such checks on the server side of things is more computationally intensive but it would solve that problem entirely and you wouldn’t need client-side anti-cheat bullshit anymore.

    The first rule of network programming is never trust the client. How does anti-cheat software work? By trusting the client.


  • Even worse: It’s a compliance nightmare!

    Classified information leaking in this way is a one-off situation that might get an individual in trouble. If someone at a heavily-regulated company uploads the wrong thing though, that can cause major disruptions to commercial services while the regulators investigate. Not just fines or prosecutions after-the-fact!

    Here’s why it’s a big deal: Nearly every organization allows employees to use google.com. That necessitates allowing POSTs to google.com and from a filtering perspective it makes it nearly impossible to prevent. The best you can do is limit the POST size.

    Having said that, search forms in general always pose a 3rd party information disclosure risk but when you enable uploading of entire files instead of just limited text prompts you increase the risk surface by an order of magnitude.