Re: [blink-dev] Re: Intent to Ship: The Popover API

[Mason Freed]

On Wed, Mar 22, 2023 at 8:57 AM Philip Jägenstedt 
wrote:

> LGTM3
>

Thanks for the LGTMs!


> On 3/21/23 3:01 AM, Noam Rosenthal wrote:
>>
>> Thanks for raising this issue. You and I discussed this several months
>>> ago. I think my view is the same as before: using `z-index` and `overflow`
>>> as some kind of security boundary is a bit fragile, and not what those
>>> features were designed to do. There *is* a platform API that *does* have
>>> this behavior as its official contract: ``.
>>>
>>  come with additional constraints. e.g. some of this embedded
>> HTML can position itself in the page (as long as it doesn't go "on top" of
>> other things), and you can't apply global CSS into iframes. There's a
>> reason people use embedded HTML rather than iframes for certain use-cases,
>> and stacking/overflow contexts gives some confidence that the embedded HTML
>> doesn't try to go on top of the embedding UI.
>>
>> That's true,  aren't free, and they do come with additional
constraints. I just meant they are the one platform primitive that actually
explicitly guarantees the contract that contained content can't escape.


> As you mentioned, you already need to use a sanitizer to preserve z-index
>>> boundary, since `dialog.showModal` or `anyElement.requestFullscreen()` or
>>> even `document.body.appendChild()` breaks out of it. And given that
>>> sanitizers are a) required for this use case anyway, b) always require
>>> upkeep to ensure they're filtering the right things, and c) should be using
>>> allowlists or they're already broken, it seems like that's the path forward
>>> for this type of CMS use case, right? Probably the attribute that should be
>>> filtered is `popovertarget`, to avoid the declarative invocation behavior.
>>>
>>
>> Sanitizers are just one way to set a boundary for embedded HTML. The
>> other one is preventing JS using CSP.
>> Looking at the major sanitizers in use today (e.g. Github markdown, Wiki
>> HTML sanitizer) they use allowlists so this would not present a problem for
>> them.
>> I don't think this should be a blocker for this feature (which I'm really
>> excited about!) but I raised it to a wider audience because I think we
>> should stay aware of this issue. We're relaxing a very old constraint here
>> (albeit for good reasons).
>>
>> That's a good point. I don't feel like an opt-in for this behavior is
warranted, given that this isn't really the contract provided by z-index
and top-layer. But I can see the need for an opt-out, similar to CSP for
JS. Would you mind opening a WHATWG/html issue about this, and we can
discuss in more detail there?

Thanks,
Mason


>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbVj4vVX92XaCCP1FQkBE5fjpWrZ2yHe2hz0rt%2BmhORyg%40mail.gmail.com
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/521f60c1-cd6f-fc61-0e36-d7e76dc512da%40chromium.org
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgrBqJnjwHC9w%3DyT5OEJzvc6ztfGcjUR7NSuh-a76VgEg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Philip Jägenstedt]

LGTM3

On Wed, Mar 22, 2023 at 4:52 PM Mike Taylor  wrote:

> LGTM2
> On 3/21/23 3:01 AM, Noam Rosenthal wrote:
>
>
>
> On Mon, Mar 20, 2023 at 8:13 PM Mason Freed  wrote:
>
>> On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal 
>> wrote:
>>
>>> Voicing some concern about this API that I've raised before, and perhaps
>>> I'm reading this wrong and it was addressed.
>>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>>> worked on popups for wikipedia).
>>> This HTML is usually sanitized to remove potentially malicious tags
>>> (

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Mike Taylor]

LGTM2

On 3/21/23 3:01 AM, Noam Rosenthal wrote:



On Mon, Mar 20, 2023 at 8:13 PM Mason Freed  wrote:

On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal
 wrote:

Voicing some concern about this API that I've raised before,
and perhaps I'm reading this wrong and it was addressed.
Think of CMS-style sites that embed user-generated HTML, like
Wikis (I worked on popups for wikipedia).
This HTML is usually sanitized to remove potentially malicious
tags (

[blink-dev] Re: Intent to Ship: The Popover API

[Noam Rosenthal]

On Mon, Mar 20, 2023 at 8:13 PM Mason Freed  wrote:

> On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal 
> wrote:
>
>> Voicing some concern about this API that I've raised before, and perhaps
>> I'm reading this wrong and it was addressed.
>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>> worked on popups for wikipedia).
>> This HTML is usually sanitized to remove potentially malicious tags
>> (

[blink-dev] Re: Intent to Ship: The Popover API

[Mason Freed]

On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal 
wrote:

> Voicing some concern about this API that I've raised before, and perhaps
> I'm reading this wrong and it was addressed.
> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
> worked on popups for wikipedia).
> This HTML is usually sanitized to remove potentially malicious tags
> (

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Noam Rosenthal]

https://github.com/apostrophecms/sanitize-html for example is allow-list by
default but can be configurable to work as a block-list.

This is hypothetically a problem for any new HTML attribute, however with
this particular one we break a very old CSS contract (stacking/overflow
contexts are only esacapable by JS).

On Mon, Mar 20, 2023 at 12:26 PM Philip Jägenstedt 
wrote:

> Hi Noam,
>
> Do you know if these sanitizers generally work as allowlists or
> blocklists? In other words, will the new popover attribute be allowed
> through current versions of those sanitizers?
>
> Best regards,
> Philip
>
> On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
> wrote:
>
>> Voicing some concern about this API that I've raised before, and perhaps
>> I'm reading this wrong and it was addressed.
>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>> worked on popups for wikipedia).
>> This HTML is usually sanitized to remove potentially malicious tags
>> (

Re: [blink-dev] Re: Intent to Ship: The Popover API

['Jake Archibald' via blink-dev]

DOMPurify  seems to block the popover
attribute, and I don't see any code for handling it specifically, so I
assume it's not on an allowlist.

On Mon, Mar 20, 2023 at 10:26 AM Philip Jägenstedt 
wrote:

> Hi Noam,
>
> Do you know if these sanitizers generally work as allowlists or
> blocklists? In other words, will the new popover attribute be allowed
> through current versions of those sanitizers?
>
> Best regards,
> Philip
>
> On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
> wrote:
>
>> Voicing some concern about this API that I've raised before, and perhaps
>> I'm reading this wrong and it was addressed.
>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>> worked on popups for wikipedia).
>> This HTML is usually sanitized to remove potentially malicious tags
>> (

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Philip Jägenstedt]

Hi Noam,

Do you know if these sanitizers generally work as allowlists or blocklists?
In other words, will the new popover attribute be allowed through current
versions of those sanitizers?

Best regards,
Philip

On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
wrote:

> Voicing some concern about this API that I've raised before, and perhaps
> I'm reading this wrong and it was addressed.
> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
> worked on popups for wikipedia).
> This HTML is usually sanitized to remove potentially malicious tags
> (

[blink-dev] Re: Intent to Ship: The Popover API

[Noam Rosenthal]

Voicing some concern about this API that I've raised before, and perhaps 
I'm reading this wrong and it was addressed.
Think of CMS-style sites that embed user-generated HTML, like Wikis (I 
worked on popups for wikipedia).
This HTML is usually sanitized to remove potentially malicious tags 
(