28 Oct 2015, 09:30

Around the Web - October 2015 - WebAssembly and Google deprecates _escaped_framgent_ urls


Maybe with this topic I should rename the blog post as "beyond the web" due to what is or more precisely will be WebAssembly.

  • On 17th June 2015, Brendan Eich (creator of the Javascript language) announced the WebAssembly project, a common effort with Google Chromium, Mozilla Firefox, Apple Webkit and Microsoft Edge teams, to bring new low level primitives to the web — a move that will make it easier to compile projects written in languages like C & C++ to run in browsers and other JavaScript environments.
  • If you read the long interview of Brendan Eich or look at the use cases, it could mean that heavy applications can be brought into the browser (or any javascript environments) such as Games (like Electronic Arts ones, you know the big ones, really !) or Image/video editor (like Photoshop), etc. You could see your browser as a new target for games, in the same way you have a PS4, a Wi-U, etc versions.
  • WebAssembly is not about to replace Javascript, it's more about to provide a binary format (optimised, etc) than can provide low-level actions for which Javascript is not suitable. WebAssembly and Javascript are to run in the same virtual machine. It's also well describre in this article with some schema.
  • For other languages, firstly c/c++, compilers shoud allow them to build a WebAssembly binary file which will then be used into a browser.
  • Project is still at early stage but some incremental releases are to happen in 2017/2018. In the same way HTML5 was a rolling release, WebAssembly will appear progressively and polyfill will alow to start using it.

Search Engine Optimisation

  • Google deprecated its AJAX crawling scheme and thus, you no longer need to use the "_escaped_fragment_" urls trick. So Google improved the way they can render moder sites and thus index them.

26 Nov 2014, 09:30

Around the Web - November 2014




HTML5/CSS/Responsive Web Design

  • 7 CSS Units you may not know about : rem, vh, vm, vmin, vmax, ex and ch. I did not know the two latter. Some more examples for the vh/vm and vmin/vmax.
  • About rem and em more specially, if you want to move from a fixed approach (ie pixel one) to a more fluid/adaptive one (em/rem), you should read this article  and then this one which explain the issue with pixels and the new way to manage it. You can also use em/rem for positionning content ; em/rem are not only about text.
  • 5 obsolete features in HTML5: hgroups tag, pubdate and scope attributes, command and center elements. With the good way to implement them and/or some workaround if you still need them.
  • RWD adoption 2014 : top 100/1000/10.000 sites are evaluated - from to what extend is RWD implemented to mobile site vs RWD benchmarks in terms of performance.
  • 6 technologies that will change the web platform : asm.js, paralleljs, ECMAScript 6, web components, installable webapps, CSS Grid layout
  • The state of Web Animation 2014 : Between the post-Flash area and the Web Animation API to be implemented in all browsers, a review of current challenges and polyfill to bring animations into the browsers. Comments are also worth to read to get more resources.
  • If you are interested in a book about RWD, seems the latest book from A book apart may interested you : Responsible responsive web design (related review)


Web Performance

  • M6 Tech team made a review of their participation to Velocity conf (day 1, day 2, day 3), a web performance oriented conference. Even if their synthesis is in French, related slides and video are in English. You can also find the one of 2013 (day 1, day 2, day 3)


React (Facebook)

  • React through the ages : an interesting introduction (from origin to what's coming) about React, a JS library to build user interfaces.

05 Feb 2014, 09:30

And your next IDE is the browser

This week, I would not even speak about Cloud 9 or Codio but about Chrome DevTools :

Video is back from May 2013 but below a 20 minutes video from Paul Irish (Google employee) about Chrome DevTools and how it ease your frontend dev tasks. A lot of progress has been done since but with the video and the demo he made, you got the idea.

Mozilla has also its own Firefox DevTools but seems one step behind unfortunately on some points and complementary on some others.

Code-school made a partnership with Google to provide a "Discover DevTools" courses (didn't watch yet but will since I watched this video)

26 Jun 2013, 23:24

Content Security Policy (CSP)

On a similar topic as CORS and the same origin police I wrote some months ago, there is another initiative called Content Security Policy which is defined as follow in the Mozilla Developper Network CSP Page :

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.


The idea behind is that you will "whitelist" the code you accept to render whether it is hosted on third party serivces (like facebook or google buttons) up to inline code within your page (yes, I mean the CSS and JS code you add with the <style> and <script> tags)

What does it look like ?

It's so far only a HTTP Header called "Content-Security-Policy" you will have to set ; for the 1.1 Specs, it will also be a "meta" tags you can set in your HTML.

You will define then the diffrent directives you want to have, depending on your needs :

  • connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
  • font-src specifies the origins that can serve web fonts. Google’s Web Fonts could be enabled via font-src https://themes.googleusercontent.com
  • frame-src lists the origins that can be embedded as frames. For example: frame-src https://youtube.com would enable embedding YouTube videos, but no other origins.
  • img-src defines the origins from which images can be loaded.
  • media-src restricts the origins allowed to deliver video and audio.
  • object-src allows control over Flash and other plugins.
  • script-src lists the origin of scripts that would be loaded
  • style-src is script-src’s counterpart for stylesheets.

Let's see an example :

Content-Security-Policy: script-src 'self' https://apis.google.com

It would mean that :

  • any script loaded from my domain and from https://apis.google.com will be loaded.
  • If you try to load jquery from code.jquery.com in your html, it will not be loaded as this host has not been whitelisted.

Another example to illustrate to what extend you can fine tune this directive :

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; frame-src 'self'

It would mean that :

  • You will not load any code hosted on your domain
  • Script, Style and Image files can only be loaded fomr https://cdn.mybank.net
  • You can connect via Ajax or similar only to https://api.mybank.com/
  • and load frame only from your domain
  • Outside of this rules, all other code/content will never be loaded.

Last one, if you want your site to load all the required files for social widgets (like Facebook, Twiitter, Google ones), the directive would be :

Content-Security-Policy: default-src 'self'; script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Inline CSS / JS Code

Sometime you do have some Javascript / CSS code in your html. Even if you defined "self" as default-src, it will prevent from loading indline JS/CSS code and also prevent "eval()" to be computed.

So the best practice is of course to put your CSS / JS code in external files. However, if you can't, you will have to add the "unsafe-inline" and "unsafe-eval" directives. Of course, it's strongly disrecommended. Indeed, if anyone can inject code in your page, then it will do whatever he wants.

Reporting & Monitoring

Introducing CSP may hurt your site to some extend  as you may forgot to declare some required resources and of course you may be interested to know if someone tries to inject code. CSP also provides some directives for these two needs.

First, for debug purposes, you have the "report-only" directive that would report files to be excluded but will not block them ; you will then use :

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Once you are fine and go in production, you want to know what happens in reality and prevent malicious code to be loaded. Just do as follow :

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

For both cases, once the rule is hit, the browser will POST the information to your report uri and you will have something like :

  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"

Current support in browsers

  • Firefox from Firefox 23 (next stable release) and later. Firefox for Android and Firefox OS soon to follow.
  • Chrome :  25 and later
  • Internet Explorer : 10 and later (sandbox directive only)

How if differs from CORS ?

CORS also aims to mitigate the "same origin policy" issue by allowing which sites can load your content. CSP is the opposite as you would define which hosts you want to load content from and will go deeper as it allows a fine grained control on the loaded/computed code.

I would say CSP it really security focused whereas CORS was more to ease developper tasks to load content from another place.

More resources on CSP

[Edit 1] : An example on how to play safely in sanboxed iframes.

26 Feb 2013, 21:51

Browser : Same Origin Policy & CORS

The same origin policy for Javascript is defined as follow :

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin.

And regarding "origin" : Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. The following table gives examples of origin comparisons to the URL http://store.company.com/dir/page.html:

https://store.company.com/secure.htmlFailureDifferent protocol
http://store.company.com:81/dir/etc.htmlFailureDifferent port
http://news.company.com/dir/other.htmlFailureDifferent host

For security reason, it's obvious to understand that it's not allowed. However, sometimes you may need to interact with data hosted elsewhere in the browser :

  • Display a menu hosted elsewhere (as we do for Globe where the menu is hosted on CMS side but also displayed on DMS side)
  • You may want to aggregate several RSS Feeds coming from different services in a single page, by using some ajax code
  • ...

You can do it by embedding some content from a given domain into another one (like image, video, some scripts, etc) but as soon as you have ajax/ XmlHttpRequest, you are in the same origin policy and you are blocked, till you discover CORS (Cross Origin Ressource Sharing) which provides a way for web servers to support cross-site access controls, which enable secure cross-site data transfers. You can use CORS for :

If from a DomaineA.com you need to fetch data from DomaineB.com, you will then need :

  • On DomaineB.com to add some Access-Control-* headers in your page to define who can safely pull your data
    • Access-Control-Allow-Origin : authorised hosts list or * if you authorise all hosts.
    • Access-Control-Request-Method : Get / Put / Post / Delete
    • Access-Control-Request-Headers : if you want to check against given headers
    • Access-Control-Allow-Credentials : if you want credentials to access your data
    • ...
  • If you don't do this, no way to fetch data from DomaineB.com - your browser will block you when you are on domaineA.com.

Once you enabled cors on client/server side, you can then safely fetch data from domaineB.com in your page hosted in domaineA.com ; nice isn't it ?

The main limitation for me so far is that you can use CORS only if you manage DomaineB server or have contact with domaineB owner, otherwise, you cannot do anything as you will not be granted to fetch data from their servers. Thus alternatives are :

  • Use a reverse proxy on domaineA.com to make the remote resource being seen as a local one to bypass same origin policy and not requiring CORS being enabled (I just did that for a pet project)
  • Go back to a initial backend treatment which will fetch the remote data to alllow you to consume it locally
  • Bypass it with other techniques your favourite language may provide

So even if CORS is a nice idea and a W3C recommendation, seems not mature enough and/or too much complex (unless you can manage the whole chain) to be used effectively on a public side. However for internal projects, it can make sense.

21 Feb 2013, 21:27

Browser : Opera to drop Presto in favor of Webkit

If you follow the web news, you cannot have missed this one : Opera dropped its rendering engine named "Presto" in favor Webkit.

As a reminder :

  • Opera was quite an innovative browser but never met the success they merited
  • Opera is deeply involved in standards implementation (W3C, etc) and will continue.
  • However, Presto, their rendering engine is closed/proprietary
  • Webkit is an open source rendering engine which is used at least in Safari and Chrome (but first of all in KHTML/Konqueror, the browser from the KDE desktop environment - sorry for Apple fanboys, Webkit is not born with Safari). More precisely, Opera will used the Chromium flavor of webkit (Chromium is the open sourced version of Chrome, ie without any proprietary nor licensed plugin)
  • Microsoft's rendering engine is called Trident
  • Mozilla Firefox's rendering engine is called Gecko

Back to the news, it leads to many comment on different topics, I will try to sum up here :

  • Good news, one browser less to test your site on : first, be honest : did you ever test your site on Opera ? So I would say this one is a non event for most of us and then, even if you tested your site on Opera, you will have to wait for the new Opera before giving up tests. As some people said : when you test your sites on IE, it's to get and fix IE bugs. when you test on Opera, you can validate your code against standards as Opera had the stricter implementation of W3C standards. So on this point, we could say that losing Opera is a bad news (however, Opera said that they chose Webkit as standards implementation in webkit is "good enough" for them regarding their criteria on standards).
  • Risk of a new web(kit) monoculture : "Optimised for webkit" could be the new "Optimised for IE6". To some extend, I would say it's already the case as webkit is used massively on mobile world (95% of mobile users are to use a webkit based browser). Fortunately, we can rely on Mozilla at least to promote the Open Web and avoid the "One Webkit reign". More over as there is at least 2 webkits (one on Safari side, one on Chrome side) and mainly as standards is the rule, it looks that "commitment to standards" will remain the rule, whatever the position of the different rendering engine in terms of market share. However, open web and standards are better promoted when there is diversity in rendering engine.
  • Will this swith increase/reduce the innovation on the web  or influence on standards ? J. Resig (JQuery's author) compares JQuery and Webkit ; even JQuery dominates the front-end side of Javascript, it leads to many innovation by providing a shared and common code base accross browsers. It could be the same for browsers and at the same time, he highlights the fact that webkit code base is not as shared between vendors as we may think. On the other side, D. Glazman (implied in CSS Working Group at W3C) mention a sad day and the webkit domination. For some others, the new end is not standard by themselves but standards is a mean for a new end : web as a platform.

Not easy to say what the future will be...

[Edit 1] : Opera's CTO said that Presto could be opensourced, once transition to webkit is achieved. Good news if they could bring some Presto features or standards implementation into Webkit ; their first patches to Webkit was also to fix a 5 yo bug by bringing in Wekbit the support of multi column layout in CSS3. If they go on this way, sounds really good for standards implementation and webkit and I guess Mozilla/Firefox will face the challenge too.

[Edit 2] : To understand the Webkit universe / econsystem : Webkit for developers ie how you will learn that there is no single webkit / all webkit based browsers are not using the same webkit. So as Chromium Team (in charge of the Chromium browser, the Open Sourced version of Chrome) announed they will develop their own rendering engine called Blink ; Opera will also be based on Blink. So Google may/will less contribute to the webkit codebase.

[Edit 3] : a more detailed review in French on the announcement confirming the split between Google teams and webkit ones and also the fact that Samsung & Mozilla to work on a new browser rendering engine for Firefox called Servo (R&D project so far even if Rust (a programming language) is initiated for years and on which Servo will be (partially ?) based, no confirmation of the switch to this new engine for Firefox so far but more for the ARM/Android version, ie for Firefox OS and Firefox Android Browser)

18 Dec 2012, 22:09

Devtools Tips & Tricks

For Chrome users especially, a review of Devtools, ie tools for web development.

It presents some built-in features but also some related extensions to improve debug and track performance issue in particular.

You can also use Chrome to do some remote debug for moblie apps to ease your work.


Use arrows to go back and forth.

15 Nov 2012, 11:22

Want to travel through the universe ?

Web technologies are progressing quite fast and you can do some amazing things with them that you would not think possible some years ago. One of the consequence also is that you can do much more in the browser natively and less and less with Flash.

Latest example : 100.000 Stars to be opened in Google Chrome, in which you can easyly go cross the universe from the Sun to the Milky Way.

Awesome isn't it ?