It blows my mind that they need to do this with physical phones. I would have thought they could virtualise/emulate everything needed.
Software can detect the hardware it's being run on. I imagine that massive amounts of targeted clicks and views detected from x86, or emulated Android, would trigger fraud alerts.
Additionally, phones are cheap and use a lot less power then the x86 cluster required to replicate that many "individual" users/devices.
On top of that, they pay these people so little that it's cheaper to hire 50 of them for a year than to hire one person to run an operation like that for the same time.
Yeah, I'd think it would be more cost effective to record the API requests the apps send and simulate those. No way the servers can tell the difference (unless they update the API or something).
API requests are usually encrypted with SSL and protected against unauthorised use with something along the lines of a JWT: https://jwt.io/
Breaking through the SSL might be possible, if the developer doesn't pin certificates, but you don't know the secret used to generate the HMAC signature (blue section of that website), then you can't simulate the API request. And the secret shouldn't be sent over a network connection.
You could probably access the secret with enough work, but it would be a lot of work. You'd have to do it separately for each app. And the developer can change the secret whenever they want. The developer will change the secret at the slightest hint of anything like this being used with their app. And possibly also take additional steps to keep it from being accessed (e.g. store it in the Trusted Platform Module or equivalent on Android/iPhone). Even the CIA can't access that - it's mostly intended for payment processing and protecting data on a stolen phone, but there's nothing stopping a weather app from using it to prevent unauthorised access to their API (weather data is very expensive, and often billed per API request).
Running the real app on a real phone though... basically nothing an app developer can do to stop that.
I was thinking more of using a debugger to see the API calls the app is making before SSL, not intercepting them over the network. Getting the secret would be harder but I assume it's stored somewhere in the app or app data and could be extracted. I'd be surprised if social media apps are storing it in the TPM.
I guess it comes down to whether it's easier/cheaper to do all of the above than to just buy a bunch of physical phones.
It blows my mind that they need to do this with physical phones. I would have thought they could virtualise/emulate everything needed.
Software can detect the hardware it's being run on. I imagine that massive amounts of targeted clicks and views detected from x86, or emulated Android, would trigger fraud alerts.
Additionally, phones are cheap and use a lot less power then the x86 cluster required to replicate that many "individual" users/devices.
On top of that, they pay these people so little that it's cheaper to hire 50 of them for a year than to hire one person to run an operation like that for the same time.
Yeah, I'd think it would be more cost effective to record the API requests the apps send and simulate those. No way the servers can tell the difference (unless they update the API or something).
API requests are usually encrypted with SSL and protected against unauthorised use with something along the lines of a JWT: https://jwt.io/
Breaking through the SSL might be possible, if the developer doesn't pin certificates, but you don't know the secret used to generate the HMAC signature (blue section of that website), then you can't simulate the API request. And the secret shouldn't be sent over a network connection.
You could probably access the secret with enough work, but it would be a lot of work. You'd have to do it separately for each app. And the developer can change the secret whenever they want. The developer will change the secret at the slightest hint of anything like this being used with their app. And possibly also take additional steps to keep it from being accessed (e.g. store it in the Trusted Platform Module or equivalent on Android/iPhone). Even the CIA can't access that - it's mostly intended for payment processing and protecting data on a stolen phone, but there's nothing stopping a weather app from using it to prevent unauthorised access to their API (weather data is very expensive, and often billed per API request).
Running the real app on a real phone though... basically nothing an app developer can do to stop that.
I was thinking more of using a debugger to see the API calls the app is making before SSL, not intercepting them over the network. Getting the secret would be harder but I assume it's stored somewhere in the app or app data and could be extracted. I'd be surprised if social media apps are storing it in the TPM.
I guess it comes down to whether it's easier/cheaper to do all of the above than to just buy a bunch of physical phones.
Someone get that guy a better chair
I don’t support what he does, but he should at least do it ergonomically.
He could start by raising that seat a bit or he's gonna get carpal tunnel before he get a strand of grey hair.
If it's like my seat, the gas seal is probably stuffed. I should probably fix it but I just treat it as a reminder to stand up.
Dude's gonna have praying mantis arms
Pretty well lit for a shadowy place.
But holy shit those ergonomics. The desk is at their shoulders...
This hits too close to home.