This is clearly a feature and it's the browsers responsibility to warn the user about use of the camera and microphone, I love this feature and use it the whole time, if anyone didn't want to allow their camera and microphone use on a public instance they should remove permissions or just turn off the camera on Jitsi and they wouldn't have this issue
But... how can CuteCats.com exploit this scenario? In the end the user ends up on https://meet.jit.si, and that's what will be displayed in the user's address bar. Am I missing something?
In basic scenario, cutecats.com just redirects to meet.jit.si, but then user's audio/video is immediately streamed to attacker's chosen conference (which they can record). The address bar shows meet.jit.si, but by then it's too late.
More advanced attack uses the trick explained in the article to open the meet.jit.si tab in background, while keeping cutecats.com in foreground (with window.open and location.href), making it less obvious.
This is clearly a feature and it's the browsers responsibility to warn the user about use of the camera and microphone, I love this feature and use it the whole time, if anyone didn't want to allow their camera and microphone use on a public instance they should remove permissions or just turn off the camera on Jitsi and they wouldn't have this issue
But... how can CuteCats.com exploit this scenario? In the end the user ends up on https://meet.jit.si, and that's what will be displayed in the user's address bar. Am I missing something?
In basic scenario, cutecats.com just redirects to meet.jit.si, but then user's audio/video is immediately streamed to attacker's chosen conference (which they can record). The address bar shows meet.jit.si, but by then it's too late.
More advanced attack uses the trick explained in the article to open the meet.jit.si tab in background, while keeping cutecats.com in foreground (with window.open and location.href), making it less obvious.