[PATCH RFC wayland-protocols] Add secure output protocol

[Nautiyal, Ankit K]

On 11/19/2018 12:51 PM, Simon Ser wrote:
> On Monday, November 19, 2018 4:21 AM, <scott.anderson at collabora.com> wrote:
>> From: Scott Anderson <scott.anderson at collabora.com>
>>
>> This protocol allows a client to ask the compositor to only allow it to
>> be displayed on a "secure" output (e.g. HDCP).
>>
>> This is based on a chromium protocol of the same name [1].
>>
>> This protocol is mostly useful for closed systems, where the client can
>> trust the compositor, such as set-top boxes. This is not a way to
>> implement any kind of Digital Rights Management on desktops. The
>> protocol deliberately doesn't define what a "secure output" is, and the
>> compositor would be free to lie to the client anyway.
>>
>> Signed-off-by: Scott Anderson <scott.anderson at collabora.com>
>>
>> [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
>> ---
>>
>> Intel has proposed a similar protocol as a Weston merge request [2].
>> I believe these two protocols should be compared and merged to try and
>> come up with a general solution that everybody is happy with.
>>
>> While this protocol is currently intended for using HDCP, I don't
>> believe it should be tied to HDCP in any way. If any other similar
>> technology is developed, it would be nice to not need to define a new
>> protocol or modify this one.
Thanks Scott, for going through the proposed protocol [2] which I had 
sent couple of week back, for content-protection support in wayland/weston.
I do agree that some thing from both of the proposed solutions can be 
taken and we get a generalized protocol, provided they provide similar 
support.

The proposed protocol [2] is surely being written with HDCP in mind, but 
does not necessarily tied to HDCP.

There were a couple of discussions on #wayland IRC and mails around this:

https://lists.freedesktop.org/archives/wayland-devel/2018-June/038446.html
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038511.html

In general for any such content-protection, the key things to consider 
here are:

The protection level can be more than one, depending on the 
content-type. Suppose there are categories of contents say - premium, 
deluxe, standard.
that might need different type of protections on the wire. The "premium" 
perhaps can be UHD content, supported on Very high end displays,
;deluxe with HD content, supported on somewhat next level of displays, 
and standard on most displays.

Suppose an application wants to show, the content-with highest 
resolution, but the connected displays do not have sufficient capability 
for "on the wire protection"
it might want to try to show a lower resolution which perhaps can be 
protected with not with the highest protection, but still acceptable 
protection.
Suppose even that is not possible, the client still can try to show some 
content, perhaps even lower resolution, to the unprotected displays.

Bottom line - clients should be able to tell the compositor, what is the 
type of content is, based on that, the level of protection can be chosen 
by the compositor.
In the proposed solution, the names are taken from Type-0 and Type-1 
which come from HDCP specification, but there can be generic names.

>>
>> I don't think it's necessary for the client to know what type of
>> protection the compositor is providingi or if the protection status of
>> an output changes. It's up to the compositor to choose and negotiate
>> what kind of protection is required, and all the client needs to do is
>> trust that the compositor is putting their content on a secure output.
>> Clients should have no control or knowledge of how/where they're
>> presented.

The client does not need to know:
- the protocol used for content-protection
- the individual support each of the connected display provides.

But what it might be interested to know is:
-whether the protection level is reasonable for the content it want to show.
-run time changes in the overall level of protection.
In case of hotunplug of a High end display, supporting, some level of 
security, and hotplug of an unprotected display,
the client needs to know, that the protection status, it can then take a 
call whether to downgrade the content or keep on
showing same content.
The compositor should not be burdened about any policies here.

>> The protocol also should be per wl_surface, instead of any type of
>> global client state. A client can have multiple surfaces, and they could
>> need to be treated differently. For example, one surface may be the
>> protected content which uses this interface, and the other may be a
>> dialog box which could be placed anywhere.
The protection here is display-level.
As per earlier discussions, there might be many displays connected with 
different levels of security.
Since the app surface, should be free to dragged from one display to 
another, there has to be the minimum level of protection
supported by all the displays.
Not sure, how the surfaces can ask for individual levels of protection. 
Perhaps I might be missing something.

Thanks & Regards,
Ankit

[2] https://gitlab.freedesktop.org/wayland/weston/blob/bb546cbbaaf6257ce018e7392747cc0fbdc1639f/protocol/content-protection.xml




>>
>> [2] https://gitlab.freedesktop.org/wayland/weston/blob/bb546cbbaaf6257ce018e7392747cc0fbdc1639f/protocol/content-protection.xml
> Hi,
>
> Thanks for your patch. However, I don't think it belongs to wayland-protocols.
> wayland-protocols isn't designed for all common Wayland protocols. For instance,
> the IVI shell isn't there, and has a similar use-case (although not limited to
> closed systems). Also some other protocols like layer-shell have been rejected.
>
> I think a Weston patch in protocols/ would be better suited. This would allow
> protocol consumers to share the protocol while not including it in a repository
> where it won't be used because a large majority of wayland-protocols users don't
> have closed systems.
>
> That said, wayland-protocols' scope is ill-defined, so it's not like it's easy
> to decide whether it belongs here or not.

Simon Ser, I was initially wondering the same while sending 
merge-request for [2].
I went ahead and added the protocol in weston, to have the client and 
protocol being discussed at one place.

The next question would be, for protocols such as Scott or I have sent, 
where the server should be kept?

>
> Thanks,
>
> --
> Simon Ser
> https://emersion.fr