content/common/media/media_stream_messages.h - Issue 1873293002: Report if video capturing meets output protection requirement.

Side by Side Diff: content/common/media/media_stream_messages.h

Issue 1873293002: Report if video capturing meets output protection requirement. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Addressed comments. Created 4 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« chrome/browser/media/tab_capture_access_handler.h ('K') | « content/browser/renderer_host/media/media_stream_manager.cc ('k') | content/content_renderer.gypi » ('j') | content/renderer/media/secure_display_link_tracker.h » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.	1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 // IPC messages for the media streaming.	5 // IPC messages for the media streaming.

6 // Multiply-included message file, hence no include guard.	6 // Multiply-included message file, hence no include guard.

7	7

8 #include <string>	8 #include <string>

9	9

10 #include "content/common/content_export.h"	10 #include "content/common/content_export.h"

(...skipping 134 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
145 std::string /label/)	145 std::string /label/)

146	146

147 // Subscribe to notifications about changes in the set of media devices.	147 // Subscribe to notifications about changes in the set of media devices.

148 IPC_MESSAGE_CONTROL2(MediaStreamHostMsg_SubscribeToDeviceChangeNotifications,	148 IPC_MESSAGE_CONTROL2(MediaStreamHostMsg_SubscribeToDeviceChangeNotifications,

149 int /* render frame id */,	149 int /* render frame id */,

150 url::Origin /* security origin */)	150 url::Origin /* security origin */)

151	151

152 // Cancel notifications about changes in the set of media devices.	152 // Cancel notifications about changes in the set of media devices.

153 IPC_MESSAGE_CONTROL1(MediaStreamHostMsg_CancelDeviceChangeNotifications,	153 IPC_MESSAGE_CONTROL1(MediaStreamHostMsg_CancelDeviceChangeNotifications,

154 int /* render frame id */)	154 int /* render frame id */)

	155

	156 // Tell the browser process if the video capture is secure (i.e., all

	157 // connected video sinks meet the requirement of output protection.).

	158 IPC_MESSAGE_CONTROL3(MediaStreamHostMsg_SetCapturingLinkSecured,

	159 int, /* session_id */

	160 content::MediaStreamType, /* type */

	161 bool /* is_secure */)
	nasko 2016/05/09 21:33:29 This seems incorrect from threat modelling perspec This seems incorrect from threat modelling perspective. We should not be trusting the renderer process to tell us secure vs non-secure state. Is there no way for the browser process to know this information? miu 2016/05/09 23:09:31 In the general case, you'd be absolutely correct. Show quoted text On 2016/05/09 21:33:29, nasko (slow) wrote: > This seems incorrect from threat modelling perspective. We should not be > trusting the renderer process to tell us secure vs non-secure state. Is there no > way for the browser process to know this information? In the general case, you'd be absolutely correct. However, this is being used for a more specialized purpose: At a high level, we are trying to determine whether protected video content is being screen-captured (e.g., via the chrome.tabCapture API) and then the resulting video stream routed by an extension to insecure links/destinations. The browser process only trusts the "is_secure" value in this IPC message if it's coming from a trusted, whitelisted extension. Extensions run in separate render processes. So it shouldn't be possible, for example, for a user's visit to a malicious web page to compromise a render process running a trusted extension to make it report falsehood in this IPC message. xjz 2016/05/10 00:28:25 Yuri: Thanks for clarifying this! Show quoted text On 2016/05/09 23:09:31, miu wrote: > On 2016/05/09 21:33:29, nasko (slow) wrote: > > This seems incorrect from threat modelling perspective. We should not be > > trusting the renderer process to tell us secure vs non-secure state. Is there > no > > way for the browser process to know this information? > > In the general case, you'd be absolutely correct. However, this is being used > for a more specialized purpose: At a high level, we are trying to determine > whether protected video content is being screen-captured (e.g., via the > chrome.tabCapture API) and then the resulting video stream routed by an > extension to insecure links/destinations. > > The browser process only trusts the "is_secure" value in this IPC message if > it's coming from a trusted, whitelisted extension. Extensions run in separate > render processes. So it shouldn't be possible, for example, for a user's visit > to a malicious web page to compromise a render process running a trusted > extension to make it report falsehood in this IPC message. Yuri: Thanks for clarifying this!
OLD	NEW