Re: Intent to prototype: Delegate and restrict permission in third party context

I think the main question that needs to be answered here is: "How does that make the situation better?" There is an extensive document from the Chrome team on their motivation,

Re: Intent to prototype: Delegate and restrict permission in third party context

On Wednesday, November 27, 2019 at 7:50:46 PM UTC+1, s.h...@gmail.com wrote: > >Conversely, there would be another attack to link to > >attacker spaces on already-trusted sites (but no top-level) >and get > >silently access too. > That is not silent, because user would have already granted

Re: Intent to prototype: Delegate and restrict permission in third party context

>Conversely, there would be another attack to link to >attacker spaces on already-trusted sites (but no top-level) >and get silently >access too. That is not silent, because user would have already granted permission to that origin to access in previous model. >Besides, if a user granted

Re: Intent to prototype: Delegate and restrict permission in third party context

On Monday, November 25, 2019 at 10:38:28 PM UTC+1, s.h...@gmail.com wrote: > 1. If a user already gave permission to certain origin (e.g. skype.com), and > that origin had HTML injection, does that mean attacker can now silently > inherit permission from skype.com? > > 2. If so, how can a

Re: Intent to prototype: Delegate and restrict permission in third party context

1. If a user already gave permission to certain origin (e.g. skype.com), and that origin had HTML injection, does that mean attacker can now silently inherit permission from skype.com? 2. If so, how can a website mitigate the risk of permission being silently taken to third party website?

Re: Intent to prototype: Delegate and restrict permission in third party context

Hi Thomas, Thank you for pushing feature policy over the finish line and making the web a safer place! Best Nils Ohlmeier > On 25Nov, 2019, at 04:41, Thomas Nguyen wrote: > > Summary: People don’t have a good understanding of iframes, because > generally, no UI indicates that iframes are

Re: Intent to prototype: Delegate and restrict permission in third party context

On Wednesday, November 27, 2019 at 4:55:35 PM UTC+1, s.h...@gmail.com wrote: > How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m > saying the origin is vulnerable to HTML injection, and origin is not > malicious. Thanks, yes, that is a consideration we should care

Re: Intent to prototype: Delegate and restrict permission in third party context

How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m saying the origin is vulnerable to HTML injection, and origin is not malicious. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to prototype: Delegate and restrict permission in third party context

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote: > On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote: > > Summary: People don’t have a good understanding of iframes, because > > generally, no UI indicates that iframes are visible on a page, or what

Re: Intent to prototype: Delegate and restrict permission in third party context

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote: > On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote: > > Summary: People don’t have a good understanding of iframes, because > > generally, no UI indicates that iframes are visible on a page, or what

Re: Intent to prototype: Delegate and restrict permission in third party context

On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote: > Summary: People don’t have a good understanding of iframes, because > generally, no UI indicates that iframes are visible on a page, or what > their origin is. Permission requests from iframes cause significant > confusion