@sonny I feel the need to say that I think dubbing needing network access (a thing that most apps need and have no alternative to) "probably safe" in the first place is a mistake that could be easily resolved without any meaningful reduction in user security by just not considering network access in the safety tile.
• network can be used to talk to services on the host
• network is the only thing needed to scam people, see recent Snap crypto scam events
• some network usage are illegal in certain regions (ex bittorrent)
But more importantly, if we mark it as safe now, that's it, we lose the leverage to ever get something better than broad and uncontrolled network access or encourage apps to work offline first.
Real cryptocurrency apps need at least as much network access as scam ones. Why would telling a user that what they think is a real cryptocurrency app needs to connect to the internet help them to detect that it will scam them?
@sonny I think you are overestimating how much interest most people have in reading a domain name and guessing whether it is safe in order to use an app, rather than clicking through; and the ability of any human to determine whether e.g. d1anzknqnc1kmb.cloudfront.net is a safe domain to talk to. (That's the CDN that served Endless OS images for many years.)
It's an interesting R&D project but I would really like to see some user research on the intended flows to go with it.
@sonny@wjt FWIW the big one (as a snap) first made a connection to a completely legitimate currency api before it did the nefarious stuff. Plus, the later ones were just web wrappers so the actual connections to dodgy places (beyond the host of html and css) came from the web host.
@popey@sonny@wjt Also, presumably a cryptocurrency scam app could steal the user's funds by talking to the same network hosts as a legitimate app would.
How do you distinguish network traffic representing a transaction the user wanted to make from network traffic representing a transaction the user didn't want to make?
@astro I don't know too much about eBPF but in general it's smart for us poor desktop enthusiasts to bet on technologies used by big tech in the server/cloud space 👍
@sonny@astro With bpf cgroup socket egress/ingress filters one can have fine-grained firewall rules. A PoC filter would just do "on/off", and then advance into protocol, port, address filtering (HTTP parsing is not really needed). Interesting would be a portal design that works with unmodified apps by detecting packet drops due to initial policy, and then open a dialog to let a ingress/egress connection through (but the app could also ask upfront (fine/coarse-grained).
@pothos@sonny@astro i wonder if VRF wouldnt be a better fit to tackle the problem than simply an app fw. I.e. i am pretty sure its more about routing than about firewalling. After all it probably should also consider captive portal network state as a separate state for each app. The tool for logging into captive portal stuff should get access to a wlan before other apps get it and such.
I'd really recommend checking what android/chromeos do for this as homework before settling on a model.
@sonny is this going to cover any traversal stuff too? We have a library we started for this but haven't gotten too far with as we have a lot to do ahead of it. But we also need to know things like all ip addresses for the machine and remote addresses too.
@sonny Yeah asking that and like what else with the bridge entail. In other words, is it even possible for Pidgin to get marked as safe as we need to be able to connect to any/all network, plus peers, etc. :)
Add comment