I'm anxious about annoying people with pop-ups for requests that, I suspect
in almost every case, will be confusing and for which the correct answer is
No.
Often: http://goat.com wants to contact http://192.168.0.1. Allow?
Sometimes: http://goat.com wants to contact
http://[hargbargleipv6wumble-geeeee:%^/??::)]:8080.
Allow?
Once in a blue moon: https://pebble.com wants to contact
http://watch.localdomain. Allow?
I'm dubious about the comprehensibility of IP addresses, especially IPv6
addresses. One can easily imagine simplifying the origin representation (as
we advocate here:
https://www.chromium.org/Home/chromium-security/enamel#TOC-Presenting-Origins),
but IP addresses will always look "syntaxy" and baffling. In a Yes/No
permission 'dialog' context, muscle memory is likely to kick in where
understanding is missing.
So, how often does the Pebble-like scenario happen in practice? We'll be
able to get telemetry in the abstract, but Chrome at least does not measure
specific origins. So we're going to get an aggregate along the lines of "x%
ignored the dialog; y% said no; z% said yes", and we won't know what
percentage of the time saying Yes had been a good idea or served a real use
case.
So, as long as the mechanism is default-deny — as long as my
instantly-EOL'd router and printer don't opt in — it's safe and I
think/hope we can breathe relatively easy with no permission dialog, just
the CORS preflight. The Pebbles of the world can opt in specifically to
https://pebble.com, and the person updating their watch will be happy.
One can hope the Elasticsearches of the world will think twice before
enabling a clearly-labeled "allow the internet to pummel the person's ES
instance" option. But if they don't, I'm somewhat skeptical that annoying
the person would have helped more than it hurt.