The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4704a57b1bde5279f8643c2db0b2778430e43e70

commit 4704a57b1bde5279f8643c2db0b2778430e43e70
Author: ryansturm <ryansturm@chromium.org>
Date: Fri Jun 16 17:44:51 2017

Randomizing seed page id for DRP

The seed page id used for DRP should be randomized to avoid collisions
with cached configs.

BUG= 733771 

Review-Url: https://codereview.chromium.org/2940163002
Cr-Commit-Position: refs/heads/master@{#480095}

[modify] https://crrev.com/4704a57b1bde5279f8643c2db0b2778430e43e70/components/data_reduction_proxy/core/browser/data_reduction_proxy_network_delegate_unittest.cc
[modify] https://crrev.com/4704a57b1bde5279f8643c2db0b2778430e43e70/components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options.cc
[modify] https://crrev.com/4704a57b1bde5279f8643c2db0b2778430e43e70/components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options_unittest.cc

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If collisions are your concern, why not use the current time as part of the page id? Random is probably as effective and easier, but thought I should ask.

This change has pretty low impact, so is safe to merge.

buettner: Is this high priority for 60, or is it fine to stay in 61?

bustmante: can you manually review this if buettner says it is high priority?

This can wait until M61. Most of our data has a unique session + page id, so we can filter out case that don't and that should give us enough to go on. 

SGTM. No need to review this bustamante@ I'll remove the merge labels.

In response to bengr@, it's random over a 64 bit uint, so I'm not worried about collisions. I'd be more worried about collisions on a windows device that resets the clock regularly (since the clock has bad granularlity), and I think TimeTicks would have a similar problem on a device that resets the time when it restarts. Either way, I'm not really worried about collisions, and the server team probably isn't too concerned with 1 or 2 collisions that might ever come about with a random number.