search

w3c / picture-in-picture

Picture-in-Picture (PiP)
https://w3c.github.io/picture-in-picture
Other
311 stars 39 forks source link

Add Secure Context #105

Closed beaufortfrancois closed 4 years ago

beaufortfrancois commented 5 years ago

@yoavweiss suggested adding one section for Secure Context that explains why API is not restricted to Secure Context.

Preview | Diff

mikewest commented 5 years ago

@yoavweiss pinged me about this yesterday, @beaufortfrancois this morning. Hi!

The justification in this PR is very weak. Native apps are delivered securely, insofar as they're packaged up, signed, and distributed coherently to the device, without possibility of modification in-flight. The secure contexts spec calls that kind of thing out as something that the agent can consider secure: https://w3c.github.io/webappsec-secure-contexts/#packaged-applications.

IMO, there's a strong presumption in favor of shipping new APIs with secure context restrictions (see https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/, for example).

In this particular case, video is one of the few content types that we allow to be served over plaintext, even on secure pages. We're trying to drive that number down so that we can close the hole in Mixed Content, either by auto-upgrading, or by blocking by default. It would be lovely if we'd stop adding new features to plaintext contexts in support of that effort.

beaufortfrancois commented 4 years ago

@mounirlamouri What's your call?

mounirlamouri commented 4 years ago

This LGTM. I realise that @marcoscaceres suggested to drop the section but I think some folks feel very strongly about everything being limited to secure contexts so I think it makes sense to explain why we did what we did.

marcoscaceres commented 4 years ago

Oh whoopsy, I totally misread it! I thought it was secure context!

Ok, yeah, please just make it SecureContext... if we implement this in Gecko, we will undoubtedly make it SecureContext.

Maybe we can get a second opinion from someone at Apple?

beaufortfrancois commented 4 years ago

@jernoble Do you have an opinion on whether we should restrict Picture-in-Picture Web API to secure contexts only?

mounirlamouri commented 4 years ago

@jernoble Do you have an opinion on whether we should restrict Picture-in-Picture Web API to secure contexts only?

I'm not @jernoble but if Gecko wants to make this Secure Context, it's fine. We could add a note that some UA can do that but the arguments we have in the spec IMO still apply. Last I checked, Safari didn't restrict AirPlay to Secure Context.

marcoscaceres commented 4 years ago

Gecko will go with whatever has consensus amongst implementers, but ultimately we'd like to put new APIs in SecureContexts. If it doesn't hurt site devs, and there is not real strong case to not add it, then I'd really encourage you to add it sooner rather than later 🙏 ... otherwise, it makes a mess later (see Geolocation and Gamepad API).

mounirlamouri commented 4 years ago

Do we think Fullscreen should be limited to secure contexts?

marcoscaceres commented 4 years ago

On the Mozilla side, we'd like to eventually have everything on the platform run in secure contexts. However, how we do that with older APIs, like fullscreen, may require a different approach than simply adding some IDL.

jernoble commented 4 years ago

Yeah, for us, that horse has already left the barn. Picture-in-Picture API works in non-secure contexts, and it's part of the default UA controls for <video> elements, so the feature itself even works for local files, etc. In addition, it's not an especially "powerful feature" that would have additional reasons to gate behind a secure context check.

All that said, an arbitrary element, fully interactive picture-in-picture API would definitely count as a "powerful feature", and for anti-phishing purposes alone should really be gated behind a secure context check. Fullscreen API, too, though that falls into the same caveat of "horse has left the barn".

marcoscaceres commented 4 years ago

and it's part of the default UA controls for <video> elements

I agree that users should be able to access the UA controls irrespective of it being a secure context.

In addition, it's not an especially "powerful feature" that would have additional reasons to gate behind a secure context check.

Agree.