HTTPS by default

18 June 2010

So, my website at jeremy.visser.name is now SSL–enabled, and I am in the process of updating links and images to use the correct https:// scheme.

Why? Because Stephen Conroy’s dunderheaded attempts to encroach on our relatively open Internet will require ISPs to sniff HTTP traffic on IP addresses that happen to fall on the ACMA blacklist. Because the blacklist is secret and subject to change without notice, my US–based Linode could have all its HTTP traffic sniffed on a whim.

Aside from the Australian Government creating a root CA and getting that included in major browsers (like what the Chinese did), it is not possible for them to sniff SSL–encrypted traffic to my site. So, to improve the privacy rights of my readers, those who use my code, and myself, all pages and bzr repositories available on the jeremy.visser.name domain are now HTTPS–enabled.

GoDaddy have an free SSL certificate scheme for open source projects. Because I write a lot about my open source goings-on, and host code on this site, I wondered if I would be eligible for the scheme. Turns out my request was a little unorthodox, and their identity verification system wasn’t properly equipped to deal with third-level registrations on the .name domain, but after some consideration they went ahead and provided me with a free SSL certificate. Thanks, GoDaddy!

I should mention that I am using TLS-SNI to serve the HTTPS version of this site, which means if you are using Internet Explorer, Chrome or Safari on Windows XP, you will get certificate errors. Sorry — nothing I can do about that, unfortunately. Also, I have been told Safari users on Mac OS X are getting certificate errors. Sorry about that, but the certificate is trusted on every other TLS-SNI supporting browser I have tested it on, so not sure what’s going on there.

I’m not redirecting users from the HTTP to HTTPS version just yet for two reasons: (1) I’m not sure what the best approach with regards to Google juice is, and (2) in case users cannot access the HTTPS version, they can still force the HTTP version. I’ll probably start redirecting in the near future though.

Paranoid? Maybe. Far-fetched? Definitely not.

Multicast versus IPTV

24 February 2010

I’ve been hearing a lot of buzz about IPTV lately. It’s something that is exciting, useful, and inevitable.

As I understand it, IPTV is defined to be a live television service delivered over multicast (usually RTP) over a broadband Internet connection. Multicast has an advantage over normal traffic (“unicast”) because it avoids the duplication of traffic. Only one copy of the data is ever sent.

TPG currently offer 19 channels over an IPTV service, and TransACT allegedly offer over 50. iiNet is “on the brink of IPTV launch”. There are rumours that Internode are investigating something similar too.

That last paragraph should have triggered alarm bells in your head. It did for me, but maybe I’m just a cynic. Let me explain.

I asked myself: why are the ISPs providing the IPTV service? It sounds wrong to me. I’ve tried to come up with an answer, and my conclusion is that it is because of two reasons: (1) infrastructure (multicast is virtually non-existant in most production networks) and (2) content lock-in.

Having the ISPs provide the infrastructure for the IPTV service (marketing, encoding, distribution, etc.) means the ISP will likely sign a contract to exclusive usage rights with the TV partner for each channel they will provide. If iiNet sign an exclusive deal with Sky News, they sure as heck ain’t going to let Internode or TPG also put the content on their networks.

The infrastructure would also be duplicated. Each ISP needs their own TV receiving equipment (likely a few satellite dishes on top of their data centre), encoding equipment, marketing, private IP multicast network, and whatnot.

With regards to content lock-in, this will also mean that the ISP you choose to use will determine what IPTV channels you are able to watch. Conversely, what IPTV channels you want to watch will determine which ISP you will sign up with.

That sounds all rosy, until you consider that I am not restricted on what websites I can visit based on what ISP I am with. I can watch YouTube or ABC iView from any ISP in Australia. Sure, some ISPs offer better services than others, faster speeds, or more reliable connections, but it’s just the one Internet. This is because the ISP is not in the content provider role. They are merely the gateway to the Internet — the Internet service provider (now where have I heard that term before?).

The way IPTV looks like it is heading is shifting the ISP onto the content provider role. As I’ve already said, this means the service is delivered over the ISP’s private network, available exclusive to that ISP’s customers, and not over the Internet. That’s a Bad Thing™ in terms of net neutrality.

If an ISP “rebroadcasts” content from an IPTV channel that another ISP has signed an exclusive deal on, that would be a copyright violation.

But that still doesn’t explain the title of my post: “Multicast versus IPTV”. The above isn’t actually the crux of what I wanted to get at (apologies to the reader if you’ve managed to read this far in great detail).

I’m supportive of multicast in general. Combined with IPv6 (each /64 subnet has a corresponding multicast subnet), multicast opens up the doorway for anybody to serve high definition audio and video to the Internet at large without the need for exorbitant amounts of bandwidth up their sleeve.

But that’s public multicast. These “IPTV” solutions will be, and currently are, deployed on private multicast networks. On the plus site, private multicast networks mean it is easier for the ISP to deploy the infrastructure — it’s much easier to only have to worry about your own network, than also have to worry about interfacing with others. But it also means less incentive to deploy a public multicast infrastructure, and less incentive for content providers (such as TV networks) to provide their services over multicast themselves. It’s a chicken-and-egg problem.

We don’t need ISPs to “provide IPTV services”. We need a decent multicast network (preferably IPv6) that all Australians can access, so that TV stations themselves can provide the multicast streams with the knowledge that a large percentage of Internet subscribers are able to access their content, and that channel availability discrimination does not occur based on what ISP you choose to sign up with.

That’s the crux of what I’m getting at. I’m sure someone will come along and say “but but but…they have a right to sign exclusive contracts and deliver only over private networks”. My response to that would be that just because you have the right, doesn’t make it right. Nor left. :)

Thoughts?

Jazzed up URL bar in Google

17 November 2009

Today, I noticed while I was using Google today (which is a website some of you may of heard of), and I noticed they jazzed up where the URL is normally listed:

I don’t know whether to puke or have a seizure. I liked having the URL there. But then again, the URL is meaningless to 99% of users, because people like to put their head in the sand and create absolutely useless URLs. I’m looking at you, Dell and HP. And a whole lot more.

So yeah, probably a usability improvement. And you can click on the little segments. Personally I don’t like it, but that’s ’cause I’m a power user that looks at URLs. And if I really want to, I can always just hover over the link to get the URL anyway.

I wonder how it works. XML Sitemaps, maybe?

Update: Google has written about it. Looks like they analyse anything that looks like breadcrumbs. Too bad it’s not standardised, and they don’t actually tell you how to do it.

Musings on copyright dates

3 January 2009

In the context of a blog, with lots of posts from different years, how would copyright apply? Would each post on the blog have a separate copyright? Or would the blog have a copyright as a whole? Or is it up to the author how it should work?

Say I added a footer to the bottom of my blog in the year 2005, which reads:

Copyright © 2005 by Jeremy Visser. All rights reserved.

(Please note that the copyright notices in this post are purely for discussion and illustrative purposes, and are not intended to state the true copyrighted nature of any of the content on this website.)

Now, it’s the year 2009, so there seems to be two popular ways to update this kind of line:

  1. Copyright © 2005-2009 by Jeremy Visser. All rights reserved.
  2. Copyright © 2009 by Jeremy Visser. All rights reserved.

So in the latter one, the copyright date is simply bumped up to 2009. Is it legal to arbitrarily bump the copyright expiration date like that without formal renewal?

In Australia, this is not a problem, as copyright expires 70 years after the author’s death — it has nothing to do with the publication date. In which case, it does not make sense to add a year to copyright declarations of Australian works. I think the following would do fine for me:

Copyright © by Jeremy Visser. All rights reserved.

It would then be up to somebody to look up the date of my death to find out if any of my works are in the public domain.

So why do we add dates to copyright notices? In the United States, the case is the same as Australia — copyright expires 70 years after the death of an author.

I could not find any information on how copyright expiration applies to a corporation in Australia (after all, a corporation cannot die), but in the United States, copyright on a work produced by somebody as part of their official duties while working for a corporation expires 95 years after publication or 120 years after creation (whichever is shorter). In this case, adding dates to copyright notices does make sense.

So, it seems to me that the reason we all add dates to our copyright notices is because we are all sheep and simply copy each others’ copyright notices. Ironic, eh?