- From: Justin Uberti <juberti@google.com>
- Date: Tue, 26 Nov 2013 16:35:59 -0800
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-1rPKAsgfKNna0aPbwjuiBie=8t_UTw462JnTK5BV8+HA@mail.gmail.com>
The fundamental thing about an app install is that it is a metaphor that is fairly well understood. If you install, say, Skype, you are by that action granting it permission to Do Things On Your Behalf, things that could not be done prior to said install. The screensharing app/extension install is similar, only with the additional benefits of a) the app is still forced to ask the user which window to share and b) a mechanism for revocation, both of which allow detection and punishment of bad actors. I agree completely with Martin that safe-by-design needs to be our goal. For right now, I think the approach mentioned above provides the right balance of functionality and safety, at least until we understand more about how this API will be used. For those arguing for weaker security: given that users routinely turn over their credentials to phishers, how confident are you that all users would click "Cancel" when confronted with some random web page that pops up a screenshare chooser? On Tue, Nov 26, 2013 at 3:57 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > On 26/11/2013 6:52 PM, Martin Thomson wrote: > >> On 26 November 2013 15:46, cowwoc <cowwoc@bbs.darktech.org> wrote: >> >>> If the default is "don't share" (similar to CORS) then I don't think this >>> approach scales. >>> >> If the choice here is between "some sites don't work" and "user's get >> screwed and don't understand why", I think that I know where I stand. >> >> There is a possibility that the default for the top-level frame can be >> made permissive. That's something that might need some extra thought. >> I don't think that you can say that iframes are ever safe to allow. >> > > I'm in favor of that approach (top-level frame is permissive and nested > iframes are not). > > Gili >
Received on Wednesday, 27 November 2013 00:36:47 UTC