Thanks for Chris Harrelson. Once "should fullscreen be modal?" is resolved, I'll keep progress this. thanks.
2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson님이 작성: > I've also added "should fullscreen be modal?" to the CSSWG agenda. Once > that is resolved this intent is ready to ship, in my view. > > On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson <[email protected]> > wrote: > >> >> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni <[email protected]> >> wrote: >> >>> Hello, >>> It would be nice if there was some repository or documents were we could >>> fill some security/privacy questions. I will do it here instead. >>> How does this interacts with iframes? Do you know where it might be >>> defined in the spec? I remember for the modal dialog, there was some >>> "inertness" attribute propagated toward parent/iframes. It was shown it can >>> be used to leak cross-site data, or it can be used to create new >>> communication channel. It was found and fixed here: >>> https://crbug.com/1293191. I guess the two features relies on the same >>> mechanism and Chrome might immune as result. Anyway, could you please make >>> sure the behavior is specified and show how it doesn't create a cross-site >>> leak? >> >> >> You are correct that the same mechanism prevented cross-site information >> leaks for "both". In other words, thet modal dialog feature doesn't >> propagate, due to the fix for issue 1293191. >> >> :modal is a pseudoclass state that only changes style for a <dialog> >> element in the same document as the style sheet using :modal. Therefore a >> cross-origin iframe won't be able to change its document's state based on >> :modal. So I don't see a way that this feature will introduce new security >> or privacy issues. Let me know if this doesn't fully answer your questions. >> >> >>> Filling the https://w3ctag.github.io/security-questionnaire/ is often >>> helpful as well ;-) >>> >>> On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike Taylor wrote: >>> >>>> On 5/26/22 9:35 AM, Mike Taylor wrote: >>>> >>>> On 5/26/22 2:42 AM, Jihwan Kim wrote: >>>> >>>> >>>> 4. Gecko vendor signal : I set gecko's signal to 'Shipped/Shipping' as >>>> the doc(bit.ly/blink-signals) defines 'Shipped/Shipping' as 'Link to >>>> public documentation or bug/issue'. I'm not sure which signal would be >>>> right if there is an open issue. >>>> >>>> Thank for this feedback - I can see how that is confusing. I updated >>>> the language to say "Link to public documentation or bug/issue that >>>> demonstrates the issue has shipped (i.e., an issue that links to patches >>>> that have been merged, or a comment that a previously disabled feature is >>>> not enabled by default)." >>>> >>>> (this should read "now enabled by default", rather than "not"). 🙈 >>>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f75f277a-11ca-4482-9af0-7764f1241eafn%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f75f277a-11ca-4482-9af0-7764f1241eafn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/293471ff-f32c-4223-b2cd-994d5d018c59n%40chromium.org.
