4 ms·
You can swap out my examples for anything really. The point is the more work the server does, the more data you have to send them to do that work. As far as t
by MrOwnPut 4y ago
You can swap out my examples for anything really.
The point is the more work the server does, the more data you have to send them to do that work.
As far as trusting it's client-side only, opening the network tab in devtools would suffice.
If you think they broke the sandbox (Google would pay millions for that!), yes sniffing would be the next step.
At least you have a sandbox on web, you usually don't have that for native apps.
But that's all better than willingly sending data to another entity's server and trusting them to not abuse/leak it.
- JohnFen 4y agoWith a couple of necessary exceptions, I don't use websites to store or process personal data, so that's not really the use case I have in mind. What I have for native applications that I don't for the web is the ability to firewall off the native applications.
- tiagod 4y ago> What I have for native applications that I don't for the web is the ability to firewall off the native applications. There you're placing trust on the firewall's sandbox. Are you sure the application can't communicate with the outside at all? DNS exfliltration for example?
- JohnFen 4y agoA firewall is not a sandbox, but yes, I am sure that the applications can't communicate with the outside at all. My logs would show if they were. Any and all packets that originate from them are dropped, including DNS lookups and the like.