Updated Python-iView: iView v359, no GTK+ for iview-cli, and bonus CGI script

16 July 2010

I have updated Python-iView to un-break changes the ABC made to iView the other day.

If you’re using the Python-iView PPA, then you should have the update available already. If you’re using Bzr, as always, type the following to get the latest update:

$ bzr pull

Changes in this release include:

  • Supports iView version 359. The changes were trivial, but broke compatibility.
  • Remove dependence on PyGTK for iview-cli, meaning you don’t need GTK+ installed to use it. This also means warnings aren’t thrown if you run it on a headless system.
  • As a free bonus, for you hackers out there, I have thrown in a script called iview.cgi. To use it, read the (simplistic) installation instructions (for what is a simplistic script) in the actual file, but basically the lowdown is this: when the CGI script is active, you can retrieve iView videos over HTTP via a URL like http://localhost/cgi-bin/iview.cgi/730report_10_01_01.flv. As you can see, that would be very handy for integrating into your home media centre and the like. Obviously you need to adjust your web server ACLs to only allow localhost and RFC 1918 addresses to access the script. The script is not designed to be user-friendly — it’s meant to be versatile.
  • Just a minor change, but some extra metadata is parsed out of the programme. The frontends don’t make use of it (…yet), but it’s there.
  • Another minor change is that set_local_only(False) is set on the iview-gtk save dialog. This lets you save to GVFS locations (e.g. sftp:// or ftp://). Why that is not default in GTK+ I am really not sure.

On a side note, Whirlpool purged all material related to alternative iView access on their wiki and forums this week because they are of the opinion that alternative iView access constitutes bypassing copy protection and is thus illegal.

While I am not a lawyer, and I doubt Whirlpool consulted lawyers to reach that conclusion — and it’s better ask for forgiveness than permission — the fact remains that Python-iView is a project solely for interoperability purposes, not copyright infringement.

I pour my heart and soul into Python-iView not because I enjoy writing software, enjoy reverse engineering copy protection, or anything like that. I write Python-iView because it fulfills a need I have, and I released the software because I know there are fellow power users like me who are in the same situation and would benefit from the software in the same way.

Enjoy the new release, and viva la non mainstream!

Tagged: , , , , | 6 Comments »

De-farm Flickr

9 July 2010

Last night I threw together a utility called De-farm Flickr. It lets you convert a static Flickr photo URL like so:

http://farm5.static.flickr.com/4007/4246714624_76febcc67d_z.jpg

…into its original photo description page.

The conversion is done in two (dead easy) stages: (1) fishing the photo ID from the URL with a regexp, and (2) sending you to http://www.flickr.com/photo.gne?id=<id>.

I don’t know if you’ve noticed, but while the photo description URLs contain the photo ID, they also contain the username which is impossible to reverse engineer from the static photo URL. That’s why I send you to the photo.gne script: it can accept just a photo ID as a parameter, and send you to the right page.

Tagged: , , | 2 Comments »

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.

Tagged: , , , , , | 10 Comments »

SCLUG site redesigned

21 February 2010

The South Coast Linux Users Group (SCLUG) website has had a lick of paint by yours truly.

The old site didn’t look bad (in particular, I liked the penguin header image), but was getting a little long in the tooth, had a few issues (such as broken category styles, and images being linked to the wrong domain), and didn’t really reflect much about Wollongong, which is where we are based.

So a little Inkscaping later, I came up with this:

SCLUG site in Wollongong livery

Check it out. No, like, seriously. Check it out. A bit more polish to come, but the idea is there.

Tagged: , , | 1 Comment »

Mandatory filter (Clean Feed) trial results announced

16 December 2009

Well, it’s official. Conroy and the DBCDE (hey, that could be the name of a band!) have released the results of the much-debated Clean Feed.

From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!

The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.

This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.

Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.

One quote I found interesting from the report:

Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.

So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.

I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.

Tagged: , , , | 1 Comment »

Older Entries