Category: Uncategorized

tl;dr: Migrating old content and infrastructure to TLS is still f’ing hard. If you are using CloudFlare, see “How do I fix the infinite redirect loop error after enabling Flexible SSL with WordPress?“.

After the recent push by many in the standards community to transition our sites to TLS, I decided to move my blog over to TLS. The push is driven the the need to generally try to make the Web more secure + we are trying to move the Web forward by requiring TLS for certain APIs (e.g., Service Workers).

This is not the first time I’ve moved this blog to use TLS.

Early attempt

The first time I did this was a few years ago when I became interested in encryption. During that time, AFAIK, in order to have a SSL certificate you needed to have a static IP address. Furthermore, there was no intermediary services, like StartSSL or CloudFlare, to provide sites with essentially free certificates. Doing the transition to SSL with my host (DreamHost) was fairly straight forward, but quite expensive for me at the time (I was a student or a junior engineer at the time). I don’t recall the exact numbers, but it was effectively something like $25/year for a static IP and then probably something like $50/year for the cert. This on top of the 10/year for the domain + $150 something/year I pay for hosting. Eventually, the cost became a burden to me: only a small handful of people ever visit this site (I don’t know how many as I don’t use analytics our of respect for my visitors) – but I just didn’t feel it was worth the cost so I abandoned it.

This was pre-Snowden, so I was fairly naive to the dragnet activities of the likes of the those assholes at the NSA. I also didn’t understand that, even if your site’s content is harmless, it serves as a data-point in a visitors history. By using TLS, one obscures the navigational trail: they may know you looked at marcosc.com, but not what you were reading. It can help a little.

CloudFlare

More recently, in light of all the bad shit that’s happening in the world, and prompted by Anne van Kesteren, I decided to re-encrypt this site. However, this time around I had a very negative experience trying to transition my personal blog to TLS.

After complaining to Anne about the costs, he pointed me to CloudFlare with the claims about it being free. The setup experience with CloudFlare was pretty straight forward: put a few things into a form and then go and tell DreamHost that the DNS values had changed. No big deal… but then things started to get fun.

Firstly, although my site started working straight away over TLS, I had to wait 4 days for the certificate to actually say it was for “marcosc.com”- during which time browsers accessing my site over HTTPS would see the red warning screen (effectively blocking anyone visiting the site over HTTPS). Thankfully, I had left plain old HTTP access enabled.

Once my certificate was actually granted and working, I decided to disable HTTP altogether. I did this by telling WordPress that this site’s URL was now “https://marcosc.com” – which immediately triggered a cascade of shit. Firstly, the site went into an infinite redirect loop and the whole site became inaccessible. I tried to revert this change in WordPress’ database, but it didn’t seem to help. I then tried to revert various things – but also didn’t work so I just left it be as I had other work to do.

I was offline for about 1 week, then thankfully WordPress issued an update. This seemed to fix things somewhat: at least the site started working again over HTTP. However, switching to HTTPS is still quite broken – the admin section is still completely broken. It won’t load styles because WordPress is too stupid to realize it is running over HTTPS instead of HTTP.

Anyway, and I’m still struggling with various things. Migrating old content and infrastructure to TLS is still hard.

I recently learned through reading Alex Russell’s blog that Google had nominated him as a candidate on the upcoming W3C Technical Architecture Group elections. I thought this was great, as I more often then not find myself in violent agreement with Alex on how browsers should expose their guts to developers (amongst other things). As Alex put it:

I’m running to try to turn the TAG into an organization that has something to say about the important problems facing devs building apps today; particularly how new specs either address or exacerbate those challenges.

I thought it would be great to finally have someone who cares about the challenges that Web developers face represented on the TAG. So it then came to me as a bit of a humbling surprise that I had also been nominated (by Nokia) and asked to run by Robin Berjon. Admittedly, I was hesitant (and I still am) as I don’t know much about the TAG.

To us humble outsiders, the TAG has always been the Ivory Tower of the old guard of the Web: you know, where the guys that started it all pontificate about the nuances of URIs, HTTP Range 14 (don’t worry, I have no idea what the hell that is either!), and the mythical semantic web.

Because of the somewhat obscure range of topics, the TAG’s discussions have been the butt of many jokes on the Web (e.g., the fake tag) and humorous pictures on W3C Memes. It has also become synonymous with architecture astronautism. This is a shame, because, as Alex points out, it could be a force for the greater good, but the interactions with other working groups is generally been limited (and certainly does not appear to be focused on pursuing the issues relevant to Web developers who end up using the stuff coming out of the W3C).

Given the negative perception of the TAG, I basically share Alex’s “goal of turning the TAG into an advocacy organization for the interests of webdevs.” If elected, I want to work with other “reformist-minded candidates” (namely, Anne van Kesteren and Yehuda Katz) towards making that happen.

What and how?

Some proactive things that could be done by the TAG to meet the goal above include:

• Take the discussion to where developers are (Google+, Twitter, GitHub, etc.) – ask them what the TAG should focus on (or make the case to developers to show that there is value in the TAG).
• Talk to developers and find out what their pressing issues are. Do this by attending actual developer conferences and similar forums. See if we can make the TAG something cool and respected again!
• Instead of publishing findings at the W3C, publish findings in the popular developer press (e.g., A List Apart, Smashing magazine, .Net magazine, HTML5 Rocks, or similar) – i.e., where developers can actually read the findings, and in a common voice. Make TAG members available for interviews to media.
• Make time available to talk to developers on a regular (e.g., bi-monthly Q&A sessions on Google+)
• Help developer-based Community Groups (e.g., the RICG and the Extensible Web CG) with navigating the process of adding things to the Web platform.
• Work more closely with WebApps WG, System Apps, HTMLWG/WHATWG to make sure their API designs stay in sync and don’t cause developers unnecessary pain.
• Advocate to W3C Working Groups for more clear specs that meet the needs to developers as well as implementers.

If you have more/better ideas of what could be done to make the TAG more relevant to developers, please let me know in the comments.

How to vote

Unfortunately, voting is W3C member only. But otherwise, you need your AC rep to nominate a candidate (instructions).

What’s my pitch

This is what I submitted to the W3C as my pitch to get votes:

Over the last 6 years, Marcos’ background in interaction design has brought a unique perspective to Web standards. Long before there was the “Native Apps vs Web Apps” debate, Marcos was leading the charge to standardise installable web applications at the W3C through the Widgets family of specifications. Until recently, Marcos worked as a software architect at Opera Software, where he led the team that created Opera Widgets and Extensions platforms. Aside from his work on installable web applications, Marcos has been involved in numerous efforts to bring device APIs to the Web. To the TAG, Marcos can bring hands-on experience dealing with the architectural challenges that come from designing, deploying, and running installable web apps – and how those apps can safely interact with device APIs. For more information about Marcos’ qualifications, please see Marcos at LinkedIn.

The W3C has also published the list of other candidates.

Here is a slightly useless, yet sometimes handy, function if you quickly need to spit out an ordered sequence of unicode characters between a range (e.g., U+007F to U+009F).

/**
 * If you need the string representation, there is a handy
 * 'unicode' property you can query on the returned object.
 * 
 * @param {string} from   is a HEX code you want to start from.
 * @param {string} to   is a HEX code you want to end with.
 * @return {array} the unicode range from - to.
 **/
function unicodeSequence(from, to) {
    'use strict';
    var code,
        index = parseInt(String(from), 16),
        end = parseInt(String(to), 16),
        result = [],
        unicode = '';
    if (isNaN(index) || isNaN(end)) {
      throw new TypeError('Invalid input');
    }
    for (; index <= end; index++) {
      code = index.toString(16).toUpperCase();
      //makes unicode code  like '00AB'
      while (code.length < 4) {
        code = '0' + code;
      }
      //concatenate so we get a unicode string
      result.push('\\u' + code);
      unicode += String.fromCharCode(index);
    }
    Object.defineProperty(result, 'unicode', {
      get: function() {
        return unicode;
      }
    });
    return result;
}

//Example
var r = unicodeSequence('40', '7E');
console.log(String(r.join(', ')));
console.log(r.unicode);

JSFiddle with it

Why?

In a lot of specs (e.g., in HTML), you see unicode ranges that when encountered have particular side effects (e.g., a parse error). In the specs, however, instead of listing out all the values in a range, the editor will just write, for example, “U+007F to U+009F“. So, obviously, when implementing a spec, one needs a way of expanding these ranges.