so much to do; a project that covers so many areas, i'm in danger of being called an egomaniacal megalomaniac, so i thought i'd best say it first.

i'm giving a talk on pyjamas, which is a python-to-javascript compiler (that takes over from where pypy decided to abandon the idea), it's a desktop widget set, it's a browser-based widget set; it's the world's only free software cross-browser, cross-platform, cross-desktop, cross-browser-engine, cross-widget-set widget set.

pyjamas being based on W3C DOM, you can put pyjamas onto python-xpcom (actually hulahop); you can put it on top of pywebkitgtk; you could, if they fixed the rtti-related issue, even put it on top of python-KHTML. you can run pyjamas apps in google chrome, safari, the nokia S60 embedded phones, netscape, firefox, opera and more.

XUL and hulahop are available for gnu/linux, macosx and windows (thanks to sugarlabs compiling up XUL and hulahop). pywebkitgtk is currently available for gnu/linux and macosx (the windows port is a bitch).

webkit compiles for gtk, qt4, wxWidgets. i've only got pywebkitgtk going at the moment, but there's nothing to stop adding qt4 and wxWidgets to the list. the pyjamas API is on top of those, and independent of them, because it's based on W3C DOM.

this isn't bullshit, vapourware, pre-alpha code or "not ready yet" - it works. i'm just very surprised that more people don't know about it / aren't using it. there are 279 people on pyjamas-dev, and 30,000 or so on GWT (which is where it originally came from). yet the people who use pyjamas just... get on with it. no fuss.

lots of people say "gosh it's a long time since i last posted" - like confessionals, "bless me father it has been xxx years since my last blog..." but no, it just _feels_ like a long time...

what the heck's happened...

moved

we're moved. stanwell. just south of heathrow (out of flight path) and east of staines. both are 15 minutes by bus. joined westminster housing coop. building's scheduled for demolition in december, but because there are 60 families in 4 blocks of flats, the chances of that happening are... fairly remote.

no carpets, no cooker. actually - no water for 36 hours until we found the tap. i bought 8 1-gallon bottles of water. destroyed a morrison's heavy-duty bag by trying to attach it to one of my two backpacks: it dragged against the wheel of my bicycle. why i even tried to carry 36 kg of water on a bicycle is beyond me - in the end i got off and walked.

3G USB HSDPA on linux</a>

the 3G usb modem is working out well, under linux. i keep forgetting to switch it off. i documented the process of setting up a huawei K3565 with HSDPA under linux.

Saving money and bandwidth using HTTP proxies

i have _six_ levels of HTTP proxies. squid, privoxy, ziproxy and rproxy are chained and installed on my server; rproxy and polipo are chained on my laptop. rproxy can't cope with AJAX responses of zero size (assert data > 0 keeps appearing on stderr...) so you have to use "older" versions of gmail.com, and occasionally, google searches result in a "BIN" download but work the second time.

... but i don't care! i'm looking also to block all swf and java files. i did mess up a bit at one point: i wondered why i was getting popups and adverts (i'm used to running privoxy on my laptop) but i'd messed up the chains a bit and should have installed privoxy on the server _anyway_... duh.

rproxy 0.5.7 works surprisingly well for an abandoned (due to patents) project.

webkit and the glib / gobject bindings

ahh, my favourite project. apple decided to lay down the law. without explanation, without discussion, without consultation, they have "decided" that language bindings shall conform to W3C standards. unfortunately, strict compliance with W3C standards makes it difficult or impossible to use language bindings.

what's especially hypocritical is that the javascript bindings in webkit get "special treatment", because of the large number of users who would otherwise complain.

i've requested seven times that evidence showing that all other major web browser engines provide language bindings on an equal footing with javascript: no exceptions are made just because one language is javascript. so, all language bindings have "toString" across all objects; HTMLAppletElement and HTMLEmbedElement have width and height as strings which can, contrary to the W3C specification, accept "1px" which is converted to numeric 1.

on this latter, the W3C specification specifically states that width and height on <embed> elements MUST be a long integer: unfortunately, so many people wrote piss-poor javascript specifying width="100px" that every single browser engine - including webkit itself - accepts "px" and does some conversion.

now - that's all fine, right up until the point where people start writing browser apps that can both be compiled to javascript (from e.g. python) or can be run as native python (by e.g. using python bindings to webkit DOM). a developer writes an app that gets compiled to javascript, it uses javascript DOM manipulation to create an "embed" node, adds a property element['width'] = '100px' all is fine. then they try to run the same app, native under webkit and FUCK it doesn't work.

why? because FUCKING apple dictates that from language bindings other than javascript, it MUST be how THEY say it is, and THEY say that an embed node's width property MUST be an integer, because the W3C spec said so, _despite_ having specific, realistic exceptions to cater for real-world usage (in javascript).

seven requests for a review of the evidence presented, and total silence. i'm thinking of ways to escalate this so that they are forced to review the evidence.

long post. i'll leave it at that.

this will be my 50th move. i'm 39.

as i have £20,000 of debt and earn about... £800 to 1000 per month, i don't have very many choices of places to live, so my family and i have been accepted by the westminster housing coop, who specialise in very short-term housing.

myself, my partner and our two-month-old baby will be moving beginning of june to a property that is scheduled for demolition at the end of the year. it's a block of 70s cheap housing that lacks ventilation and adequate thought as to the design of the windows.

we've yet to arrange internet access: so, temporarily and in an emergency, i bought a vodafone 3G USB modem. it's a Huawei K3565. yes i had done a little research in advance, and there's a fantastic python-based application which was commissioned by vodafone somewhere for ubuntu-based netbooks.

the application was badly designed to shoe-horn specifically into gnome, which i despise. about an hours' judicial hacking and exploration removed the dependencies on gnome, substituting xfce-notifyd which answers the freedesktop.org standardised "notification" requests that the modem-management program generates.

all in all, for £34 and about an hours' work, i was stunned to have this all working under linux.

... here's the problem though: the cost of the access. so - i resurrected rproxy.

rproxy 0.5.7

rproxy is designed to send _changes_ to web pages, not the entire web page. it doesn't work on HTTPS, and i don't think it supports HTTP 1.1, but who cares!

the cost savings are just... augh, i don't even want to think about what i'd have to pay for, without it.

updating rproxy to use modern gcc was fiddly but straightforward.

... welll.... better get on. have to find a cooker and a fridge, get a pump for the airbeds...

• analysis of the RTMPE specification shows it to be vulnerable to man-in-the-middle attacks, and to be nothing more than an obfuscation attempt using no passwords and no secure encryption keys of _any_ kind. Diffie-Hellman is utilised, but in a way that is subject to standard man-in-the-middle attacks; what Adobe calls "encryption" keys are nothing more than publicly-available "magic constants".

• the developer of rtmpy.com has requested removal of his projects, which includes crtmpserver, from sourceforge, in protest at sourceforge's compliance with the illegal use of a DMCA take-down notice.
• the same developer has successfully implemented RTMPE in crtmpserver.
• the developers of rtmpy have indicated their intent to implement RTMPE in python.
• eben moglen, of the software freedom law centre, has written to emphasise that the software freedom law centre is always available to help any free software developers who are attacked by large corporations.
• dave touretzky, the professor who created the DeCSS gallery, has provided a mirror of the RTMPE specification on his web site.

so the shit is truly hitting the fan, for adobe.

whoopsie, guys. if you had left rtmpdump alone, i would never have seen the slashdot article. if i hadn't seen the slashdot article, i would never have mirrored rtmpdump. if i'd never mirrored rtmpdump, i would never have looked it it. i i had never looked at it, i would never have gone, "this is shit. i must write a spec, immediately". if i'd never written a spec, two teams of free software projects would never have implemented RTMPE.

how's that for not achieving the desired results? why don't you fire your shit-for-brains lawyers: they're only looking for ways to make money out of you, and are alienating the very people who could help you extend the reach, security and acceptability of your products and the protocols that you've designed: us free software developers.

until you get with the picture, though: FUCK you, adobe.

RTMPE is definitely not a "Copyright Protection" mechanism.

An analysis of RTMPE (see "Analysis" section) shows that RTMPE does nothing more than what SSL already does (provide end-to-end secrecy) and simply mathematically links a publicly-downloadable and publicly-obtainable SWF file to the connection.

Bottom line: All the information required to obtain the content is publicly available. There is no "security".

If the information isn't publicly available (such as the SWF file to be executed in the web browser) then the content cannot be obtained, either.

Unfortunately, this leaves Adobe in the shit, if they've been claiming that SWF verification is somehow "secure". Anyone reading this who has bought into Adobe Technology on the basis of "security" or "protection" is advised to initiate legal action against Adobe, seeking compensation and damages for deceiving them about the level of "protection" of their Copyright material.

From Adobe's Web Site:

'(swf verification) ensures that only your SWF or AIR files can connect to your application or content on Flash Media Server'.

This is false. The correct interpretation is:

"if anyone can obtain the publicly-available SWF or AIR file (or a hash of it, and knows the SWF or AIR file's size) they can also connect to your application or content".