Make pipelineIds unguessable

[cbrewster]

Needed for servo/servo#10542.
We need to get webrender updated in Servo before this can be ready along with servo/servo#14283.

---

This change is 

[glennw]

This will need to update the sample/ and replay/ applications in this repository in order to pass CI - you can do that by running cargo build in each of those directories. Once that's done, I'm fine with this change. Let's not merge it until the accompanying Servo changes are reviewed though - to minimize the time when WR master is incompatible with Servo master.

[bors-servo]

☔ The latest upstream changes (presumably #592) made this pull request unmergeable. Please resolve the merge conflicts.

[bors-servo]

☔ The latest upstream changes (presumably #666) made this pull request unmergeable. Please resolve the merge conflicts.

[glennw]

Is this still in progress?

[cbrewster]

@glennw yup! the blocking changes just landed the other day. Should have this rebased soon

[cbrewster]

Rebased. Waiting on review for servo/servo#14283

[bors-servo]

☔ The latest upstream changes (presumably #693) made this pull request unmergeable. Please resolve the merge conflicts.

[jrmuizel]

So Gecko does not need this kind of thing because different processes do not share channels. What's the reason that Servo shares channels? It seems like sharing channels is asking for security trouble.

[cbrewster]

@jrmuizel the issue tracking this reasoning for this change is servo/servo#10542. Separating out the channels was one option; however, we opted for the UUID approach as its much simpler.

cc @asajeffrey

[jrmuizel]

Wouldn't it be simpler to not mix everything together instead of mixing all the messages together and then depending on clients to make it so they can't be spoofed? I'd rather webrender/gecko not take on the complexity of having uuids because of servo.

[pcwalton]

Well, we have out of process iframes in Servo, so we have potentially a lot more processes and channels. So the calculus may be different here than in Gecko, assuming that Gecko uses some sort of UUIDs at the subprocess level (does it?)

It might be worth doing some measurements to see whether using lots of channels actually hurts. I worry about the specter of FD exhaustion…

[glennw]

One option could be to just make the PipelineId in WR an arbitrary 16 byte field. Servo can use a UUID, and Gecko could use whatever arbitrary identifier it chooses to?

[jrmuizel]

So the calculus may be different here than in Gecko, assuming that Gecko uses some sort of UUIDs at the subprocess level (does it?)

Gecko just has a hash table per file descriptor that it's listening on and maps ids that it receives on from that fd to objects. This means that there's no way to spoof ids because they don't share a namespace.

[glennw]

@cbrewster Should we keep this open or close for now? It seems like we probably won't end up having a uuid crate dependency in WR?

[cbrewster]

We can close this for now