W3C

Security standard open kitchen

Standards are an interesting kitchen, where the technology is discussed, cooked, sampled and finally implemented. It could work in closed loop, between vendors. But our world is turning into a user centric manufacturing house. And standards are no exception. This is why, at the same time specifications are developed at W3C, it’s useful to go in front of web developers and ask ‘hey look at what we are doing, is it to your taste?’

Standing in front of a crowd of Web developers is a great way to test a dish from the Standards kitchen. I will be doing that in October, at a conference I really like, where the audience asks questions and challenges the speakers, at the end of sessions or in corridors or casually around beers. This conference is Paris Web, a two-day francophone conference –followed by a day of practical workshops– that attracts over 1,300 participants around the DNA (major ingredients?) of the Web, with topics such as open standards, Web design, accessibility, UX, quality, etc. I’m particularly happy that for its 10th edition, Paris Web gives a strong focus on privacy and security.

In my talk “Quoi de neuf sous le ciel de la sécurité du web et des internets ?” (“What’s up in the heavens of security for the Web and Internet?”) I will promote the recent work in Web Application Security, Web Cryptography, Privacy, together with security and privacy related activities of the Technical Architecture Group.

I’ll do my best to expose the recent security and privacy achievements, ongoing plans, and developing success of W3C which I recently described in my blog.

  • I am planning to convince the audience that security matters and tell how W3C progresses on that quest.
  • How users could win a decent treatment of their application permission, but also better understand the danger and countermeasure of browser fingerprinting.
  • How web developers could implement security policy based on crypto operations, and create mixed content with less security risk, thanks to the Web Crypto API, CORS and CSP.
  • How important it is to improve user and service provider’s interest by promoting usage of HTTPS.
  • How the next features of the open web platform could be made available in secured context.

I believe that demonstrating that W3C is the right place to think and design the trusted Web is also a good means to increase the value of the work which takes place there, contributed by all W3C members.

I want also to win something else by promoting W3C activities: collect good insight from the French and European community during the conference, and possibly get some of these smart people on-board so that they can contribute to the Working Group. I’m looking forward to answering questions after my talk, listening to the audience challenge our work, and sharing a beer with those passionate men and women, as we’ll toast to Paris Web for it’s 10th anniversary!

One thought on “Security standard open kitchen

  1. Two points.

    is: in the heavens
    should be: under the sky

    What happened to RFC 2817? There seemed to be a consensus that adding TLS (or any other type of encryption) to a protocol (in this case HTTP) doesn’t of itself change the set of resources that may be available using this protocol, nor the semantics of operations which the protocol allows to apply to a given resource, therefore the associated scheme should not vary. The practice of using https: was seen as a wart and the RFC 2817 solution was deemed superior. Then some browser makers started promoting https: and teaching users to look for the letter s as a distinguishing sign of security. After all, it proved inadequate, so they started displaying very clear visual indicators (which could just as well apply in the RFC 2817 scenario, and actually did, as far as I can remember from the last time I visited such page), and now they even hide the scheme (which is annoying because you don’t know what you’re copying to the clipboard, among other reasons). The argument of user perception of security having been dispelled, isn’t it time to return to RFC 2817 approach?

Comments are closed.