4 ms·

Without control of the client, it gets much harder to fight abuse.

amatecha 4y ago
If you've ever worked on an online service, you might realize that what you ship for the client is almost irrelevant -- it can all be reverse engineered and an unofficial client can _always_ be created. This happens for all online services, even if it's just someone's data-mining app running on a local machine. The number one rule is "never trust what comes from the client", because it's trivial to create carefully-crafted network calls to basically do whatever the API allows (and sometimes more than what was supposed to be allowed). So, obviously 3rd party clients are thus able to perform malicious acts, but existing laws already forbid this. My suggestion to ensure 3rd party clients are always legally permitted isn't mutually exclusive with existing laws protecting the creators of services and software. :)
- xvector 4y ago
  "Never trust the client" is true, but in practice, some control over the client still helps reduce abuse if you make third party clients a lot harder (eg remote attestation.)
- dangero 4y ago
  You should check out Apple App Attest —- this just isn’t true any more for mobile. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...
  - Matheus28 4y ago
    I haven't read it thoroughly, but given the App Attest service runs on the OS, why can't someone just find the certificate for it hidden somewhere and use that to sign fake attests in userland? This is just an extra layer of obfuscation. It doesn't prevent someone from faking api calls with no app (or phone) involved.
    - btown 4y ago
      Given that this only runs on certain Apple hardware, I wouldn’t be surprised if the Secure Enclave holds that certificate and can confirm at an extremely low level that it is being used only to sign a hash of of the app code itself and a shared secret with the app developer. Brilliant, in a scary way. In a way it makes data portability regulations all the more important.
      - Matheus28 4y ago
        From my quick reading of the docs: It generates a public-private key pair that is stored in the secure enclave, then it sends that public key (or the hash maybe) to Apple for them to sign. The rest of the stuff is as you expect. One could simply figure out how the request to apple is made to get them to sign a key, and that's that. Get them to sign a key and pretend to be the app from now on. I guess this prevents spam from someone signing thousands of keys using a specific phone's serial number, though. Assuming there's an unique public-private key for each phone apple makes, one can't simply get them to sign keys with random serial numbers.
        origin_path 4y ago
        The way these schemes usually work is that the pairing is done at the factory. Apple switch the iPhone on for the first time as it's being made, it generates a private key that never leaves the secure chip and then presents the public key. The public key is then signed to create a certificate chain and the certs handed back to the device for storage. So, there's no way to beat it except by extracting a private key, or by using some software exploit to confuse it into signing the wrong thing.
        Nextgrid 4y ago
        You don't need to extract the private key though, just use it to sign things. So if you have shell access on the phone, you can tell the SE to sign the request you want.
  - a_t48 4y ago
    Does still this work on jailbroken phones where you can let apps modify the memory of other running apps (ala CheatEngine)?
  - d110af5ccf 4y ago
    It isn't true for iOS devices, perhaps. I refuse to run an OS that supports such nonsense. Right now a custom Android rom is sufficient. In the future I expect I'll be moving to one of the Linux distros once they have better support for mobile.
- rootw0rm 4y ago
  back when MechWarrior Online was still pretty new, I reversed the login app (100% .Net, very little obfuscation) which allowed me to access test servers that were testing an unreleased map. Fun times
zeta0134 4y ago
I agree with you, but specifically, I believe it is the user which should have this control. This prevents abuse by the service provider.
CGamesPlay 4y ago
Well, if valid uses for clients are outlawed then the only people buying clients will be the ones trying to abuse the system. So really all the policy does is change the market.
josephcsible 4y ago
Do you also support games using client-side anti-cheat in your OS kernel?
- Matheus28 4y ago
  This seems a bit unrelated but I'll chime in with my opinion. Unfortunately for some types of games (first person shooters), a modified client can be game ruining for other players. For me, as long as it's only running while the client is running, and doesn't send private data remotely, I'm okay with it. At least on Windows there's not much difference in terms of privacy of something running in the kernel vs userland in the same user as your important documents. It can read your entire filesystem and attach to running apps anyway without needing kernel access. So the "in your OS kernel" part is only concerning if their anti-cheat is coded poorly enough to cause a BSoD.
  - LtWorf 4y ago
    All wonderful. Except the anticheat doesn't work and only active moderation stops the game from being ruined.
    - Matheus28 4y ago
      It prevents the more amateurish cheats, which by itself reduces cheating in the community by a lot. Obviously in these kind of games, active policing is the only way to find the most sophisticated cheaters. But the anti-cheat does help.
chaostheory 4y ago
Meta isn't some utility people can't live without. It's optional. If you're worried about abuse, then don't use it.
- yibg 4y ago
  Doesn't meta have an obligation to product users that do want to use their product? This is like saying people should be free to pee wherever they want, if you're worried about the smell, don't walk there.
  - chaostheory 4y ago
    Actually, the pee analogy fits better with your argument. You’re arguing that people can siphon electricity and use meta’s servers without paying (via ads). As I’ve already mentioned, meta isn’t a utility that people can’t live without like a phone. If they don’t like it, they should use something else. There are many alternatives
- jjav 4y ago
  > Meta isn't some utility people can't live without. This is not true for large parts of society. There are many institutions which force you to communicate via facebook, so not having access to it means you're locked out of parts of your real life. This is horribly wrong by those institutions, of course, but here we are. It should be illegal, but isn't yet.
  - chaostheory 4y ago
    Which institutions? if it affected “a large part of society”, I would imagine that I would be aware of it.
    - jjav 4y ago
      Schools tend to be worst offenders, clubs, companies (heard of at least one company which only honors warranty support via facebook!).
deleted 4y ago
[deleted]

If you've ever worked on an online service, you might realize that what you ship for the client is almost irrelevant -- it can all be reverse engineered and an unofficial client can _always_ be created. This happens for all online services, even if it's just someone's data-mining app running on a local machine. The number one rule is "never trust what comes from the client", because it's trivial to create carefully-crafted network calls to basically do whatever the API allows (and sometimes more than what was supposed to be allowed). So, obviously 3rd party clients are thus able to perform malicious acts, but existing laws already forbid this. My suggestion to ensure 3rd party clients are always legally permitted isn't mutually exclusive with existing laws protecting the creators of services and software. :)

xvector 4y ago
"Never trust the client" is true, but in practice, some control over the client still helps reduce abuse if you make third party clients a lot harder (eg remote attestation.)
dangero 4y ago
You should check out Apple App Attest —- this just isn’t true any more for mobile. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...
- Matheus28 4y ago
  I haven't read it thoroughly, but given the App Attest service runs on the OS, why can't someone just find the certificate for it hidden somewhere and use that to sign fake attests in userland? This is just an extra layer of obfuscation. It doesn't prevent someone from faking api calls with no app (or phone) involved.
  - btown 4y ago
    Given that this only runs on certain Apple hardware, I wouldn’t be surprised if the Secure Enclave holds that certificate and can confirm at an extremely low level that it is being used only to sign a hash of of the app code itself and a shared secret with the app developer. Brilliant, in a scary way. In a way it makes data portability regulations all the more important.
    - Matheus28 4y ago
      From my quick reading of the docs: It generates a public-private key pair that is stored in the secure enclave, then it sends that public key (or the hash maybe) to Apple for them to sign. The rest of the stuff is as you expect. One could simply figure out how the request to apple is made to get them to sign a key, and that's that. Get them to sign a key and pretend to be the app from now on. I guess this prevents spam from someone signing thousands of keys using a specific phone's serial number, though. Assuming there's an unique public-private key for each phone apple makes, one can't simply get them to sign keys with random serial numbers.
      - origin_path 4y ago
        The way these schemes usually work is that the pairing is done at the factory. Apple switch the iPhone on for the first time as it's being made, it generates a private key that never leaves the secure chip and then presents the public key. The public key is then signed to create a certificate chain and the certs handed back to the device for storage. So, there's no way to beat it except by extracting a private key, or by using some software exploit to confuse it into signing the wrong thing.
        Nextgrid 4y ago
        You don't need to extract the private key though, just use it to sign things. So if you have shell access on the phone, you can tell the SE to sign the request you want.
- a_t48 4y ago
  Does still this work on jailbroken phones where you can let apps modify the memory of other running apps (ala CheatEngine)?
- d110af5ccf 4y ago
  It isn't true for iOS devices, perhaps. I refuse to run an OS that supports such nonsense. Right now a custom Android rom is sufficient. In the future I expect I'll be moving to one of the Linux distros once they have better support for mobile.
rootw0rm 4y ago
back when MechWarrior Online was still pretty new, I reversed the login app (100% .Net, very little obfuscation) which allowed me to access test servers that were testing an unreleased map. Fun times

zeta0134 4y ago

I agree with you, but specifically, I believe it is the user which should have this control. This prevents abuse by the service provider.

CGamesPlay 4y ago

Well, if valid uses for clients are outlawed then the only people buying clients will be the ones trying to abuse the system. So really all the policy does is change the market.

josephcsible 4y ago

Do you also support games using client-side anti-cheat in your OS kernel?

Matheus28 4y ago
This seems a bit unrelated but I'll chime in with my opinion. Unfortunately for some types of games (first person shooters), a modified client can be game ruining for other players. For me, as long as it's only running while the client is running, and doesn't send private data remotely, I'm okay with it. At least on Windows there's not much difference in terms of privacy of something running in the kernel vs userland in the same user as your important documents. It can read your entire filesystem and attach to running apps anyway without needing kernel access. So the "in your OS kernel" part is only concerning if their anti-cheat is coded poorly enough to cause a BSoD.
- LtWorf 4y ago
  All wonderful. Except the anticheat doesn't work and only active moderation stops the game from being ruined.
  - Matheus28 4y ago
    It prevents the more amateurish cheats, which by itself reduces cheating in the community by a lot. Obviously in these kind of games, active policing is the only way to find the most sophisticated cheaters. But the anti-cheat does help.

chaostheory 4y ago

Meta isn't some utility people can't live without. It's optional. If you're worried about abuse, then don't use it.

yibg 4y ago
Doesn't meta have an obligation to product users that do want to use their product? This is like saying people should be free to pee wherever they want, if you're worried about the smell, don't walk there.
- chaostheory 4y ago
  Actually, the pee analogy fits better with your argument. You’re arguing that people can siphon electricity and use meta’s servers without paying (via ads). As I’ve already mentioned, meta isn’t a utility that people can’t live without like a phone. If they don’t like it, they should use something else. There are many alternatives
jjav 4y ago
> Meta isn't some utility people can't live without. This is not true for large parts of society. There are many institutions which force you to communicate via facebook, so not having access to it means you're locked out of parts of your real life. This is horribly wrong by those institutions, of course, but here we are. It should be illegal, but isn't yet.
- chaostheory 4y ago
  Which institutions? if it affected “a large part of society”, I would imagine that I would be aware of it.
  - jjav 4y ago
    Schools tend to be worst offenders, clubs, companies (heard of at least one company which only honors warranty support via facebook!).

deleted 4y ago

[deleted]