W3C WebRTC Working Group, 14 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WebRTC interim December 14, 2020

Description

December 14 WEBRTC interim meeting

A

We are in the process of starting the recording now we're recording.

B

Okay, this is the december 14th meeting of the emergency working group.

B

Little reminder of the ipr policy we abide by it, and only people on companies that are listed on that page are allowed to make substantive contributions.

B

uh This is the second decembering interim and we're going to talk about get current browsing context, media html, capture, capabilities and testing, and we promise you. This is the last virtual interim of 2020. so enjoy the holidays. um Everybody. I guess that fingers crossed what fingers crossed fingers crossed right, most most fun things you can't do, but do what you can so one last thing um we are looking to complete a doodle poll today for the virtual interim during the week of january 18th to 22nd.

B

Currently the best date looks like uh tuesday january 19th, but if you haven't responded, please do and we'll double check and make sure everyone can make it and close the poll today.

B

Okay, so a little bit about this meeting, the info is up on the wiki and the slides are published there.

B

uh We do need a scribe. uh Can we draft you again, henrik uh sure? Yes, I can do it. Thank you uh and we have the irc channel and we're going to see wiki hey so today. This is the agenda.

B

I think we have slides for everything, except maybe the last two things um so we'll turn it over to alive.

C

Thank you, um my apologies for having over liverpool's uh slides, but uh I won't be reading off of them too much so uh no worries, uh basically, uh I'm talking about uh capturing the current tab, and um I think that there is a new trade-off here between uh security privacy uh of different user journeys.

C

um uh Next, if we think about this, when you uh ask the user to share to choose what they're going to share uh you're, giving them a foot gun, it's very likely that they would occasionally miss click uh and share their own thing with actual human beings with whom they've got uh offline relationships and uh sharing the wrong thing could even uh could jeopardize those relationships for obvious reasons. uh On the other hand, we know that uh next slide. I think that we can skip this one.

C

I think that uh we know what this is about. This particular slide is about, and um so we're going to um we're offering to share this tab instead, which means that the user cannot accidentally share their own thing.

C

The only thing that you can do is you can share the current tab and the benefits are uh significant and obvious, but there are obviously a couple of new dangers in doing that, and the danger is that by allowing any part of the allowing one origin to capture the entire tab, um you allow it to circumvent the origin, isolation to some degree. uh Next slide. Please thank you. So uh we recognize four different risks uh in a page.

C

One of them is when you capture your own things, uh you allowed, you can snoop on the user. So if you present links, then you can see if they're purple, you can sometimes see auto-completion of the user's address or anything else, and that is obviously dangerous. That's danger! Number one danger number two is and three occur when you've got embedding. So when you embed another cross-origin content, you can capture it.

C

That's a problem, and, conversely, when cross-origin is embedded by you and captures you that's also a potential problem, uh and the last one is that if you embed two different things, then they could spy on each other, uh which is kind of um you know the next step of both those directions.

C

uh So next slide please so uh in this slide, which has way too much text, I'm basically saying that hey even if we look at one particular um one particular example of just capturing the color, we won't actually be able to come up with a comprehensive mitigation for this. We will kind of have to go with uh case by case for mitigations of capturing your own tab um of you even capturing yourself and snooping on the user, and so for example.

C

One thing that we could say eventually is to say: uh if there is a capture of the current tab, going on, don't show links as purple ever because this is problematic. uh We could similarly suppress autocompletion and other risky features next slide. Please.

C

Next is if we are embedding a resource and that resource uh captures us or catches them better, uh so there is already a mitigation against this uh display. The capture.

C

It's a feature policy uh and I believe that firefox is the only one that is currently implementing that um and they're the only ones currently implementing that and we're suggesting to implement that and to apply that to get current browsing context media as well as get display media, and that should pretty much solve that issue um next slide, please, uh maybe um just I'm sorry, uh one back. It has just uh occurred to me that maybe some people are less familiar with this uh policy.

C

This policy basically says uh if you don't allow an iframe to capture. If you do not say display capture and given allow list that includes you, then they cannot capture uh so next slide. Please now thanks uh the other way around is uh when you're embedding a frame an iframe or- and there is the question of- does it want to be captured by you? Does it trust you enough?

C

So it can already opt out of being embedded, but when it chose not to be opted out of being embedded, it could be that it did not realize that uh hey. It could also be captured uh and inspected by the embedder. uh So we're suggesting an opt-out mechanism that would allow uh resources to.

C

To opt out of being captured, um I think that this is kind of important for this to be opt out so to by default for things to be capturable, and I understand that this is the less secure model, but I'm afraid that, without going the truth, uh we will end up with the feature never being used uh because it will be prohibitively difficult um if everything on the page.

C

I'm sorry I'm getting a bit of feedback here um if everything on the page- and this could be quite a lot of resources uh if everything needs to opt in to being captured, uh it's very unlikely that uh applications of any significant size would ever be able to capture anything.

C

uh If we just look, for example, at the use case of google, docs or google slides, then they could one day embed wikipedia and even if wikipedia opts into being captured because they think everything's okay, one day, they start using some other service and everything breaks down uh going to be very difficult to maintain next slide. Please.

C

So this is basically what I'm suggesting. Instead, I'm saying we could define a new um permission policy allow capture by embedder, which by default, will say that it's just like the state on the web right now. I allow myself to be captured by anything, but it would also be able to opt out by saying none or saying self or just listing specific, um specific origins that may capture it next slide.

C

Please thank you and the last thing is for one eye frame capturing another. I'm saying that we will just do this transitively. So basically, if I embed two things- and one of them allowed me to capture it- and I allow the other one to capture me, then there is a chain here and we can be. They can capture each other, at least in that one direction, maybe not in the other direction.

C

um That's it uh if anybody would like. I can go into some of the details about any part of this, uh but first maybe there are some thoughts.

D

Quick question on uh this: allow catcher by embedder. Is it for get display media or is it for the new api? Is it for both.

C

I think that it would make more sense about for the new api, although we might want to use it for get display media in the case that the user intentionally chooses the current tab. I think that it makes less sense when it is for a different tab or, of course it would make no sense when you capture the entire window or the entire display, and for similar reasons, I think it doesn't make sense when you capture a different tab.

C

So I I don't think that, for example, that I that it makes sense for me in a tab that uh in quite a different tab to start allowing or disabling the capture by some other tab. I don't think that I can be expected to make intelligent decisions about that. I think here the user would have to make the decision.

E

So um janavar here and I have slides coming up as well, so I can hold my comments a little bit, but I have questions about the.

E

What you call a permissions policy here, which doesn't really sound like a permissions policy, which is it used to be feature policy, but permissions policy has now been limited more to be only for iframes.

F

E

It's they're inherently set by the by the container. So in this case it sounds like you're saying you allow capture by embedder if that was set by the embedder. That would be, you know, kind of useless, so I'm assuming this is set through uh html headers or something different. A different mechanism than permissions policies right http.

C

Headers and yes, and actually when I say permission policy- I just mean it generally. In fact, I want it to be a document policy because of the inheritance model of permission policies uh of um that you can only capture if you're, more restrictive, which could be a bit of a problem.

C

uh So document policy is what I actually mean, but we can also call this uh for, for the time being, a permission policy uh with an http header that you say what can capture you and it would not make sense to specify that on an iframe attribute only on the http headers.

E

Right don't note that document policy is not a w3c standard.

C

Not at the moment, that's true right.

G

um So I guess I understand your motivation for making this an opt-out, but isn't it scary and can't you really do really bad things that people would not expect if you enable that api by default.

C

um Yes, but I would argue that these things are also to something really possible with the display media, because the page can actually.

C

Encourage the user to choose the current tab and can encourage the user to choose a specific other tab. And things like this. So I feel like I'm managing the trade-off here to some degree and I feel like it's better to introduce a somewhat flawed new api than to not introduce one, because I believe that the current state of things is problematic, where the user.

G

C

Very likely to make mistakes.

G

Yeah, let me clarify, I think there are two aspects to security aspects is one is whether to have a dedicated api and the other is the mitigation that document policy provides.

G

I think the dedicated api makes a lot of sense from a user experience, but I think, as has been discussed, it actually reduced the need for social engineering to get to what you need. So the security surface, I think, is bigger than get display media I mean you can maybe do social engineering with get display media, but this one solves a lot of your social engineering issues. If you're the attacker I mean, um and so providing this header as a mitigation, but then making it an opt-out.

G

I think, requires a higher level of convenience than we would have had for get display. Media.

C

C

Sure I'll just um I want to clarify just my previous answer, because I feel that I did not give it well and then I'll turn to my cover view. I think that what I was trying to say is that an opt-in mechanism would just make it to the get it to the point where nobody would use the new feature to the point of making it irrelevant. So I that's my argument here. uh Yes, henrik.

A

um uh A point about this being so I I think I think, there's a weird trade-off here right, because um we're talking about social engineering and you know, get display media, you can't direct the user and- and all that is true, but I think with with get display media the danger of over sharing even on the legitimate websites is quite strong, which means that if you prevent that ability as far as legitimate use websites are concerned, this does seem less risky of over sharing. You know you have two windows open.

A

You only need to share one of them, but you accidentally share two of them. I do think it's a trade-off here, but I I'm interested in um why why? It would be so bad for this um like why? Couldn't it be default to to opt, opt out.

G

uh So let me again clarify my understanding of this difference of the security with get display media. So I agree that this api brings some security benefits by avoiding this oversharing risk, but it creates a new risk which is again removing some of the friction needed to social engineer. For someone to self-own using uh this, uh you know show my own website to myself, which sounds very nucleus per se, um so I guess what I'm saying is.

G

Yes, this api solves one of the risks associated with get display media, but it also removes some of the protection that gets display. Media.

F

G

By making it harder to self-share yourself.

G

And so my point, I guess, is that it's not a zero change of security attack surface, and so we cannot claim that we're not missing making things worse. So it's okay to use an opt-out. I think the argumentation at least needs to be stronger.

G

I haven't done a full depth analysis of the risk, but you could imagine a website that integrates an iframe from a very innocuous. Looking other side that gets taken over by spammers that start to use the fact that the initial site does some script sharing for some reason and then does really bad thing to the end user. Who can figure that that this is a complex attack? So I you know, I have no idea how realistic it is.

G

I don't have even the full flow of permissions and other mitigations that would be in place, but I guess the core of my argument is that.

G

Share this tab, api has a different attack surface and get display media, and so we can't just rely on the existing mitigation or lack thereof of get display media to claim where we are on the same ground.

C

um I at least agree completely and my concern. So if a mechanism can be brought forth, which is um good enough, then I'd be happy. I'm just concerned that an opt-in mechanism would not be usable by any application. That's big enough and that.

C

That embeds too many resources from third parties, because even if at any given moment, everything works and the capture works the moment any one of them starts, embedding something new it breaks. And then you fix that and then somebody else embeds something else. So it would get to the point where nobody would use this new api, at which point they will use, get display media because that's the only alternative and then that's why.

C

I claim that we kind of need to judge the merits of this new api with the less with the lesser security of opt out versus get display media, because I think that's what it's going to boil down to.

F

I I wanted to ask sorry: go on there, you go ahead. I wanted to ask what what failure looked like. So, if you, if you went for um opt-in, what would failure look like from from the point of view of either the user or the developer.

C

The capture will stop immediately. It can either fail completely or just be paused, but it's clear that we cannot allow even a single frame more that could include something that is opted out or not or failed to opt in.

A

I think if, if everything permission wise is on a per iframe basis, at least in my mind, it's on a per rectangle basis. So wouldn't it be quite easy to just censor out the iframe. If it's just you know, remove the rectangle.

C

No so first, I don't think that it needs to be only iframes. It can also be um does not mean you're somewhere on the screen. You could float around any place. So basically, if I had to censor anything, I might be censoring things that move around, maybe even to the point that it actually is obvious what they are, but that's less likely, but, but still I don't think that would be very uh serviceable.

E

So uh jana right here and I agree 100 with dom that uh I think this is a less safe api, not a more safe api. So having this that be a solution to a safety problem, we get display. Media, I think, is a little backwards, because the exact protection that this works around is the limitation what's driving. This is that the site does not get to drive what the user shares as to whether this will sites will use this.

E

I think sites will be highly motivated to use this, so I'm going to present an opt-in mechanism, basically in the following slides, and it touches on some of these answers. So, but I wanted to have this discussion first.

D

I missed part of the discussion, but uh I just wanted to say that, depending on the scope of what what you capture, if it's the whole tab or if it's part of a tab, then you might have different behaviors like if you. If the api is only about the whole tab, then you need the whole tab to be agreed. But if you're only there may be cases where you only only part of the tab, and in that case all the other tabs might not be clean. You you don't care and maybe.

E

Then I originally had a proposal that you would just on a document. You would convert that html to to a mini stream. Basically, but then you have to deal with things that are uh not always visible. Iframes and pages can have large areas that are off-screen and stuff like that. So I actually think uh I've come around to that capturing the top level tab effectively.

E

It's actually safer, because uh this is uh some of the uh things you can do here with uh capturing harvesting user information means that you probably don't want this to happen like in the background tab, because once once the website can figure out the user is not looking at the tab, they can put all kinds of stuff up on the web page on the web page. If it's are in the following slides, so it would be possible for me to run those and we can come back.

E

Yes, please discussing this okay cool, so uh I'm going to present an opt-in mechanism, and I think we also need to talk about the name. I think I get current browsing context. Media is a little long, but anyway, getting ahead of myself here. So I'm calling it get tab media for now, but you can replace it with whatever we end up with, uh and I want to talk about securing it with uh cross-origin and better policy, which is an existing concept. Next slide.

E

So, just to go over the risks again, so the risk here is that you can craft your resources across origin and just a reminder for folks that uh this would actually violate that uh this would actually violate. You can be able to pull in cross-origin images stuff like that. That would only be visible uh on on the users browsers. The users can basically be logged into other sites, and only they would normally be able to see these pictures, but now you're able to capture them across sites.

E

There's some improvements in this area, for instance, we talked about uh same site lacks as a new mitigation, but that's just changing a default and there's still a lot of same site, equals non-use cases out there um that we need to talk about. uh Basically, um where websites are complex. As I said, and you know, you have a lot of arrangements for for images and and videos and browser history form autofill, address credit card info.

E

That kind of stuff will be captured, uh web extensions like lastpass and font, size and other things, and on the right there is my uh over the week I tried to get a bjs account. I was trying to score a playstation 5, but you know that was not successful. It was basically like a twitter, coordinated denial of service attack, uh but yes, so any kind of autofill would be captured next page.

E

So I want to look at the scope here and I think the scope is actually narrower that the the use cases I heard that are highly motivated are highly motivated websites that want this. Basically, the primitive and integrated html capture, and what I found appealing was that they're, both based on stream by self.

E

This is a neat idea from google that google slides streams itself into an ongoing meeting using existing technology like the peer connection and the same thing for recorded meeting uh from a client's perspective, because you include all the web layout and things that would be uh quite performance intensive to do in a canvas and the page needs to only capture itself. So that's simple right: we could just capture the same origin and buy-in is insured from requiring code and a highly motivated target and there's no threat of capture from the outside.

E

But of course, sites aren't simple. So there are tons of edge cases here with iframes and complicated share was visible. There can be css overlapping elements on top of things, and if we wanted to say capture a document, we might actually have to render twice in the browser which is not appealing uh from an implementation point of view. So the proposal a here is basically what ella suggested and I also have a next slide. A proposal b.

E

The only modification here is that uh we could capture the the same area but but basically cropped to the iframe, and that would give sites a finer control, because I've heard rumors that if we go with the first proposal, we're going to be talking about adding cropping apis and everyone to read it. It's a good article kudos to google and it's basically describes cross-origin and better policy, there's a lot of different acronyms there's cross-origin opener policy cores and corp. So I'll try to cover some of them here quickly.

E

The most important one here is the embedder policy, which prevents the document from loading any cross-origin resources that don't explicitly grant the document permission using corporate course. With this feature, you can declare that the document cannot load such resources and they had a great example here: picture with example, with a and b sites, a and b that you can specify a header called a better policy require corp, and once you have that policy of that policy.