Wayland content-protection extension

[Pekka Paalanen]

On Thu, 14 Jun 2018 13:09:24 +0200
Arnaud Vrac <rawoul at gmail.com> wrote:

> On Wed, Jun 13, 2018 at 12:34 PM, Nautiyal, Ankit K
> <ankit.k.nautiyal at intel.com> wrote:
> > Hi All,
> >
> > I am working on wayland content-protection protocol extension, to enable
> > content-protection (HDCP1.4, HDCP2.2) in wayland.
> > DRM layer already has support for HDCP1.4 and patches for HDCP2.2 are in
> > review : https://patchwork.freedesktop.org/series/39596/
> >
> > As per the IRC discussion on #wayland about content protection extension for
> > Wayland (yesterday, 12th June 2018) , please find below the agreed points:
> >  
> 
> Hi Ankit,
> 
> Thanks for working on this, overall I agree with your design, which
> provides a first level of security when more advanced output
> protection enforcement is not available. I missed the discussion on
> IRC so I'm sorry if my comments are reduntant.
> 
> I see one problem with this approach of hiding the output state to the
> client: there is no way to choose the content in advance based on the
> output protection capabilities.

Hi,

generally there cannot be in-advance information. Until a window is
actually mapped, the compositor will not know where it will show up as
the scenegraph may change due to the client, other clients, or hotplug,
etc.

It would be a narrow special case compositor that would know
before-hand what the protection for a surface would be.

I have assumed that applications are able to switch the content quality
at runtime to match changes in the protection status. If this is not
the case, the issue needs to be brought up now.

OTOH, an application can always map the window with non-sensitive
content to see what it will get. I don't think that would be a problem
if the system design otherwise guarantees that the protection status
does not change while the window is mapped. However, I don't think we
should make the demand of status not changing in the protocol extension.

> Most content providers have the same
> content available in multiple qualities, and the better qualities will
> be available based on the device and output capabilities.
> 
> Since the client has no way of knowing on which output the video
> surface will be shown, the maximum protection level supported by all
> outputs should be exposed to the client, and the client can then
> determine if it's worth switching to a higher quality, and if there's
> a chance it will be displayed on at least one output.

I'm not sure knowing the chance is possible given how the DRM UAPI for
it has been designed: you will know only after attempting to enable a
specific content type whether you got what you asked for. If you ask
for Type 1 and receive "no", that won't tell you anything about whether
Type 0 would succeed, so the compositor has to try again. I'm told that
HDCP negotiation can take a noticeable amount of time, so I assume
compositors would not want to attempt it speculatively.

At least I am assuming that a compositor would not want to enable HDCP
unless it is actually wanted. If a compositor is enabling maximum
protection at all times, then it would know the chances.

Then again, I suppose if a compositor knows what the protection status
will be, it can send events for it even before mapping the window. I
just don't want to require it, and I would not want to imply that apps
can rely on it.

All this really becomes a question of scope for the protocol extension,
how narrow or wide the use cases will be. If we narrow down the
intended use cases, we could have more restrictions written down in the
specification.

I have a funny thought that normal desktop applications that show
sensitive information like password lists might be able to use this
extension to protect the window content from being leaked to
screenshots or such. Of course, such use cases would need consideration
right now to set the expectations in the protocol introduction
correctly. That use case might well be better served by an extension
explicitly designed for it.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180615/155f65f6/attachment.sig>