+rjkroege@, +tsepez@ since I've chatted with them about this kind of thing as well.

I've been poking at these kinds of problems for a little while now and here is my thought:

Unguessable tokens potentially reduce IPCs to establish what a client process is allowed to do, and to validate that a client is allowed to refer to a particular resource. If generally resource IDs are unguessable across IPC boundaries then we can worry a bit less about validating that a client is indeed allowed to refer to a given resource: if it is holding on to a valid ID then it must've gotten it from a privileged process and so it's already been validated to use that resource. WDYT?

> It should also have a secure hash (so that the token can be used as a key in a std::unordered_map for example)

unordered map does not need a secure hash.

I thought that using Nonce rather than "UnguessableToken" would make the class more discoverable. I am however very open to other naming suggestions, especially if there is a fear of "Nonce" being misused.

This is what the code might look like (heavily influenced by cc::SurfaceId and gpu::Mailbox)
https://codereview.chromium.org/2333443002

I want to add a few comments to the review itself before "publishing" it, but feel free to give feedback whenever you want.

It looks good to me.

FWIW I had never heard the word Nonce before SurfaceId used it.. and just assumed it was some one-off thing. :) I wonder how normal that is.

https://en.wikipedia.org/wiki/Cryptographic_nonce

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

commit 4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25
Author: tguilbert <tguilbert@chromium.org>
Date: Mon Sep 19 21:11:25 2016

Add base::UnguessableToken

cc::SurfaceId, gpu::Mailbox and ScopedSurfaceRequestManager need an
unguessable identifier. Security recommends using 128 bits to make sure
an ID is unguessable. However, there is no conveniently serializable
way to represent 128 bits.

This change introduces base::UnguessableToken, a 128 bit class with a
cryptographically strong Create() function. UnguessableToken can be
used by themselves, or as part of an aggregate ID.

An empty UnguessableToken is a valid value. It is however illegal to
send empty UnguessableToken across processes (because the resource that
is supposed to be protected by the token would now be guessable).
Sending empty tokens across processes is a security issue, and should
be handled as such.

This change also introduces the appropriate code to send tokens
over IPC and Mojo. base::Optional should be used in cases where it may
be valid to send no token (rather than sending an empty token).

TEST=Added unittests. Also tested in a prototype that uses IPC and Mojo.
BUG= 643857 

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

[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/base/BUILD.gn
[add] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/base/unguessable_token.cc
[add] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/base/unguessable_token.h
[add] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/base/unguessable_token_unittest.cc
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/ipc/ipc_message_utils.cc
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/ipc/ipc_message_utils.h
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/ipc/ipc_message_utils_unittest.cc
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/common_custom_types.mojom
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/common_custom_types.typemap
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/common_custom_types_struct_traits.cc
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/common_custom_types_struct_traits.h
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/common_custom_types_unittest.cc
[modify] https://crrev.com/4a5ac609f7ea52f2eb69fe871ba6b00c463b9b25/mojo/common/test_common_custom_types.mojom

The work for this bug has been concluded for a while.

As follow up work, I opened 660138 to update gpu::Mailbox, 660127 to update BrokerableAttachement::AttachmentId, and staraz@ (cc'ed) is working on getting LocalFrameId updated.

Thanks everyone!