Mike Meredith

Apple Demonstrates Its Stupidity Again

 Computing  No Responses »
Nov 032012
 

Previously I ranted about how Apple had “complied” with a UK court order by criticising the decision made by the UK courts and implying they had gotten it wrong. Now Apple have been dragged into court again to explain their lack of compliance, and been ordered to remove their previous statement and replace it with another whose wording has been dictated by the court.

Apple in a mind-blowing exhibition of stupidity tried to claim that whilst it would take just 24 hours to take down their previous statement, it would take up to 14 days to put up a replacement statement. For “technical reasons”.

Now as it happens, in addition to writing drivel on this website (where the only delay “technical reasons” might impose would be due to an infrastructure failure/upgrade, but “personal reasons” might well impose a 14-day delay), I have been involved in more “corporate” websites where content management systems can indeed impose “technical reasons” for a delay in updating a website. But not 14 days! More like a few hours, or at most 24 hours.

And if a content management system does impose a long delay in publishing website updates, it is always possible to bypass the CMS to publish emergency updates. Even if it is necessary to “break” the CMS to do so.

It may very well be that an internal approval process within Apple’s CMS normally requires 14 days for an update to be published. In which case the reason for the supposed 14 day delay is for “business reasons” rather than “technical reasons”.

Of course there is also another possibility. Given that Apple have recently launched new products, they may be very reluctant to put anything up on their home page (which the revised court order now requires) which distracts from their new product. You do have to wonder if this mysterious delay for “technical reasons” is in fact so that nobody gets distracted from the pretty pictures of Apple’s new products.

That would be very, very silly of them.

The court evidently did not think much of Apple’s excuse of why they could not put up a replacement statement promptly and have given them 48 hours to comply. So either Apple has to comply within 48-hours – demonstrating that they lied in court, or has to come up with detailed technical reasons why they cannot comply – which will demonstrate they are surprisingly incompetent when it comes to technical matters.

Neither alternative is comfortable for Apple executives, but this position is all their fault.

Apple’s Enforced “Apology”

 Computing  No Responses »
Oct 262012
 

Apple actually lost a court case recently, and as part of the settlement they were asked to publish an apology in both printed media and on their website. Which may well come close to the letter of what they were obliged to publish, but in no way comes close to the spirit … and indeed may well be contempt of court. The relevant part of the apology reads:

However, in a case tried in Germany regarding the same patent, the court found that Samsung engaged in unfair competition by copying the iPad design. A U.S. jury also found Samsung guilty of infringing on Apple’s design and utility patents, awarding over one billion U.S. dollars in damages to Apple Inc. So while the U.K. court did not find Samsung guilty of infringement, other courts have recognized that in the course of creating its Galaxy tablet, Samsung willfully copied Apple’s far more popular iPad.

Or to re-phrase it: The UK courts are complete idiots and should pay closer attention to the judgements reached in the US and Germany which of course have far wiser judges. If I were that UK judge I would order Apple to pay “over one billion dollars” to the court and prohibit Apple from selling any products in the UK until it was paid.

You do have to wonder just how dumb the relevant executives at Apple are. When you are forced into publishing an apology, the sensible thing is to do just that … and not try and weasel out of the apology by saying “but ….”.

 

This Probably Won’t Ever Happen, But …

 Computing  No Responses »
Oct 222012
 

It could!

According to this other blog entry, a completely innocent person has had their Amazon account closed. Which would be very inconvenient for anyone, but if you just happen to be a Kindle owner with a fair number of ebooks purchased it will be somewhat more than inconvenient.

You could believe that the person involved was involved in some sort of activity that Amazon didn’t approve of. Perhaps they were an anti-DRM activist of some kind; perhaps they accused Amazon of some under-hand business practice, or perhaps they just belonged to the wrong political party. Who knows? Amazon’s response to the situation is standard corporate double-talk designed to say as little as possible.

Conventionally, Amazon has a perfect right to cease doing business with anyone for whatever reason they choose. But removing access to purchases (such as Kindle books) is a whole different ball game.

At worst Amazon is guilty of theft and at best they have brought further disrepute to the whole DRM system.

The Coolest USB Devices

 Computing  No Responses »
Oct 202012
 

If you have a look for top cool USB devices, you will find plenty of lists out there with rather boring choices. In fact most of the devices are simple memory sticks whose main means of standing out from the crowd is to have an unusual form factor. Now I like funky form factors for my memory sticks as much as the next person, and some of the memory stick designs do deserve some attention. Some other lists contain things like USB powered missile launchers, heated mugs, etc. all very fun.

But it is still a bit of a shame that you have to look so hard for really interesting USB devices. My list below has been gathered over years and frequently by accidentally discovering them. I’ll add additional ones to the list as I discover them … or if people tell me about ones that interest me :-

iStorage DatAshur

And after all that moaning about memory sticks, the very first device on my list is a memory stick! But a rather different one :-

The difference is hinted at by the little buttons on the memory stick. This is a hardware encrypted memory stick where the encryption is implemented within the stick itself rather than rely on a piece of software that may or may not work with your current operating system.

The Entropy Key

You can tell this is a more geeky product just by the fact that the sales picture shows the device naked :-

What this does is provide a source of genuinely random numbers that can be used by Linux to add entropy to the standard random numbers device. To most people, this is a pretty uninteresting device, but anyone involved with cryptography is undoubtedly saying Cool! and has probably clicked on the title link to disappear from this posting to go and get one.

The Ubertooth One

As you may very well guess from the really naked picture of this device, it is probably the geekiest device in this list. It is effectively a software radio limited to the 2.4GHz band and is intended as a device for hacking bluetooth. Think of it as a WiFi sniffer but for bluetooth; although it can do quite a bit more.

The Zalman Hard Disk Enclosure

Your average USB hard disk enclosure (for putting an appropriate spare internal hard disk in) is not exactly exciting, and this device is one of those “stealth” devices that becomes more interesting the deeper you look at it :-

Note the little LCD display. What you cannot see is a little job-wheel which is the input device to control the functions. This little box of tricks allows you to select an ISO file contained within a subdirectory named _ISO and the firmware emulates a CD-ROM with that ISO inserted into it. Yes, you can now carry around as many CDs as you want and use them to boot from.

Debian: Adding Entropy to /dev/random

 Computing, Linux, Security  1 Response »
Oct 172012
 

I have recently become interested in the amount of entropy available in Linux and decided to spend some time poking around on my Debian workstation. Specifically looking to increase the amount of entropy available to improve the speed of random number generation. There are a variety of different ways of accomplishing this including hardware devices (some of which cost rather too much for a simple experiment).

Eh?

Linux has a device (/dev/random) which makes available random numbers to software packages that really need access to a high quality source of random numbers. Any decently written cryptographic software will use /dev/random (and not /dev/urandom which does not generate “proper” random numbers of quality) to implement encryption.

Using poor quality random numbers can potentially result in encryption not being secure. Or perhaps more realistically, because Linux waits until there is sufficient entropy available before releasing numbers through /dev/random, software reading from that device may be subject to random stalling. Not necessarily long enough to cause a major problem, but perhaps enough to have an effect on performance.

Especially for a server in a virtualised environment!

Adding Entropy The Software Way (haveged)

HAVEGED is a way of using processor flutter to add entropy to the Linux /dev/random device. It can be installed relatively easily with :-

apt-get install haveged
/etc/init.d/haveged start

As soon as this was running the amount of entropy available (cat /proc/sys/kernel/random/entropy_avail) jumped from several hundred to close to 4,000.

Now does this increased entropy have an effect on performance? Copying a CD-sized ISO image file using ssh :-

Default entropy 29.496
With HAVEGED 28.636

A 2% improvement in performance is hardly a dramatic improvement, but every little bit helps and it may well have a more dramatic effect on a server which regularly exhausts entropy.

Checking The Randomness

But hang on … more important than performance is the randomness of the numbers generated. And you cannot mess with the generation of random numbers without checking the results. The first part of checking the randomness is making sure you have the right tools installed :-

apt-get install rng-tools

Once installed you can test the current set of random numbers :-

dd if=/dev/random bs=1k count=32768 iflag=fullblock| rngtest

This produces a whole bunch of output, but the key bits of output are the “FIPS 140-2 failures” and “FIPS 140-2 successes”; if you have too many failures something is wrong. For the record my failure rate is 0.05% with haveged running (without: tests ongoing).

Links

… to more information.

 Older Entries  Newer Entries