webrtcH4cKS: ~ Chrome Screensharing Blues – preparing for getDisplayMedia

Posted by Philipp Hancke on June 14, 2018

Posted in: Technology.

Tagged: Chrome, extension, getDisplayMedia, screenCapture.

What happens when you screen share on a computer that's already sharing your screen

The Chrome Webstore has decided to stop allowing inline installation for Chrome extensions. This has quite an impact on WebRTC applications since screensharing in Chrome currently requires an extension. Will the getDisplayMedia API come to the rescue?

Screensharing in Chrome

When screensharing was introduced in Chrome 33, it required implementation via an extension as a way to address the security concerns. This was better than the previous experience of putting this capability behind a flag which lead to sites asking their users to change that flag… that got those sites an official yikes.

webrtcH4cKS: ~ So your VPN is leaking because of Chrome’s WebRTC…

Posted by Philipp Hancke on April 2, 2018

Posted in: Technology.

Tagged: Chrome, ip leakage, proxy, VPN.

1 comment

Brussel’s Mannneken Pis. Original photo by Flickr user Francisco Antunes (CC BY 2.0)

We have covered the “WebRTC is leaking your IP address” topic a few times, like when I reported what the NY Times was doing and in my WebRTC-Notifier. Periodically this topic comes up now and again in the blogosphere, generally with great shock and horror. This happened again recently, so here is an updated look into this alleged issue.

The recent blog post titled VPN Leak by voidsec highlighting how 19 out of more than 100 VPN services tested “leak” IP addresses via WebRTC is a quite interesting read. Some of the details about WebRTC are not quite correct the results are interesting nonetheless. At is core this is someone who sat down to test a long list of services and their behaviour, one by one. This is not the most exciting research task, but exhaustive studies like this often find something interesting.

webrtcH4cKS: ~ getUserMedia resolutions III – constraints unleashed

Posted by Chad Hart on February 8, 2016

Posted in: Guide.

Tagged: camera, Chrome, Edge, Firefox, getUserMedia, resolutions.

17 comments

Back in October 2013, the relative early days of WebRTC, I set out to get a better understanding of the getUserMedia API and camera constraints in one of my first and most popular posts. I discovered that working with getUserMedia constraints was not all that straight forward. A year later I gave an update after the situation with Chrome was greatly improved, but Firefox at the time effectively only supported a single resolution so constraints were not much help. Specifically, I am interested in understanding what happens when you ask for a specific resolution. You might want to have a specific resolution returned by getUserMedia if you want to match the camera resolution to a specific video area to have a 1 to 1 pixel correlation, in a computer vision application where each pixel represents a distance, or if you are dealing with non-standard video devices.

webrtcH4cKS: ~ Surviving Mandatory HTTPS in Chrome (Xander Dumaine)

Posted by Xander Dumaine on December 17, 2015

Posted in: Guide.

Tagged: Chrome, code, getUserMedia, HTTPS, Walkthrough, xander dumaine.

6 comments

“Only Secure Origins Are Allowed”

– Chrome 47

Chrome 47 now forces secure origins (mostly) with HTTPS. This can be a pain to deal with, but Xander Dumaine is here to help with some guidance. Xander is a Senior Software Engineer who deals with the good and bad of WebRTC for Interactive Intelligence in Raleigh, NC. He is helping maintain simpleWebRTC and organises the Triangle WebRTC Meetup group in that area.

{“editor”: “chad hart“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates.

webrtcH4cKS: ~ OMG WebRTC is tracking me! Or is it?

Posted by Philipp Hancke on November 5, 2015

Posted in: Technology.

Tagged: Brief, Chrome, Philipp Hancke, tracking.

2 comments

There has been more noise about WebRTC making it possible to track users. We have covered some of the nefarious uses of WebRTC and look out for it before. After reading a blog post on this topic covering some allegedly new unaddressed issues a week ago I decided to ignore it after some discussion on the mozilla IRC channel. But this has some up on a the twitter-sphere again and Tsahi said ‘ouch’, here are my thoughts.

Claims

The blog post (available here) makes a number of claims about how certain Chrome behavior makes fingerprinting easier:

webrtcH4cKS: ~ getUserMedia Mirrors and Frame Rates

Posted by Chad Hart on July 8, 2014

Posted in: Guide.

Tagged: canvas, Chrome, fps, frame rate, getUserMedia, mirror, Walkthrough.

1 comment

Let’s have some more fun with getUserMedia by creating a simple mirror application and determining its frame rate.

If your user is going to send their video, it is a general best practice to let them see what they are sending. To do this you simply route the local video stream capture by getUserMedia to a <video> element inside the DOM. That is pretty easy, but the challenge is the video you see is not mirrored. When you are looking at yourself you expect to see a mirrored image. When you don’t it feels off and leads to a poor user experience. Ok, so everyone mirrors their local video, so let’s do that.

webrtcH4cKS: ~ How to use WebRTC and Chrome Extensions to Call a Browser When it is Not Open (Konstantin Goncharuk)

Posted by Chad Hart on April 8, 2014

Posted in: Guide.

Tagged: Chrome, code, DataChannel, extension, PeerJS, Walkthrough.

5 comments

Ring! Sometimes you need an alert to get your attention. Traditional phone systems make this easy – if someone calls you your phone rings. The traditional telephony model assumes the called device is always on an available to ring and this is how it generally works across analog phones, mobiles, VoIP phones, and even desktop calling replacements like Skype. The challenge in the web model is that you can no longer assume the remote device is available to run your program’s ring command. Even if the called party has a browser open, it does not mean they have a tab running your app. This means you need to find some other means of telling the called party to go to your URL. That can be limiting for a lot of apps. Fortunately there are solutions for this.

Chrome

All posts tagged Chrome

webrtcH4cKS: ~ Chrome Screensharing Blues – preparing for getDisplayMedia

Screensharing in Chrome

webrtcH4cKS: ~ So your VPN is leaking because of Chrome’s WebRTC…

webrtcH4cKS: ~ getUserMedia resolutions III – constraints unleashed

webrtcH4cKS: ~ Surviving Mandatory HTTPS in Chrome (Xander Dumaine)

webrtcH4cKS: ~ OMG WebRTC is tracking me! Or is it?

Claims

webrtcH4cKS: ~ getUserMedia Mirrors and Frame Rates

webrtcH4cKS: ~ How to use WebRTC and Chrome Extensions to Call a Browser When it is Not Open (Konstantin Goncharuk)

Search

Categories

Recent Comments

Twittering

New post notifications

RSS Feed

webrtcH4cKS: ~ Chrome Screensharing Blues – preparing for getDisplayMedia

Screensharing in Chrome

webrtcH4cKS: ~ So your VPN is leaking because of Chrome’s WebRTC…

webrtcH4cKS: ~ getUserMedia resolutions III – constraints unleashed

webrtcH4cKS: ~ Surviving Mandatory HTTPS in Chrome (Xander Dumaine)

webrtcH4cKS: ~ OMG WebRTC is tracking me! Or is it?

Claims

webrtcH4cKS: ~ getUserMedia Mirrors and Frame Rates

webrtcH4cKS: ~ How to use WebRTC and Chrome Extensions to Call a Browser When it is Not Open (Konstantin Goncharuk)

Search

Tags

Categories

Recent Comments

Twittering

New post notifications

RSS Feed