There is an additional side effect that should be noted: large report server server.log files.. If the CONNECT on port 5228 is not allowed it could be blocked by the rules pointed out in #2 above. If that is the case, the block reason will be 103. Unfortunately, Web Reporter and CSR do not understand block reason 103 so they will print an error message in the server.log that states as much. This isn't normally a cause for concern but it is in this case due to the sheer amount of requests Chrome can generate in a short amount of time. This will result in very large server.log files on the reporting server for as long as the behavior is occurring.
Here is an example access.log entry (block reason is the last column):
[08/Jul/2014:15:32:37 +1000] "" 10.76.18.8 400"CONNECT mtalk.google.com:5228 HTTP/1.1" "" "-""" 3092 "" "" "103"
Here is an example of the message as seen in a CSR server.log:
2014-07-06 05:42:39,984 WARN [com.mcafee.mesa.logparsing.parsers.util.ParsingUtils]Unmatched block reason number: 103.
I have concerns with opening non-standard ports and I don’t think enterprise IT should rollover and do Google’s bidding when the source of the issue is Google. Organizations should push back and get google to fix the code and architect it’s features so that it can function within normal enterprise constraints.
I think this thread had been mentioned (https://code.google.com/p/chromium/issues/detail?id=373181), individuals managing networks and security should chime in there so that google may respond to the issue and learn to co-exist in corporate networks.