Asking a end user if foo.com should be allowed to open a TCP connexion to host:port makes no sense. 99.999% of users can't make an informed decision, and they just want the damn to work so they choose "allow".
Never ask users questions that they can't reasonably answer, ie don't do what android did for a long time (looks like this has been improving since N).
Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993
> Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993
Such prompts are going to be super confusing to the majority of users. What is IMAP? What does secure mean? What's a port?
I don't have a solution; I think it's really difficult and interesting problem. For example, you might think a game shouldn't require any permissions, but then it might need internet access to upload scores, access to your address book to invite your friends to play etc. I can't see any easy solutions how you can check the app isn't using these permissions in a malicious way.
You can't reasonably limit access to a specific host anyway, because DNS allows you to point a hostname to any IP; once you have permission to access a hostname that you control DNS for, you can connect to any arbitrary IP address, including LAN addresses. (You could slightly mitigate that by blocking RFC1918 private addresses and localhost, but then you couldn't build clients to talk to such servers.)
As another alternative, which would allow applications like mail clients, SSH clients, VNC clients, and similar, you could treat Internet connections like the web treats file-pickers today: ask the browser to prompt the user for one, and get handed a connection, without the ability for the site to set the target. Combine that with persistence ("allow the site to connect to this host again in the future without prompting?"), and you could easily connect to the handful of servers a user wanted to connect to. That wouldn't let you build a web-based BitTorrent client or similar, but it'd solve many of the problems people want arbitrary connections for.
Yes, but the "solution" is that you can't convince the browser to talk anything but HTTP. So unless the device is HTTP it will probably ignore your "malformed" request.
It is awful that we can't rely on devices to do proper authentication but that is the state of security today.
Never ask users questions that they can't reasonably answer, ie don't do what android did for a long time (looks like this has been improving since N).
Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993