Web Views: about embedded web-view display

[imsenyu]

#41
In the case of non‑fullscreen embedded web‑views (e.g., cards in conversation flow),
the corresponding interface elements should also be adapted specifically.

As mentioned in 0318 Pacific Breakouts, for third-party provided non-full-screen embedded WebViews, such as a rich-card displayed within an embedded WebView in a chat conversation, should relevant information (such as domain origin or permission indicators) be displayed within the embedded WebView's own content?

@jyasskin : For browser-embedded iframes, it's no.

[bkardell]

Trying to think through this, I wonder if it matters which kinds of interface elements you have in mind, particularly...?

[jyasskin]

If it's permission- or security-related UI, like the URL bar, the UA needs to ensure the user gets accurate information, even if the content in the embedded WebView wants to trick the user. If the user is being asked to make decisions about whether to grant permissions to that embedded content, I agree with your PR that the "interface element which identifies the embedded content" needs to be adapted so that users understand it to apply to the specific WebView that it's about. That interface element can't just be at the top level of the outer UA, since users won't understand what it's referring to. It might be safe to have it overlay the WebView's content as long as the UA can guarantee it's shown, and as long as content can't gain anything by drawing (spoofing) a custom version of that element.

Are there other kinds of interface elements, whose purpose isn't to let users protect their privacy or security? Perhaps those could be provided by the WebView's content...