Generally, we try to update kRestrictedPorts to match spec updates or failing that, an Intent-to-Remove. 

Feel like security feature than a vulnerability, taking off security queue. Mike, thoughts ?

I do think it's worth adding some metrics here to see how flexible we can be with regard to potentially dangerous ports.

So, isherman@, rkaplaw@, etc: How sad would the metrics team be if I added a histogram with 65k buckets to measure the prevalence of each port's use when loading files? *cough* Two of them, really, to distinguish top-level navigation from subresource loading? :) Can I assume that there might be a better way to get this kind of data?

We have sparse histograms. For a given client, how many different values will they be usually emitting (within a 30 minute period, say)? I assume very few - a single client will only be using a few ports?

And also - across the entire client base - will all ports end up being used, or will it mostly be the same subset? Is this platform dependent?

(Actually opening up the bug)

rkaplow@: Thanks! For all clients, I'd expect the vast, vast majority of values to be either 80 or 443.

Particular clients would likely use a particular set of obscure ports for their own internal applications, etc, but I imagine that each individual user would have a small number of ports recorded.

My intuition is that across the entire client base, we'd see clusters around particular ports (like, Chromium developers might be likely to run Blink's layout tests, which use the ports 8000, 8001, 8080, 8081, 8443, and 8444), but I'd be pretty surprised if we saw every port used.

What are the tradeoffs for sparse histograms that I need to be aware of? It sounds like they might be a reasonable fit, but the overhead worries me a bit from a performance perspective. Naively, we'd be poking this counter once per request, and requests happen a lot.

Sparse histograms are backed by a map, and use locks to guarantee thread-safety.  So, the performance concerns would be primarily around those locks -- if you're not worried about the overhead from locking, then it should be ok.  (I'm actually not sure how much overhead there is from locking...)  You could probably implement some local optimizations to work around this if it's too much overhead -- say, by saving off requests into some temporary data structure, and then periodically flushing that data structure to the histogram.  But, naïvely, I'd hope the overhead is low enough to where you shouldn't need to pull such machinations =)

From the metrics team's perspective, we tend to have two main concerns:
  (1) On a per-client basis, are we going to burn through too much memory to back the histogram?
  (2) Server-side, across all clients, will the histogram be too expensive to work with?

It sounds like we're probably fine for (1), as most clients will encounter only a handful of ports.  We might be okay for (2) as well, though it's hard to be sure ahead of time -- maybe there are clients that run some sort of test setup where they repeatedly connect to random ports.  Then we'd see the full spectrum of ports server-side every day, which would be too much.  You could still report the histogram; we just wouldn't process it in our pipelines, and you'd need to run manual Dremel queries instead.

Is WebSocket also affected?

> maybe there are clients that run some sort of test setup where they repeatedly connect to random ports.  Then we'd see the full spectrum of ports server-side every day, which would be too much

Thinking about this again: we will absolutely see every port used. Maybe every day, albeit in low volumes. Because folks use WebSockets to do port scanning, which is the reason we want to lock down access to specific ports in the first place. :)

Why don't I send you a patch, and we can discuss the implications on the pipelines, etc there in more detail.

> Is WebSocket also affected?

If we add a port to the bad ports list, yes.

I am in favour of blocking the ports.

There will be connections to these ports, and some people will be broken if we block them.

What would the connections-per-user ratio have to be to change our mind about whether or not to block?

I'm adding WebSocket to the components because it's relevant and so that I don't need to triage this issue again. This is not an offer to implement it :-)

Given that metrics for ports doesn't seem workable, is it worth just trying out what blocking 137, 138, and 445 would do and monitor fallout as appropriate? Seems slightly preferable over inaction to me.

We use 137 for NetBios discovery of network attached storage devices on ChromeOS- would this change have any impact on our ability to use netbios? 

I suspect that from privileged APIs none of https://fetch.spec.whatwg.org/#port-blocking are blocked. At least, from the perspective of the standard it only matters what happens with web content.