Re: [w3ctag/design-reviews] Permission Delegation (#225)

@clelland

Thanks @lknik. As @annevk mentioned, this transitivity is a part of the Feature Policy mechanism rather than this (Permission Delegation) proposal. We thought about this issue closely when we designed Feature Policy. From a security boundary standpoint, as soon as the top level site has shared access with the embedded site, what the embedded site does with that capability is almost completely out of the hands of the top level site. We don't have any good way to force the embedded site not to share the capability. For example, if you shared location with example.com, example.com could pass on your location to other parties in any number of ways, including via a fetch/XMLHttpRequest or via postMessage. 

I don't see this as problematic though. When you share your credit card with example.com, you don't have any control over what they do with it or who they share it with. You're making a trust decision to share access and as part of that trust decision you are deciding on the risk of them sharing it on to other parties. You can tell example.com not share your credit card with anyone else but that wouldn't be more than a hint that they can choose to listen to or not. 

I don't see such a hint as useful in this case because it does nothing to hinder or even warn the embedded site about sharing access to the capability in the other ways mentioned above. On the contrary, an attribute actually has the potential to provide a false sense of security if developers believe that it enforces some kind of meaningful privacy constraint on the embedded site. As such, I don't think that we should consider such an attribute at the moment. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/225#issuecomment-362081410