(In reply to Tanvi Vyas[:tanvi] from comment #1) > (In reply to Anne (:annevk) from comment #0) > > 1. Simplification of the UX dialogs to only contain the top-level embedder origin. > I am on board with giving the top level granting rights for permissions - embed.com can't get a permission unless the top-level gives it the right to ask for the permission. But when it does ask, shouldn't we scope it to embed.com? Instead of granting to the permission to any third party in the entire page (and the first party)? Can you explain why granting, say camera access, for the whole page is beneficial? Thanks! The point is that (going by our assumptions) the user makes this choice without considering the URL that's being displayed in the prompt, so effectively any third party or first party could show this prompt, and the user probably wouldn't use the domain name to make a trust decision (which makes sense, let's say you're on a site that wants your location access and the domain in the prompt is "maps-services.com", how do you know it's a malicious site vs. a legitimate service provider). One-off granting really isn't the issue here, as that should still be scoped to the single entity that made the call to access the functionality (i.e. in my idea if the frame calls getUserMedia and gets it granted and if the top-level then call getUserMedia again there's another prompt, though we should probably clarify this). The big problem is what happens if the user clicks on "Remember this decision"? I get your point that we could double-key the permission here. Back when we originally started this project double-keying permissions was actually technically blocked on some work that has now been resolved (and I don't think we expected it to become possible so quickly). So we could do that, on the other hand this then forces us to display *very* complicated UI to the user that needs a lot of explanation (we had troubles explaining iframes, now we need to explain double-keying as well). The goal of this project is to *reduce* the amount and complexity of the UI we have to display, so that makes me very hesitant to go down that route. Again, I think your concern is valid but I would see it as an edge to a large overall improvement.
Bug 1572461 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Tanvi Vyas[:tanvi] from comment #1) > (In reply to Anne (:annevk) from comment #0) > > 1. Simplification of the UX dialogs to only contain the top-level embedder origin. > I am on board with giving the top level granting rights for permissions - embed.com can't get a permission unless the top-level gives it the right to ask for the permission. But when it does ask, shouldn't we scope it to embed.com? Instead of granting to the permission to any third party in the entire page (and the first party)? Can you explain why granting, say camera access, for the whole page is beneficial? Thanks! The point is that (going by our assumptions) the user makes this choice without considering the URL that's being displayed in the prompt, so effectively any third party or first party could show this prompt, and the user probably wouldn't use the domain name to make a trust decision (which makes sense, let's say you're on a site that wants your location access and the domain in the prompt is "maps-services.com", how do you know it's a malicious site vs. a legitimate service provider). One-off granting really isn't the issue here, as that should still be scoped to the single entity that made the call to access the functionality (i.e. in my idea if the frame calls getUserMedia and gets it granted and if the top-level then call getUserMedia again there's another prompt, though we should probably clarify this). The big problem is what happens if the user clicks on "Remember this decision"? I get your point that we could double-key the permission here. Back when we originally started this project double-keying permissions was actually technically blocked on some work that has now been resolved (and I don't think we expected it to become possible so quickly). So we could do that, on the other hand this then forces us to display *very* complicated UI to the user that needs a lot of explanation (we had troubles explaining iframes, now we need to explain double-keying as well). The goal of this project is to *reduce* the amount and complexity of the UI we have to display, so that makes me very hesitant to go down that route. Again, I think your concern is valid but I would see it as an edge case to a large overall improvement.