Routing IDs vs. unguessable tokens

[Kentaro Hara]

Hi

Currently we are mixing routing IDs and unguessable tokens in the code base. Recently there were some public and internal discussions about which we should use.

Alexander, Chris, Daniel, Dave, John, Nasko and Haraken discussed offline. Let me summarize the discussion in this public forum:

We all agree that unguessable tokens are better than routing IDs. However, it's hard to staff engs to work on the full conversions at this point due to other high priority projects. Until we staff engs on the full conversion, we follow the rules:

1) Use unguessable tokens only when Blink talks to //content/ via Mojo. Don't proactively replace the rest of code in //content/ yet.
2) Don't expose unguessable tokens outside //content/ and Blink (e.g., //content/public/, //components/, //ui/, //net/). They should keep using routing IDs.
3) RenderFrameHostImpl::FromFrameToken() should just take the frame token and doesn't need render_process_id.

4) Unguessable tokens are expected to be used only as an IPC parameter and to reference another object within the browser process. The explicit passing of unguessable tokens as IPC parameters is expected to be rare (e.g., postMessage, printing, AX).

If you have any concerns / questions, let me know!

--

Kentaro Hara, Tokyo, Japan

[Julie Jeongeun Kim]

Hi Kentaro,
Thanks for sharing.

I'm working on converting printing messages. I have one question related to the token.
Some messages from //components/printing/renderer/print_render_frame_helper.cc are sent to //chrome/browser/printing and handled in //components/printing/browser/print_composite_client.cc.

For example, [1] is sent and handled at [2] and it has RenderFrameHost*. It generates a frame guid[3] with pid and rounding id from RenderFrameHost* and manages several maps.

I thought we could replace the frame guid with the unguessable token such as an embedding token or a frame token since it needs something unique for frames and it doesn't convert to the frame once it has a guid.

After hearing some updates from dcheng@[4] and reading the mail from you, I'm about to go back to the routing id but I think I'm lost.
It doesn't have RenderFrameHost* since it has its own pipe and the routing ID is not unique in the browser side. It doesn't look general to send its process id from the renderer to the browser, either.
If we just send a routing ID through mojo interfaces, how can I make the frame guid in the browser side?
I would appreciate hearing your opinion on this.

[1]https://cs.chromium.org/chromium/src/components/printing/renderer/print_render_frame_helper.cc?l=2486
[2]https://cs.chromium.org/chromium/src/components/printing/browser/print_composite_client.cc?q=print_compo&g=0&l=204
[3]https://cs.chromium.org/chromium/src/components/printing/browser/print_composite_client.cc?l=31
[4]https://bugs.chromium.org/p/chromium/issues/detail?id=1104102

Thanks,
Julie

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxrmmw5Sqc1-%2B9fsXSc3e8Min8ZYEQ8DE8-1PzA0%2BZUeA%40mail.gmail.com.

[Kentaro Hara]

Thanks Julie for asking the question!

After hearing some updates from dcheng@[4] and reading the mail from you, I'm about to go back to the routing id but I think I'm lost.

Correct.

It doesn't look general to send its process id from the renderer to the browser, either.

Correct. The renderer should not send the process ID to the browser because the renderer might be compromised.

It doesn't have RenderFrameHost* since it has its own pipe and the routing ID is not unique in the browser side.

If we just send a routing ID through mojo interfaces, how can I make the frame guid in the browser side?

If PrintingCompositeClient has a per-frame mojo interface, would you help me understand why it does not understand RenderFrameHost it is bound to?

+Daniel Cheng 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/460b4686-6368-39d4-8a56-9983bb7f5d4f%40igalia.com.

[Daniel Cheng]

The printing code is a bit complicated. There are several parts to it:

1. On the renderer side, when we need to print a cross-process subframe, we generate a placeholder in the SkPicture. The placeholder is identified with a content ID [1] which is associated with the frame token.

2. On the browser side, when we receive the request to print the cross-process subframe, we request the actual renderer hosting the frame to print it [2].

3. When we get the print result, we send it to the print compositor. [3] Before we send it to the print compositor, we convert the content info map we received from the renderer (which maps from content ID to RenderFrameProxy frame token") to map from content ID to frame GUID. In order to do this, we use RenderFrameHost::FromPlaceholderToken() to do this lookup to get the corresponding RFH.

4. In the print compositor, content is keyed by "frame GUID". The print compositor uses the map generated in step #3 to substitute the corresponding data for each placeholder with a content ID.

In all of these places, we should know the RFH associated with the print request--we're passing a RenderFrameHost to the handling functions in [2] and [3]. Since a RFH has a RenderProcess (and a process ID associated with it), my understanding is we should still be able to use GenerateFrameGuid(), without requiring the renderer to pass up a process ID.

Daniel

[1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/frame/remote_frame_view.cc;l=317;drc=75b3d3930442a4d7ad895cad013f3089fe7a9e9d?originalUrl=https:%2F%2Fcs.chromium.org%2F

[2] https://source.chromium.org/chromium/chromium/src/+/master:components/printing/browser/print_composite_client.cc;l=185;drc=9a7c42e7b3ce922f16b308e2b295f109b56b9fa2?originalUrl=https:%2F%2Fcs.chromium.org%2F

[3] https://source.chromium.org/chromium/chromium/src/+/master:components/printing/browser/print_composite_client.cc;l=147;drc=9a7c42e7b3ce922f16b308e2b295f109b56b9fa2?originalUrl=https:%2F%2Fcs.chromium.org%2F

[Julie Jeongeun Kim]

Thanks for the reply.

Here are some logs.
It has |preview_ui_|[1][2] to communicate with the browser for the preview. The initial idea was started from [2] to skip passing the preview ID and it has been introduced at[3].
After reading your mail, I'm thinking that I might go back to [3] without its own pipe even thought it should keep passing the preview ID and the request ID, PrintHostMsg_PreviewIds. What do you think?

[1]https://cs.chromium.org/chromium/src/components/printing/renderer/print_render_frame_helper.h?l=459
[2]https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/print_preview/print_preview_ui.h?l=300
[3]https://chromium-review.googlesource.com/c/chromium/src/+/2100547
[4]https://chromium-review.googlesource.com/c/chromium/src/+/2106985

Thanks,

Julie

[Kentaro Hara]

+Daniel Cheng Would you probably answer the question of Julie? I believe you are more familiar with the printing code than me :)

[Daniel Cheng]

Sorry, I lost the replies to this thread...

Julie, I think I'm not entirely sure what problem you're running into, as I'm not very familiar with preview ID and request ID. It may be good to chat on Slack if you're available: I suspect you might know more about parts of the printing code than I do anyway :)

Daniel

[Julie Jeongeun Kim]

Please don't be sorry. I was also hesitating to suggest something or having a discussion. Since it's a bit complicated, as you mentioned. So, I have started to work on the other path to the print manager[1] first as expecting that once I complete conversion to the print manager, I would get a more clear view. I'll ping you when I'm ready.

[1]https://source.chromium.org/chromium/chromium/src/+/master:components/printing/browser/print_manager.cc;l=81

Thanks,

Julie