A copyright-obsessed French government gets a taste of its own medicine

As you might expect when your president is married to a singer, the French government takes a fairly totalitarian line on copyright. The infamous HADOPI law effectively enables citizens to be prohibited from contracting Internet access with an ISP on the basis of copyright infringement complaints, apparently with such complaints centering around access from a particular IP address.

So it would be slightly embarrassing if it turned out that IP addresses belonging to the president's official residence and a French government ministry turned up in a database of illegal downloads. Unfortunately, this is precisely what appears to have happened: records of apparently "illegal" downloads from the French Ministère de la Culture and Élysée (official presidential residence and offices) have turned up in the databases of YouHaveDownloaded.com, a site publishing records from (among other sources) various public BitTorrent servers.

So, should we conclude that a poverty-stricken Sarkozy has had to resort to using public resources to download illegal copies of his favourite flicks and tracks in these times of austerity? Should we now engage in month-long trial to determine whether we can prove beyond reasonable doubt that Mr Sarkozy did or did not download that dodgy low-quality MP4 of La Cage aux folles? Should the Élysée now spend public money on a lengthy witch-hunt to establish which petty office clerk or work experience temp is responsible for this shocking infringement of some random fat cat's right to stuff his coffers a little fuller?

Well, I would suggest not-- but that's the point. Hopefully this revelation may help the French government to understand people's concerns about the glib connection that they are insistent to draw between an IP address in a database and the download in question having definitely occurred under the actions of a particular person, and to weigh up the pros and cons of establishing totalitarian means in an attempt to enforce the practically unenforceable with arguable benefit to society.

Is copyright worth breaking the Internet over?

The truth is that for some time now, the Internet can no longer be relied on to fulfil its simple infrastructural purpose of delivering bytes from A to B unhindered when requested to do so. The appetite of the powers that be for intruding on their citizens' privacy on the one hand and for succumbing to capitalist pressures on the other make any Internet connection an increasingly noisy channel.

Lemley, Levine and Post now outline and give an enlightening critique of some recent and alarming steps being taken in their essay Don't Break the Internet. As an author, I completely sympathise with concerns about copyright, and I would possibly agree that the current process of having infringing material removed is insufficient-- whilst also suspecting that the impact of the "copyright problem" is massively overexaggerated. But as with traffic shaping measures (among others), it is particularly concerning to see proposals to allow fundamental pieces of infrastructure to be undermined almost on a whim. Is this really the most intelligent counter-measure to copyright infringement that we can think of?

Can more indeed be done to disincentivise smartphone theft?

San Francisco Chronicle columnist C.W.Nevius has an interesting article on how Australian mobile operators do far more than in the US to block stolen phones. On the surface, it is intriguing that more governments, manufacturers and operators can't bang their respective heads together to put more measures in place, both technologically and legislatively, to curb mobile phone theft, particularly that of high-end smartphones.

Direction from governments is probably required. As the aforementioned article mentions, if left to capitalism alone, there is little incentive for mobile operators and manufacturers to put such schemes in place: for them, theft simply equates to more sales. Another interesting thought is that various countries in Latin America do apparently have some measures in place to block the connection of stolen phones. If the US doesn't, then this situation presumably serves to make the US an even more prime target market for the criminals selling stolen devices.

However, such measures surely aren't a panacea. Any system is only as strong as its weakpoints. What measures would need to be put in place to ensure the accuracy of the database and eliminate "false positives"? Since (presumably) operator staff have the ability to override the system in order to deal with cases of error, how does one prevent them from becoming targets for blackmail, bribery and gang involvement, in effect simply shifting the problem? What methods could criminals fight back with (e.g. replacement of the chip containing the serial number), and what impact would this ultimately have in terms of where new criminal opportunities would spring up? And what more serious crimes would criminals then commit instead of stealing mobile phones?

Nonetheless, I haven't seen much debate of these issues and it does seem that potential measures at least deserve more consideration from governments and operators and a clearer explanation for why they cannot be put in place if indeed they can't.

The Carrier IQ debacle

In case you've missed the commotion, concerns have been raised over the last few days about a component produced by a company called Carrier IQ and installed on many smartphones which (a) is set to run by default on some smartphones; (b) may be more covert than other processes running on the system; and (c) seems to have hooks to which it is passed various confidential data such as the identity of keypresses, the content of SMS messages and the cleartext version of data sent over HTTPS.

Such is the concern that some commentators are already describing the Carrier IQ software as a rootkit.

It is possible that the module in question is entirely innocent, and that the reason for confidential data being passed to its hooks is simply due to some slightly diabolical API design. Be that the case, I would then expect:

- smartphone manufacturers who have embedded the Carrier IQ component in their OS's to come forward with details about the close scrutiny that the software underwent on their part before being approved;
- Carrier IQ to come forward with some convincing and reassuring details about why this confidential data is apparently being passed to the process without constituting a breach of trust and confidentiality.

As I say, the Carrier IQ component may be entirely innocent and above board. But the longer the above two actions continue not to occur, the more concerning things appear. And sometimes, it isn't whether there is anything untoward that matters, but whether there appears to be...

Apple infuriates iOS 5 beta users by suddenly bricking their phones without warning

A huge number of iOS 5 beta users have apparently been infuriated after their phones were suddenly bricked yesterday evening US time.

Oracle releases Java patches

Oracle has released critical patch updates for Java runtimes.

Not news, but worth emphasising: SSL certificate authorities can be compromised

I can't actually spot the piece of news in this "news" item by the BBC. However, the general point of the article still stands as a universal truth: our secure web communications generally depend, and always have depended, on the assumption that certificate authorities are not compromised. They also depend among other things on the assumption that client machines' certificate stores, software and operating systems are not compromised and don't have bugs. People do sometimes forget this and take the little padlock icon in their web browser as some kind of "guarantee"; it's worth reminding ourselves from time to time that SSL offers a degree of confidence that a communication is secure, but no absolute guarantee.

However, I repeat that this isn't really a piece of news to have come to light on 18 October 2011; it has been universally true since the inception of the secure web communications protocols that we so readily rely on.

Amazon's Kindle Fire: does it have something to offer other than cheapness?

The latest company to jump on the tablet bandwagon-- in as much as such a bandwagon actually exists-- is Amazon with the launch of its new Android-based Kindle Fire.

Clearly, the distinguishing feature of buying Amazon's offering is that the device is coupled with Amazon's purchasing ecosystem, as opposed to, say, Apple's if you were to buy an iPad.

One thing that strikes me is that at present at least, the majority of media focus appears to be on the price, which at $199 does seem aggressive to the point of being a loss leader. When Apple originally launched the iPad, arguably the spark of the recent tablet frenzy among the rest of the market, it is interesting to compare Apple's approach of offering what they saw as a "fairly priced"-- but by no means "cheap" if you sounded opinion at the time-- marketed essentially on features. Amazon clearly have their ecosystem on their side compared to the average Miscellaneous Android Tablet Manufacturer X. But they do appear to be buying into the price-focussed strategy of the other manufacturers. It will be interesting to see how this plays out!

What do you think? I'd love to hear your opinion about the Kindle Fire.

Even 'random junk' may need encryption

There appear to be some interesting legal cases springing up around the fact that software developers have been taking "raw" Unique Device IDs and using them to store data against a given user 'in the cloud'. UDIDs essentially resemble a long 'random number' rather than directly encoding any user-identifiable information, so you may be forgiven for wondering what the issue is. The problem comes when applications have then stored user-identifiable information (such as social network data) alongside the UDID and make this information available to other applications, thus leading to a 'leaking' of user-identifiable information on the basis of this shared UDID.

The solution is in principle simple: append the UDID to an application-specific code or 'salt' and then encode this combination using a secure hash scheme such as SHA-256. The application-specific salt doesn't need to be a secret. But doing this means that I cannot compare a hash for user X from one application with a hash for user X from another application and deduce that they are for the same user. Again, in principle.

However, this scheme does rely on UDIDs containing sufficient entropy. Since the number of devices of a particular model sold is maybe in the tens or at most hundreds of millions (iOS devices appear to have sold something in the order of 200 million so far), if it is possible to make a good prediction of which range of the theoretically possible UDIDs has actually been allocated, then I can simply pre-compute all the potential combinations of (allocated hashes, application ID) for two given applications and find all the matches.

I haven't yet looked into all the details, but it appears that iOS 5 will remove the ability to read device-wide UDIDs in favour of application-specific UDIDs, presumably generated using a scheme such as the above. Although this is arguably the scheme that should have been adopted from the outset, if true, it will interesting to see what incompatibilities this throws up.

So why didn't people think of this in the first place? I wonder if one of the issues is that to a human, UDIDs do just look like 'random junk': it's just a string of random numbers, right, so why would you bother encrypting it? It's a good example of how when deciding when and how to employ encryption, we have to think not only about the data itself but also about protocols and practices governing how that data is used and stored.

Some thoughts in response to Matthew Baxter-Reynolds

Matthew Baxter-Reynolds wrote an interesting piece for the Guardian yesterday giving some points of view essentially on what Windows 8 will mean for businesses and IT careers. In particular, he makes the point that writing for a Windows 8 device means a more natural progression from the "C# in Visual Studio" type development that is the bread and butter of most business applications. And he makes the point that this time around, Microsoft will be fostering a tighter coupling of software and hardware platforms to move closer to the model of the iPad, part of whose success relies on it being more of a "self-contained ecosystem".

From this point of view, I think Matthew is probably correct: if the thing you want to concentrate on is writing boring old "bread-and-butter" business applications, then a platform that builds on the existing "bread-and-butter" platform of C# in Visual Studio will be a more attractive proposition for businesses to get a footing on the tablet bandwagon. And even it if wasn't more attractive from a development perspective, "Microsoft Windows tablet" may just sound a bit more 'serious and businessy' on a tender bid.

But, I think Matthew could have included a few other important observations (which don't necessarily contradict his point of view and if anything support it-- but which are nonetheless worth mentioning):

• the iOS "ecosystem" may still present an attractive market to developers in the sense that Apple have done the job of (a) isolating the 100+ million people with sufficient income to splash out on fancy toy; (b) sold them that toy on the basis of it providing enjoyment: or in other words, persuaded them that it is to their benefit to spend money on this new gadget (and associated apps); and (c) built a system for developers to market fairly effortlessly to that income-to-spare-for-toys-and-apps sector;
• games (and, apparently, knocking out games that you can sell for a buck or two a download) remain the predominant iOS market; the iOS development framework allows you to write virtually all of your application in a bog-standard C/OpenGL paradigm which will allow the creation/porting of a huge number of games with a minimal learning curve;
• while slightly quirky, in a sense Objective-C is just "another C syntax-based language" and if you stick around in programming long enough, you generally end up learning a new C syntax-based language every 10 years or so; indeed, "Java" as it looks today, and certainly how it will look if currently discussed language features make it into Java 8, is almost a whole new language compared to how Java was when it first materialised back in 1735 (anyone remember when Java didn't have inner classes, let alone generics or closures?);
• given that many business applications can and indeed ought to be written as web apps (a point which Matthew himself makes), for as long as HTML5/Javascript remains a standard enough development paradigm, I wonder if the Microsoft tablet will "C# in Visual Studio" actually become the paradigm of choice for tablet business applications anyway?

So, while I think Matthew is probably right that we could end up with an 80:20 split in one market versus a 20:80 split in the other, I don't know that that means that the "not-the-boring-bread-and-butter-database-application" market isn't viable.

Windows 8 soon to be upon us

It hardly seems 5 minutes since Windows 7 was the Next Big Thing. But apparently Windows 8 will soon be upon us, the principal motivation apparently to allow Microsoft to have another crack at jumping on the tablet bandwagon. It will be interesting to see how many people are actually burning to have Windows on their tablet, in whatever touchy-tabletified guise.

I'm quite happy not to have the following features on my iPad, for example:

• the need to grind the entire system down to the speed of a ZX Spectrum thanks to the latest antivirus software
• irritating pop-ups every five seconds requesting permission for applications to do their basic job
• having to battle with system that insists on saving documents in fundamentally stupid locations buried somewhere 5 million levels deep in the filing system
• the need for every Application That Goes Ping to take up 7 squillion terabytes of disk space, delay startup by half a minute and require at least 2 resets before they will work

But of course, I am open minded and eagerly await the first demonstration of the wondrous crop of Windows 8 tablets which will not fail to ensue.

UK petition to get programming on the curriculum

There's an interesting petition being made to the UK government to teach programming to children from primary school age rather than waiting until later in their school career. I'm not sure that the rationale specifically given by the petition's initiator-- that there would be "far less of a disparity between the sexes"-- is terribly convincing as it stands. It's not clear to me either that there's really some great barrier, preventing female students from learning program if they choose to, that will be broken down specifically if 9-year-olds are taught programming. And in any case, it's not clear to me that even if it were the case, that it would be the most compelling reason for teaching programming. However, whether that proposition proves true or false, I think there are other valid reasons for teaching programming at this early stage. And so I support the petition itself, even if not the exaggerated gender-gap mantra that seems to be its underlying motivation.

I think a more compelling rationale is to be found in the types of skills that programming develops and simply in the ubiquity of programmable devices. As has been expressed elsewhere, learning to be a good programmer seems to entail making certain problem-solving skills become intuitive. (As one fellow blogger has put it, learning to "algorithmate".) And in today's world where the average iPhone packs computing power that would have classed it as a mainframe not so many years ago, the potential for innovation through programming is practically beyond comprehension. I also suspect-- though I concede that I am also guilty of fluffy argument here and would be hard pushed to substantiate this view-- that the mindset that is made intuitive through learning to program gives people a more intuitive grasp of other concepts crucial to understanding our universe, be it genetics or the syntax of language. But in any case, the computer is now so engrained into our day-to-day devices that I would argue that "understanding our universe" really entails understanding how the microchip and computer work just as much as it does understanding the atom, the laws of thermodynamics etc.

Or put another way, there's really no reason nowadays to view programming as a uniquely specialist, "nerdy" subject.

However, I have some implementational concerns. I worry, if programming was brought earlier on to the curriculum, about how severely it would be dumbed down; educators need to understand that "programming" doesn't mean drawing inane patterns with "turtle graphics" or similar glorified spirograph imitations. I also have mild concerns-- though from a UK perspective, yes, they are mild-- that having a stronger computing component to the curriculum could widen existing digital divides if, for example, basic computer literacy was sidelined. (However, I do disagree with an apparent over-obsession with "teaching" skills such as browsing the Internet or word processing to those children for who such skills are as intuitive as operating their iPod.)

I look forward to seeing what success this and other similar petitions in other countries may have. And if you are based in the UK, I urge you to sign this petition and encourage your friends and colleagues to do likewise.

Speculated iPhone specifications... seem somewhat boring

As we approach the predicted launch date of the iPhone 5, we unsurprisingly start to see more of the media speculation machine whirr into action. Key specifications that are pretty much on the cards are the dual-core A5 processor and an 8 megapixel camera. And the new version of iOS isn't a terribly big secret given that any iOS developer can download the beta version.

Now, perhaps I'm missing something, but it strikes me that if this is the big spec improvement to make a big fuss about, it seems pretty unexciting.

The dual-core processor will hopefully make, for example, video editing a little less klunky. And it may be put to good use in a few specialist applications such as to allow extra tracks or more complex virtual instruments in some of the excellent music making software that has appeared for iOS over the last couple of years. But for your bog-standard iPhone game, I suspect the extra capacity will go largely unused: the standard game programming paradigm simply doesn't used multithreading, or only to a very minimal extent (e.g. sound playback is handled by background threads). While I'm not sure whether to agree with Don Knuth's take that multi-core processors are essentially a passing gimmick while we work out how to get faster single cores, it's true that what game programmers generally want is a single core that runs as fast as possible.

As for an 8 megapixel camera instead of a 5 megapixel one. Well, I can't help shrugging my shoulders a little. So maybe we'll get a 2x digital zoom that's just about worthwhile if the extra megapixels actually add resolution rather than just being extra noise. But unless Apple is about to announce that they've just designed a revolutionary new lens, a few extra megapixels don't sound terribly exciting on the face of it.

Of course, I also eagerly wait to be corrected... :)

Encryption: it's the protocols that often go wrong

Bruche Schneier has an interesting summary of the recent diplomatic cable disclosure due to (a) the encrypted file being (surreptitiously but) publicly available, and (b) the decruption key being publicly disclosed on a separate occasion. It's a good example of how what can often go wrong with cryptography is not the core technology or algorithm itself, but a failure in handling associated protocols (be it technical or social).

Google's use of the +1 button for search ranking

So firstly, a confession: I had always assumed that Google used +1 ratings in some small way for search engine rankings. Perhaps I'm misreading their blurb, but it seemed that they were pretty much advertised as such to web publishers. Clearly the influence would have to be small, as +1 ratings are easily fakable, but I assumed they were used in some way.

According to a recent Wired article, it seems that this isn't yet the case, but that Google are still in the process of considering using tihis nformation.

A couple of problems I see:

• as Ryan Singel notes, it's easy enough for web site authors to "fraudulently" arrange +1 clicks on their own site, so some kind of filtering would presumably be required, and the degree of influence that +1 ratings had would need to be quite carefully balanced and monitored;
• it may be that certain more "socially oriented" sites are more susceptible to the +1 or "Like" concept; just because a site is more focussed on social networking doesn't necessarily mean that its content is more "worthy" or relevant in response to a given search.

The problem of spotting scams

Ed Bott writes an interesting article on the subject of Why do people fall for trojans? As he explains, one of the problems is that the steps that one must go through to make even a legitimate purchase can often resemble the experience of a scam, including false alarms such as Windows warning us that our legitimately purchased item "might harm your computer".

This is also one reason why I think schemes such as the "verified by Visa" scheme for credit card purchases, in addition to being senselessly irritating, are actually a bad security measure because they imitate during a legitimate procedure precisely a process that an attacked might exploit or which might be the warning sign of an attack. Or in other words, in both this case and the scarey dialogs that can appear in Windows while you are downloading and installing a legitimate program, we are actually risking that what should be warning signs actually become ignored due to being "dulled by familiarity".

The Google files

The current milestone in the Google-Oracle debacle has been reported this week to hing around two e-mails, one dating back to 2005 and the other a draft of an e-mail possibly constructed after Oracle's patent claim expressing a need to negotiate a licence for Java.

Whilst the first of these e-mails discusses strategies for what to do "If Sun doesn't want to work with [Google]", if will be interesting to see how much this weight carries in light of the subsequent 2007 blog posting in which Sun's CEO apparently praises and supports Google for their use of Java technology in Android.

The scond, apparently only a draft of an e-mail, but slightly dammingly indicating "We conclude that we need to negotiate a license for Java under the terms we need." poses other interesting questions. How admissible as evidence is a draft of an e-mail reported to never have actually been sent? And if it is established that this draft was composed after Oracle first raised its case (from the reports I've seen, the timing still does not appear clear), how damming is an e-mail saying "we need to negotiate a license" if it effectively in response to Oracle saying "You need a license".

I'm not a lawyer, but it will be interesting to see how this plays out.

I would still be interested to see a re-examination of the actual patents in question. As I've expressed before, my opinion of at least some of these is that they appear to essentially be fancy verbiage to describe procedures that are inherently obvious to an expert in the field, with little in the way of an actual invention.

"Lost Programming Skills"

All too familiar with that "corporate IT solution" consisting of various inefficient black boxes haphazardly glued together using a plethora of acronyms?

This article entitled Lost Programming Skills looks at some of the once common knowledge which has not been passed on to generations of programmers. Interestingly, they highlight the inability to appreciate I/O issues (as much as, say, code optimisation).

Why Java 7's hotspot bug is a bad bug

I'm responding partly to Alex Blewitt's article in which he downplays the severity of the Hotspot bug exhibited in Java 7.

First of all, I think that in principle he may have a good point: previous Java releases have exhibited bugs which are arguably just as severe if not more so, there has been a temporary workaround, and they have been fixed and the world has carried on ticking. It's also true that any critical application upgrading to Java 7, as with any major upgrade of a key system component, would be mad not to have a regression plan should the proverbial shit hit the fan.

Where I disagree with downplaying this bug is that I believe the problem is largely one of process rather than the substance of the actual bug:

• this is the first major release of Java since Oracle took over stewardship of the Java language: eyes were on them to see how they would handle it;
• this is the first major release since the departure of various key ex-Sun employees;
• the bug(s) in question were reported before the release and were exhibited by code present in the experimental stage in releases of Java 6 (or to paraphrase: "if the fix for that known serious-sounding bug wasn't tested properly, then what else wasn't tested properly?");
• the precise circumstances under which the bug(s) exhibited themselves were not clearly published, let alone by Oracle;
• without knowing the details, a vague birds-eye view of the problem (a "bug with JIT-compiling nested loops") sounds like a bug in a fundamental function of the JVM that you would ideally want to work reliably 100% of the time.

Alex Blewitt takes the view that: "since Java 7 has only just been released it would be unlikely to be used in production environments yet". I don't buy this view. If this is an alpha release, then call it an alpha release. But if your position is that you are making a "release", then that quite reasonably means "this is a version that has been through rigorous testing which I believe is suitable for use in production environments". Let's not flannel our way out of this: it was a cock-up.

If I were using Oracle Database for any critical applications, I would certainly now be looking for some reassurance that they take the testing and release procedure of their database products more seriously than they do Java...

Today's spurious software patent is...

Sadly, on any random day, we could probably pick a case like this. Today it appears to be Spotify's turn to face a lawsuit for "infringement" of a spurious patent that should never have been granted in the first place.

The abstract of the patent begins:

"In order to distribute music information from a central memory device (2) via a communications network (4) to a terminal (6), this information is organized in a digital music information object."

As you can probably guess from this opening line, and sadly like so many other "software" patents, the rest is pure flannel: a very broad overview of the blindingly obvious steps that one would take in designing an application, but without having actually invented any non-obvious implementational details. Pretty much every line of the patent leaves you coming away thinking "Sure, that's obviously true, but what's your actual invention?". It's another example of how the patent system urgently needs to be reformed with at least:

- patent examination which goes beyond the intelligence of a chimpanzee on hallucinogenics (or as a next best thing, to paraphrase Donald Knuth slightly: if you would expect a 1st year software engineering student to be able to solve a problem as a homework assignment, you shouldn't be able to patent the solution as an "invention");
- severe punishment for companies that attempt to file spurious patents;
- more severe punishment for false claims of infringement (such measures do already exist to discourage large companies from bullying small developers, but they clearly don't go far enough).

There's also an interesting article in this week's Pod Delusion on the subject of patent trolls, looking at another recent case of patent abuse (Lodsys-Apple).

There's no hiding from ngram analysis

It's not often that a corpus linguistics paper makes it to Slashdot. A notable exception today came in the form of Burger et al's paper on Discriminating Gender on Twitter. Using surprisingly simple techniques, they present data suggesting that a machine algorithm can determine a tweeter's gender more reliably than human judges.

As far as I can see, their measure of reliability is of the % of correctly attributed tweets over the data set as a whole. It would be interesting to see more analysis on the nature of tweets that the system can't judge reliably vs human judges (and vice versa). To what extent do typical tweets fall into polarised categories of "readily categorisable" vs "highly ambiguous", or is there more gradience? And it will be interesting to see what other demographic data can be gleaned using similar techniques.

Estoppel

Following on from my post yesterday about how a statement in Jonathan Schwartz's blog post indicated that Sun approved Google's use of Java in Android, I should perhaps have pointed out-- as others reporting on this have-- that there is indeed a judicial basis for Schwartz's statement being used in Google's defense. The principle is estoppel, defined by Black's Law Dictionary as:

"An affirmative defense alleging good-faith reliance on a misleading representation and an injury or detrimental change in position resulting from that reliance."

Will Jonathan Schwartz's blog post finally persuade Oracle to pick its toys up and put them back in the pram?

In case you've missed all the commotion, or just found it a little bit dull, I remind you that in August 2010, Oracle filed suit against Google, claiming that their Android operating system violates various patents held by Oracle after they acquired Sun Microsystems.

The extent of damages that they can actually claim for appears to be in some doubt. After an initial claim of several billion dollars, and a judge effectively ruling "don't be so silly" last week, the claim may be reduced to as "little" as 100 million dollars. If I had 100 million dollars, I wouldn't be sitting round writing silly blog posts. But to Google, that's petty cash.

Now, to naive bystanding programmers such as myself who are not lawyers, a few things always seemed a little bit odd about this case:

• would a company the size of Google with the legal resources it can afford really just go ahead and commit billions of dollars worth of patent infringement and hope that "nobody would notice"?
• if there was a big problem with Android's use of Java technology, why didn't Sun raise this at the time?
• some of the patents in question really boil down to some quite small, specific points of implementation (e.g. specific details of implementation of protection domains, the "pre-processing and packaging of class files", and some implementational details of the virtual machine), many of which could probably be worked around by using alternative implementations or (and hence) a reasonable licence fee negotiated with Sun if need be.

Or put another way, the whole case smells of somebody scratting around through their recently acquired arsenal of patents looking for an excuse to sue. Rather than learning to play happily with all the other children in the classroom, Oracle seems intent on shouting "But Miss, the red crayons are mine!".

Meanwhile, commentators had noticed the curious deletion of blog posts of previous Sun CEO Jonathan Schwartz. Unfortunately, such Orwellian attempts to rewrite history don't tend to work on the Internet. Thanks to nothing more sophisticated than a search in The Way Back Machine, a key post from "Jonathan's Blog" has been restored to its former glory. And in this post, Schwartz states: "I just wanted to add my voice to the chorus of others from Sun in offering my heartfelt congratulations to Google on the ennouncement of their new Java/Linux phone platform, Android". As commentator Steven Vaughan-Nichols has also pointed out, this doesn't exactly sound like Sun were saying "We disapprove of Android because it violates our patents and will be suing Google for billions of dollars".

It will be interesting to see if this evidence can persuade the two parties to finally bang their heads together and get on with more interesting things. Like it or lump it, Android is a key market for Java technology, with Android accounting for a 30% share of tablet shipments in April-June 2011, for example. I can't help feeling that it would be more conducive to the platform's development for Oracle and Google to have a more sensible working relationship.

Google's malware warning

Google have given more details of the malware warning that they will be issuing at the top of their search engine. They have been able to identify around 2,000,000 infected machines on the basis of traffic sent to their servers.

A couple of things strike me about this:

• I wonder how applicable this technique could be to other servers in general? Could we see other sites performing a similar civic duty of warning users about potential malware.
• Given that one route of infection (which Google blames specifically as the culprit in this case) are those fake "Your computer has been infected" popups already littering the Internet, how do we give out a message to users that these popups should generally be ignored because they're likely to be fake, whilst at the same time issuing genuine warnings in an ostensibly similar manner?

I'm interested to hear your thoughts either here, or by tweeting to BitterCoffey.

Dear universe: please make your default settings sensible

I'd occasionally noticed that alerts for my calendar events would sometimes go off at odd times on my iPad. For example, I'd wake up in the morning to find that the "5 minute" alert for a mid-morning meeting had already gone off. I suppose the first couple of times, I just assumed I must have entered something wrong when setting up the event. But, being the aspiring cross between Columbo and Paddington Bear that I am, gradually my suspicions were aroused.

Luckily, some other people more patient than I am with spuriously designed user interfaces were able to come to the rescue. In case you haven't found it, the offending setting is an option burried in the "Mail, Contacts, Calendars" section of your iPhone/iPad settings curiously entitled "Time Zone Support". With this set to a particular Time Zone (rathr than simply being switched off), then your device will not adjust calendar events to match your current time zone.

So you might be thinking "hey, what's your beef, this is a great feature to have, no?". Well, yes, it's a great optional feature. But the things that strike me are:

(a) to say that the iPhone/iPad are supposed to be the holy grail of PDAs (aren't they?), it doesn't seem like a terribly fine-grained feature, particular as there is a "Location" field in calendar events, and that thanks to the miracles of GPS, the device knows where you are at any given moment (or at least, knows where you are to within an approximation of a couple of skyscrapers/underground bunkers-- usually good enough to tell what time zone you're in);
(b) why give this option a silly, non-intuitive name and then turn it on by default? why by default would I tend to want events not to be in synch with where I am at the moment, given that the whole raison d'être of these devices is for travelling...?

Well, I'm sort of happy now I've discovered the option. But on the other hand, grrrrrr.

Rip-off for rip-off's sake

In response to crackpot loon conspiracy theories that instead of landing on the moon in 1969, Nasa played a hoax that has then been kept under wraps for the past 40 odd years, my argument has always been that rather than stage and hide such an elaborate hoax, it's probably easier just to go to the moon. (The other main evidence for the falsity of the moon landing hoax being that Fox TV made a documentary about it...)

Well, my grip on reality may have been overturned today by reports and pictures of fake Apple stores in China. Somebody who can actually be bothered to go to these lengths of counterfeiting and then sustain the momentum of preventing the relevant authorities from finding out must be doing it out of some bizarre sense of national pride. I'm really not convinced it isn't easier to just franchise a genuine Apple store...

On the dangers of our reliance on opaque algorithms

Kevin Slavin offers an illuminating TED presentation on the implications of our reliance on computer algorithms whose complexity has reached the point of being opaque to human understanding.

The fine lines of iPhone app rules

"It's not whether there is anything wrong. It's whether or not there appears to be."

It appears that app developer Daniel Amitay has been finding out recently about the finely shaded grey areas of Apple's rules on what you can and can't do from an iPhone app.

One of Daniel's apps, Big Brother Camera Security, is designed to mimic the iPhone passcode screen and then photograph any user making an incorrect attempt to enter the passcode. He also decided to collect statistics on the most common passcodes chosen by users by having the app anonymously send those passcodes. Apple have since removed the app from the App Store.

Daniel argues on his blog that this data collection was legitimate, as the purpose was to warn users against choosing frequently chosen passcodes in a future update to the app, and the the App Store EULA informs users that apps may collect diagnostic data. Apple, on the other hand, appear to be arguing that application was "surreptitiously harvesting user paasswords".

It seems that whether that is strictly the case depends at least on one's interpretation of what "harvesting" constitutes, and how one defines the nature of the separation between the app's lock code and the actual iPhone passcode, given that the app is designed to simulate the iPhone lockup screen. A potentially complicating factor is that the data has also been used as the basis for a (somewhat interesting) article that Daniel has published giving an overview of the statistics obtained for the most common passcodes and most common digits in different positions. Publishing this article, though of interest to the security community, may be deemed to make the data something other than for diagnostic purposes of "facilitat[ing] the provision of software updates, product support and other services [...] related to the Licensed Application" as set out in the App Store EULA.

Some interesting questions to consider:

• if secure hashes of the passcodes, rather than the actual passcodes, had been sent, would that have constituted "harvesting"? (Even though with only 1000 possibilities, the actual codes could of course be resolved from the hashes.)
  
• which precise conditions would need to be changed to allow Apple to approve the app? (Is it ultimately the data itself or the surreptitiousness that is the problem? or the publishing of the data in an article not strictly necessary to updating and supporting the app?)

It will be ineteresting to see how this case evolves over the coming days/weeks and whether Daniel is ultimately successful in getting the app reinstated, and what changes are necessary for this to happen.

Have CAPTCHAs gone slightly too far...?

I like a bit of security just like the next man. But I wonder if this piece of "security" is going slightly too far. It appears that in order to make a posting on Facebook, we are now required to fill in a CAPTCHA consisting of words in two different alphabets...?

Now, I was trying to decide if this was some kind of perverse general knowledge test, or the latest CIA "initiative" to track down terrorists. Mention the wrong keyword and show an ability to type Arabic, and you're suddenly on the list of America's most wanted...?

(Oh, and even if I could have read Arabic, I would have still got stuck with the mysterious blob on the left. Answers to that one a postcard...)

Why lawmakers' ignorance matters

The other day I blogged on the apparent ignorance shown towards what is now basic technology infrastructure by members of a committee hearing in the current UK libel law reform case.

It appears that our lawmakers, possibly with similar knowledge of Internet infrastructure to those on the libel reform committee, have now allowed us to reach a stage where putting a link on a web site is an extraditable offence. I'm just going by what I've read in the media and cannot confirm any of the details. And the aforementioned article doesn't appear to mention What Law Has Actually Been Broken. But if true, I am slightly curious as to why the focus of the Powers That Be is on removing sites linking to the offending material rather than just removing that material from the sites hosting it. If I put a note on my web site saying "There's illegal stuff on the Internet and if you do a Google search for it you might find it", is that also illegal...?

The lawmaking process and technology

A process is currently underway in the UK to reform the libel law. Before people outside the UK click their "back" button thniking this is just a piece of local trivia, I'd like to suggest that the procedure highlights some more general symptoms of how the Internet may be understood (or not) by those involved in the lawmaking process which are probably applicable in many countries.

In this session, various members of the science community who have in one way or another been on the receiving end of libel cases (notably Simon Singh and Ben Goldacre for their attempts to alert the public to instances of bogus medicine) give their opinion on changes that they believe should be included in the reform. Very telling are several instances where they appear to be educating the panel on some basic concepts about the Internet, blogs and ISPs. Some key points to look out for:

- at 17'50, where Simon Singh is practically describing what the Internet is
- at 18'10, where Ben Goldacre is pretty much explaining what a blog is, and making some very fundamental statements about how basic and prevalent they are to the Internet
- at 18'27, where it is asked what the witnesses think of a "Prior system whereby a claimant could write to a web host ... and the web host would be under the obligation to put up a notice alongside the story", and Ben is forced to explain some extremely basic information about the relationship between ISPs and their clients.

Now on the one hand, I should emphasise that I don't begrudge this level of transparency in a world where not all citizens are so fortunate in seeing their lawmaking process in action. On the other hand... I worry about how this demonstration of an apparent oblivion to basic technology and "social infrastructure" is going to be translated into a new law that truly fulfils the wishes of those calling for reform.

Making the difference with lego

There are various methods for evaluating a polynomial. But perhaps one that may not have occurred to you is to build a difference engine out of lego. According to this story in Wired, that's the approach that Andrew Carol decided to take.

Whether further lego difference engines will be built is not yet clear. A difference engine is currently used in the banking sector as part of the processing of international transfers as, despite adding several days on to the time taken for transfers to complete in some cases, difference engines are deemed to be more reliable than conventional microprocessors. However, banking officials openly admit that the decision to use a solid gold difference engine has prohibited rolling out similar machines across Europe to speed up transactions. Now that this cheaper, lego version is available, industry leaders may be looking to see whether it has the reliability required to allow the rolling out of these cheaper machines and hence enable banks to speed up the processing of international transfers. However, it is unlikely that a decision will be reached before 2012. For the time being, those of us transferring money between accounts in different countries will have to continue to wait up to 5 days for transfers to complete.

Irritation, irritation, irritation...

Over 1,000 users of the Javamex have responded to the site's survey in which they were asked to vote for their most irritating software. It seems that the topic has struck a nerve...

I have a put up an initial hit parade of irritating software based on the first 100 repsonses (a more in-depth analysis of all results to be published shortly).

In first place, perhaps unsurprisingly, are antivirus programs. I've used practically every major antivirus program on the market, and have found every single one to be completely infuriating. Whether it's popping up irritating paranoic messages every few milliseconds, making it difficult to access certain web sites properly or slowing down your eight-core CPU to the speed of a ZX Spectrum on tranquilizers, every single antivirus product appears to be designed to make you want to throw your PC off a very high balcony.

I was somewhat reassured to find iTunes in second place. Especially under Windows, I have also personally found it to be one of the most buggy and infuriating pieces of software ever written. But whether it's freezing every five seconds, launching into a lengthy "sync" process just because I accidentally wanted to upload an extra song or thinking at random intervals that my iPhone has mysteriously transformed into a new one never seen before in the history of humanity, I now feel less alone in the universe knowing that other users share my view.

Suggestions for new programming articles

The Javamex site is open to suggestions! Please make a suggestion for a new programming topic at the top of the home page!

Update to Currency Quoter utility

The latest update to the Currency Quoter utility available on this site, version 0.04a, fixes an issue which prevented currency data from being downloaded under some circumstances. It also introduces a parameter allowing you to control the number of months' worth of data that are taken in producing the forecast value of a given currency exchange. You can currently configure this between 1 and 12 months. The default is 3 months, which appears to be suitable in most cases. However, you may wish to take a greater period, for example when looking at a longer-range forecats of the value of a currency that has had a particular trend over a longer time.

Please report any issues with this program bugs@javamex.com

Additional information on the 'final' keyword

The section on the Java final keyword has been expanded. Previously, we concentrated on the use of 'final' for thread-safety but did not give much information about a separate use of 'final' to indicate that a class or method cannot be overridden. The new material expands upon this use with a look at the performance implications of the 'final' keyword as a class or method modifier.

A common view that I have both heard among colleagues and seen in various Java textbooks is that 'final' is as much a performance hint to the compiler as a specification of design. In the new section, I present some data showing that this view is probably misguided: the timing of calls to methods to final vs non-final classes comes down to whether the JIT compiler can determine at runtime the precise subclass of an object rather than whether or not the class in question is or may be overridden.

Initial release of "Currency Quoter" utility

A very initial release of a currency conversion tool is available from the Javamex site. The Currency Quoter utility allows you to exchange between various currencies using exchange rate data reported by the IMF, and also allows you to forecast the likely range of values that a particular exchange will have on future dates.

For news and updates, you may also wish to subscribe to the Currency Quoter project page on Freshmeat. You can report bugs at bugs@javamex.com

New material: doing maths in Java

The section on mathematical operations in Java has been expanded over the last few days to include some new material that will be useful to those writing maths-related applications in Java. Notable inclusions include:

• The section on the performance of java.util.Math methods has been expanded somewhat to include more information about the timing and implementation of certain operations.
• A new section on BigDecimal and BigInteger looks at how to manipulate arbitrarily large numbers (or numbers of arbitrary precision) in Java. We include an analysis of the performance of multiplication.

As usual, suggestions for improvements to this section or suggestions for new material are always welcome, either on this blog or on the Javamex forum.

I thought this was interesting, although the actual security impact is hard to assess. Various sites "leak" information not through the payload returned by a particular HTTP request, but simply by the response code. Thus, as this article illustrates, we can find out, for example, whether a user is logged on to sites like Facebook as follows:

- find a particular page that responds with an error code or not depending on whether or not the user is logged on;
- using a "script" tag, ask the browser to load that page as though it were a script;
- in the onload() and onerror() handlers, take action that assumes the user is logged on in the first place and not in the second.

The fact that a user is logged into, say, Facebook or GMail probably isn't a very exciting discovery: half the Internet population probably are at any given moment. But more controversial sites may want to think about what kind of information they accidentally leak in this way.

New articles in the 'Java collections' section

Readers are invited to explore some new material that has been added to the Java collections section of the web site. By rights, this material would probably belong in a "Java algorithms" section, as they don't use the collections framework as such, but rather look at structures closely related to those used in the standard collections classes.

In the section on Advanced use of hash codes, some new material firstly looks at how we can implement a strong, 64-bit hash code in Java, and how we can use this to create a Java hash map implementation that saves memory by storing only the keys.

A further section on Bloom filters builds on this strong hash function further, allowing a set of objects to be represented very compactly in memory in return for a certain "false positive rate". This tradeoff is useful in certain situations where we want to "weed out" certain items that require further, resource-intensive processing from those that don't (for example, when wanting to reduce database hits), but where it doesn't matter too much if a small percentage of items "slip through the net". We look more closely at how the initialisation parameters of the Bloom filter can be configured to tune the false positive rate in return for more or less memory space being required.