Inspecting the Content Security Policy of a Website
Starting in Firefox 41, Mozilla provides a developer tool that allows users to inspect the security settings of a website. Using GCLI (Graphic Command Line Interface) a user can inspect the Content Security Policy (CSP) of a website. CSP is a security concept that allows websites to protect themselves against cross-site scripting (XSS) and related attacks. CSP allows website authors to whitelist approved sources from which content can be loaded safely. Browsers enforce that Content Security Policy header and only allow whitelisted resources to be loaded into that website. The CSP inspection tool » security csp lists all whitelisted sources.
The main intention behind CSP is to protect websites against XSS attacks, but the protection needs to be deployed in a way that allows support for legacy code on these sites. For example, the keyword ‘unsafe-inline’ was originally introduced to support legacy inline scripts while transitioning sites to use CSP. This keyword whitelists all inline scripts for a site, but it also allows attacker-injected scripts to execute, making CSP ineffective against most XSS attacks. Hence, the CSP devtool not only lists all whitelisted sources, but also provides a rating for each whitelisted source, to indicate the level of protection.
Inspecting the referrer policy of a website
Starting in Firefox 43, Mozilla exposes more website privacy settings and also allows users to inspect the Referrer Policy » security referrer. The referrer policy allows websites to exercise more control over the browser’s referrer header. Specifically it allows website authors to instruct the browser to strip the referrer completely, reveal it only when navigating within the same origin, etc. The referrer devtool provides an example of what referrer will be used when visiting different websites, allowing the user and developer to inspect what information is sent when following a link.
Inspecting the Content Security Policy as well as the Referrer Policy is only the starting point to providing end users with more feedback about the security and privacy settings a web page uses. We hope to add more tools in the future to give users more transparency and control over the security and privacy of the websites they visit.
Most of you remember the Hello Chrome, it’s Firefox calling! blog post right here in Mozilla Hacks demonstrating WebRTC video chat between Firefox and Chrome. It raised a lot of attention. Since then we here at Fresh Tilled Soil have seen a tremendous amount of startups and companies which have sprung up building products based WebRTC video chat technology. Tsashi Levent-Levi who is a WebRTC evangelist has been interviewing most of these companies on his blog, the list is quite impressive!
WebRTC chat demo
Much like most of early adopters we have been playing around with WebRTC for quite awhile now. We have of course created our own WebRTC video chat demo and have also very recently released WebRTC video chat widgets.
The widgets work very simply, anybody can take the following HTML embed code:
<!-- Begin Fresh Tilled Soil Video Chat Embed Code --><divid="freshtilledsoil_embed_widget"class="video-chat-widget"></div><scriptid="fts"src="http://freshtilledsoil.com/embed/webrtc-v5.js?r=FTS0316-CZ6NqG97"></script><!-- End Fresh Tilled Soil Video Chat Embed Code -->
and add this code to any website or blog post. You’ll see the following widget on their website:
From here it’s dead simple to start a WebRTC video chat, just make up a name for a room, type it in and click start chat. Tell the other person to do the same and you’re all set.
As always make sure you’re giving this a try in Firefox Nightly or the latest stable build of Google Chrome. If you are on a tablet make sure you are on Google Chrome beta if you are using the Google Chrome browser.
Something else to note is that for this first version our video chat is limited to just two participants per a room. If a room name is occupied by two people the third person who tries to connect to this room simply won’t be able to connect.
How It Works
Without getting too deep into the code behind how WebRTC video chat actually works, let’s briefly go over what is actually happening behind the scenes when you click the start chat button and how WebRTC video chat actually works. Here is a step by step timeline of what actually happens to give you a better idea:
A quick note about this step: “Once remote media starts streaming stop adding ICE candidates” – this is a temporary solution which might result in suboptimal media routing for many network topologies. It should only be used until Chrome’s ICE support is fixed.
A quick and very important tip to remember when you are trying to get this to work. We used a ‘polyfill’ like technique as shown in this article by Remy Sharp. As Remy describes we wrote a piece of code to adapt for the Firefox syntax to get cross-browser functionality.
Issues We Ran Into and How We Solved Them
As you might expect we ran into a number of problems and issues trying to build this. WebRTC is evolving quickly so we are working through a number of issues every day. Below are just some of the problems we ran into and how we solved them.
PeerConnection capability in Google Chrome
While working with the new PeerConnection capability in Chrome we discovered a strict order of operation for it to work; more specifically:
Peers must be present with local streaming video before sending SIP (offer/answer SDP)
For ‘Answerer’; Do not add ICE candidate until the peer generates the ‘Answer SDP’
Once remote media starts streaming stop adding ICE candidates
Never create peer connect for answerer until you get the ‘Offer SDP’
We fixed it by handling those issues and handling the connection in the order described above. This was crucial to making the connection work flawlessly. Before we did that it would work only every once in a while.
Added latency due to lag
When streaming to a mobile device there is added latency due to lag and limitations of surfing the net via mobile phone.
We solved this by making the resolution of streamed video reduced via a hash tag at the end of the URL. URL can optionally contain '#res=low' for low resolution stream video & '#res=hd' for HiDefinition streaming video as an optional URL parameter. A quick note here that other configurable properties are now available such as frames per second which you can use for this same purpose.
Recording the WebRTC demo
We’ve been dabbling with recording video WebRTC demo. When recording video we used the new JavaScript type arrays to save the streaming data. We quickly discovered that it is only possible to record the video and audio separately.
We solved this by creating two instances of recording, one for the audio and one for the video, that utilized the new javascript data types and recorded both streams simultaneously.
Conclusion
It’s exciting to dabble in this stuff, we love WebRTC so much that we created an entire page dedicated to our experiments with this technology and others which we believe will transform the web in 2013. If you have any question please give us a shout.
