ASO left with egg on faces but SKY still has plenty of unanswered questions.

Only a day after the Tour de France organisers blocked Chris Froome from starting the race on Saturday, cycling’s governing body, the UCI, has cleared him of wrongdoing relating to an adverse drugs test from last September’s Vuelta a España.

ASO, who organise the le Tour, used a little-known clause in their rules to block Froome on the basis that he would bring the race into disrepute. They were keen to avoid a rider from starting -and probably going on to win- the race who could potentially be banned due to the ongoing investigation. 

Then, out of the blue, the UCI concluded their 9 month investigation into excessive levels of Salbutamol in Froome’s urine dating back to a single stage of the Vuelta last year. Froome went on to win the race. But that was not without controversy…

In the meantime, the Tour’s organisers look like they acted prematurely and possibly out of malice in blocking Froome and subsequently backing down.

On the day of the adverse drugs test, Froome had stormed the peleton to increase his grip on the race on a tough mountaintop finish to Santo Toribio de Liébana. The previous day he’d looked down and out, conceding 40 seconds to all his rivals and appearing to be dropped by his own teammates on the savage final climb. 

There were many eyes raised at this startling recovery. The reason most often cited was the Froome had saved his legs on stage 17 in order to attack on stage 18; his rivals having done the opposite had committed a tactical error. For Froome’s critics, the adverse finding was yet more evidence of pushing into the grey areas of performance-enhancing use of therapeutic drugs. 

The team SKY philosophy has always been to race clean one the one hand, but to use all legal mechanisms for marginal gains on the other. The theory being that totting up a large set of marginal gains adds up to genuine gains. There’s no denying that where SKY have led, others have followed. They were the first for example to recognise the value of a good night’s sleep for riders to such an extent that the riders mattresses, pillows and bedding traveled with the team. This is now commonplace across many competitive sports. Likewise basic hand hygiene. Many of these are borne from the team’s early beginnings in British track cycling. 

But SKY have been noticeably shy -and indeed shifty- about use of medicines. In evidence to the House of Commons, director Dave Brailsford and team medics cited various excuses: medical confidentiality, loss of records and so on for being able to answer some sharp questions. 

The questions for SKY and Froome himself can be boiled down to: 

• How were all the issues with the Vuelta adverse finding resolved so quickly once Froome was blocked from starting le Tour?
  
• Why does the team recruit so many asthma sufferers?
  
• Why don’t the team doctors prescribe rest or conservative treatments rather than extremely high doses of medicines?
  
• Why does the team refuse to sign up to the MPCC-Mouvement pour un Cyclisme Crédible?
  

While these questions go unanswered or dodged there will be a nasty taste in the mouths of the cycling community. Something looks and smells very off about this. 

I started reading this blog from the Google Artificial Intelligence team with some scepticism. “Another article about speech recognition; what’s the point. Telephone calls will die out within a few years anyway”. That’s not just prejudice on my side. Although I do admit to having a sense of trepidation when I have to call a business to get something done. Research shows that most young people never listen to their voicemails; they reject or ignore calls unless it’s some they are expecting and only make calls themselves in emergencies (with a loose definition of emergency; as any parent can testify.)

In fact I’m guilt of doing almost anything to avoid the awkward interaction of making phone calls to strangers. Especially if I might be interrogated by a voice recognition system first, then put on hold and then have to repeat all my information to a human.

So why is the Google AI blog of any interest? It took a while for me to get the gist; the tech isn’t for receiving calls -it’s for making them. 

When this penny dropped my mind already raced ahead - I could get my phone to make calls for me to perform standard tasks with places who don’t have online bookings or enquiries. Like reserving a space for a bike on a train, or booking my dogs into their kennels. Or even doing a ring round of a load of restaurants to find a table at the last minute. I might never have to call anyone ever again. Google plan to build this functionality - in a limited way- into their phones very soon.

The challenges aren’t trivial: 

“When people talk to each other, they use more complex sentences than when talking to computers. They often correct themselves mid-sentence, are more verbose than necessary, or omit words and rely on context instead; they also express a wide range of intents, sometimes in the same sentence…

“In natural spontaneous speech people talk faster and less clearly than they do when they speak to a machine, so speech recognition is harder and we see higher word error rates. The problem is aggravated during phone calls, which often have loud background noises and sound quality issues.

“In longer conversations, the same sentence can have very different meanings depending on context. For example, when booking reservations “Ok for 4” can mean the time of the reservation or the number of people. Often the relevant context might be several sentences back, a problem that gets compounded by the increased word error rate in phone calls.”

On the blog there are some great examples of real calls using the system. The voice sounds really natural - well it’s American so the intonation is all over the place anyway. But natural to my ears.

Go ahead and listen to some of the examples on the blog; then imagine a future where you never put off a task because it involves making a phone call. Just get your phone to do it for you.

Password68 * - is not a good password, but it met my corporation’s complexity requirements. And, as the next month rolled along, it was easy to figure out what to change it to. When you’re typing your password hundreds of times a week, it’s important that it’s very easy. 

The National Cyber Security Centre (NCSC) has published a load of up to date password advice. All of it is very very sensible; but much of it flies in the face of conventional wisdom and current corporate security policies.

In particular system administrators will be surprised to find the advice not to force users to change their passwords regularly (known as password ageing). It’s great news. I felt guilty every time I had to change at my previous job, knowing that I should change to something truly unique, but instead I just incremented the last two digits every month. 

NCSC give exactly that reason for not enforcing password ageing, instead they recommend that passwords are only changed when they’re compromised. They also warn to beware of putting too much faith in complexity requirements or complexity meters. Users will simply engineer a weak password which meets the requirements, and that makes it much easier for hackers to guess. Instead the recommendation is that users are offered a choice of strong passwords which have been generated for them. 

It seems weird that this stuff has come full circle. In 1999 I was implementing a system for the MOD. We offered users a choice of three passwords at password reset time, Each was made of three short words, all lower case, no numbers or special characters. These passwords were really easy to remember but very hard to social engineer, shoulder surf and highly repellant to dictionary attack, despite being made up of real words.

Likewise I remember a kerfuffle 15 years later on a different secure system where overnight we had to force users to move from 9 character to 10 character passwords. This was because supposedly a 9 character password had become hackable by brute force in less than the 30 day password ageing period. In reality most users simply added an extra digit onto the end of their existing password. Security wasn’t improved at all. And we upset everyone who came into work the next day and had to change their passwords, out of sync with all their others.

If you think your email address and password have been hacked - there is a great site to check: https://haveibeenpwned.com/ 

I know from bitter experience that my email address and a previous password were sold online in a hack some years ago. Google, amazon and others spotted the suspicious activity and blocked the login attempts. My netflix account was compromised though, the password was immediately changed and my account was ‘sold on’ at a bargain price to someone else. 

Due to my daughters’ deligence (ie almost constant netflix watching) this was spotted and recovered almost straightaway. The man in the Netherlands who’d ‘bought’ my account was presumably very perplexed that the Dutch version of Top Gear suddenly stopped playing.

Needless to say I’ve got different passwords for each of those accounts now. Netflix is quite clever in that you can change the password but allow currently logged in devices to stay logged in. So I can change the password to something very long, random and complex and leave that stored in a password manager (another recommendation from NCSC) without forcing my family to type in something stupidly long themselves; unless they change device. Similarly amazon now has easy to use two factor authentication. Any new device trying to log into my account prompts a text message to me with a passcode to be input at the device itself. 

Google seems to understand that a login from a brand new device in south america while I’m still logged in to my phone and laptop in Yorkshire is likely to be suspect. They block it and let me know. Again this is the best practice advice from NCSC. Keep users up to date with information instead of trying to make them jump through hoops.

You can read the full set of guidance here:

https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach

* Password68 was never my actual password, although my corporate password wasn’t really much better. I ashamed.

An autonomous Uber vehicle which fatally killed a pedestrian on Sunday might have had Volvo’s safety features disabled. 

The National Transportation Safety Board are investigating whether the top of the range Volvo XC90 had features removed or disabled. If so why and by who. The NTSB told me “These questions will be part of the investigation. We hope to put out an update later today”.

Volvo puts much store by the safety record of its vehicles. They have a well publicised vision to have zero fatalities caused by their vehicles by 2020. The XC90 model used in the Uber tests is equipped with it’s own radar to detect cross traffic at junctions and to brake and steer around pedestrians who step out into the road. This technology has been standard in Volvos for nearly a decade. In Sunday’s crash either the Volvo failed, or it had been modified.

Self driving cars rely on a system of lasers and radars to read the road and detect obstacles. “This is exactly the type of situation that Lidar(laser radar) and radar are supposed to pick up,” said David King, an Arizona State University professor and transportation planning expert. “This is a catastrophic failure.”

There is a harrowing video of the collision which shows the car striking Elaine Herzberg as she crosses the road pushing her bike. 

The video “strongly suggests a failure by Uber’s automated driving system and a lack of due care by Uber’s driver”, Bryant Walker Smith, a University of South Carolina law school professor and autonomous vehicle expert, said. He noted that the victim is visible about two seconds before the collision, saying: “This is similar to the average reaction time for a driver. That means an alert driver may have at least attempted to swerve or brake.”

The video looks dark and everything happens very quickly. But that is no excuse. The whole point of lidar and radar is to read the road and prompt the autonomous car to react. The incident throws into doubt the viability of self driving cars in anything but strictly controlled conditions such as motorways.

In most countries, tampering with the safety features of a car which is subsequently involved in a fatal crash would amount to criminal negligence. It remains to be seen what action the NTSB is able or willing to take.

Uber when asked about this referred me to the NTSB. Volvo said: “We are aware of the incident and have seen the disturbing and upsetting video. Our thoughts remain with Elaine’s family and friends. Uber is cooperating with local and national authorities and Volvo is assisting in these investigations.”

https://www.theguardian.com/technology/2018/mar/19/uber-self-driving-car-kills-woman-arizona-tempe

My claim is that no self driving fully autonomous car* will be available in the next 10 years. 

*my definition of this car is:

• publicly available to purchase
  
• can travel autonomously from point at random chosen in mainland england/scotland/wales to any other mainland destination
  
• no supervisor is required - ie all the occupants could asleep or the car could be empty
  

read more here: https://m71ohr.tumblr.com/post/170117731906/stockholm-gets-driverless-buses and https://m71ohr.tumblr.com/post/168076580311/driverless-cars-v-pig-kidneys?is_related_post=1

Patching: It’s like cleaning the filter on your dishwasher. Never a nice job, never the right time to do it. But if you leave it long enough, your plates and glasses will start coming out greasy and you’ll eventually flood the kitchen.

Also, fundamentally, it’s very easy and the more regularly you do it, the easier it is. You have to start by accepting that it’s a job that must be done. And…if no one else is already doing it, then probably safe to assume it’s your job.

The Register report today that IBM haven’t bothered to patch the server estate for New South Wales transport authority for at least 10 years. They’ve put a desperate call out for staff to volunteer for a few weeks of midnight rebooting of mission critical unix, linux and windows servers. 

But actually they could just hire me. 

I won an award for rescuing a customer account by sorting out their long standing patching issues. In fact the award was for taking the work I’d done for this customer and turning it into a generic approach to patching.

This customer had a particular set of requirements due to their trading day across different time zones. The only time they cope with downtime was 6-8pm on a Saturday. Not the most popular slot for which to find volunteers. Most other customers have their own set time. Midnight friday or saturday always seem popular. I had another who liked 8pm on a monday night.

This customer was not really any different from any other. They were hopping mad that no patching had been done. And the various support teams were all claiming that someone else should be responsible.  After some weeks negotiation we came up with a plan. Based on the microsoft patch cycle of Patch Tuesday releases:

• Week 1: OS 3rd line support -analyse the patches and inform the application owners what is gonna be applied where
  
• Week 2: patch the test environment
  
• Week 3: patch production site
  
• Week 4: patch the standby site
  

Same monthly cycle for linux.

So in week 3 the customer took 2 hours downtime at 6pm on a Saturday evening. If apps weren’t back up and running by 8pm then we had the option to failover to the unpatched standby; likewise if something cropped up during the working week we could failover. We also had 2 weeks grace period before the patches landed in production for any installation or side effect issues to become public.

As you can see, there was nothing really clever in the plan. There was however a smattering of clever stuff in my scripts that rolled out the patches and orchestrated the reboots. The service desk expected stuff to flicker red and amber on their monitoring screens but knew to phone me if it hadn’t settled by about 6-45pm. I  gave my phone a quick check for automated progress update emails and waited for the all clear signal that everything was back up.

I rolled out the same approach and scripts to other customers and our internal systems and re-used 5 years later when I took over a secure platform which had never been patch since installation. It really wasn’t that hard. The award was probably more for the creative accounting to show how ‘financial benefit’ of doing this. In reality we were guessing. But none of my systems ever suffered an exploit due to missing patches.

IBM have taken the first step by accepting that they need to do something. Next step is to hire the right person; I’ve got my passport and shorts on standby.

OK. It was never Barcelona versus Real or England v Germany or even on the scale of VHS v Betamax. But there was a battle for the format of emails which raged at the turn of the millennium the outcome of which left us with a sour legacy.

GCHQ are patiently trying to help businesses secure their email and admirably trying to put the genie back in the bottle: https://www.ncsc.gov.uk/blog-post/making-email-mean-something-again 

But it could have all been very different. If only us messaging geeks had won and the unix sysadmins hadn’t been quite so promiscuous. 

X.400 had been the standard for email long before the world wide web was even a thing. It’s rival SMTP/Mime (now just called SMTP) was an upstart. The upstart won over the whole technology stack in the end. Even people who new it was wrong gave in. 

I first used X.400 supporting a messaging system for the NHS. It was mostly data being transferred; pathology results, xrays, prescriptions, purchasing etc. Very few messages left NHSnet. Person to person messages were rare. I later moved onto look after systems for the RAF and crucially a system that ran the financial transactions between European central banks that would later become the Euro currency. 

But X.400 was superb at this job. It was super secure, reliable, trustworthy. SPAM and junk mail was almost impossible. Every step of the message transfer process trusted every other step. X.400 handled attachments superbly, perfect for shuttling documents, financial transactions, images, encrypted messages etc.

SMTP on the other hand was invented to be simple. Simple to setup, simple to send. It was quick and dirty, literally. It was loved by unix system administrators who used it fire status messages around the computers they looked after into a central mailbox. It was designed for text messages only. It was (and still is) awful with attachments.

X.400 imagined a closed world where large central mail servers all trusted each other and where any email sent was guaranteed to be delivered, somehow. SMTP on the other hand was much more open. More like the postal system, where anyone with access to an envelope could post a letter to anyone they knew the address of. X.400 relied on trusted predetermined routes, SMTP on the other hand relied on the new technology of DNS. 

I dug out this old paper http://www.ittoday.info/AIMS/DCM/52-30-01.PDF which explains the differences in more detail. It concludes that X.400 and SMTP will converge into one format at some point. The author couldn’t have been more wrong.

At the same time, those of us in the front line waged a battle on forums, at the coffee machine; defending X.400 against the SMTP onslaught. 

I knew we would lose. For the same reason that VHS beat Betamax. VHS won out because it was much cheaper, although massively technically inferior. Betamax in fact lived on as the video format of choice for professionals until very recently.

X.400 was more expensive to manage. It needed skilled people. It had a much worse issue for users though. And this is what killed it. It didn’t matter how many times we tried to explain that no-one actually needed to know anyone else’s email address because we would all be using directories; it was the format of the address which killed it.

the very simplest email address you could have would be something like:

C=UK;A= ;P=gmail;O=hillohr;S=Ohr;G=Martin

It could be much much worse depending on how your company had setup it’s mail. Worse still, if you wanted to send an email to someone who only had an SMTP email address on the internet (and there were quite a few people at the time)

their address to you would be something like: 

C=UK;A= ;P=gmail;o=goole;cn=internetgateway;RFC-822=J.Bloggs(a)hotmail.com

while your address to them would be something even worse:

‘G=Martin/S=Ohr/O=hillohr/P=gmail/A= /C=UK’@google.com

it hardly trips off the tongue.

Whereas SMTP had the email address format we all know and love now.

The battles raged. X.400 was the backbone of every ‘proper’ messaging system. Microsoft’s Exchange, the worlds most successful email server seemed to have it cracked. It used X.400 in the background but exposed a lovely easy to use directory to users and was happy to accept the SMTP address format for emailing people outside the organisation.

“There” we said. That’s how you do it. The friendly email address, with the rock solid technology underneath. But website developers were having none of it. They wanted their webservers to be a able to ping out an email. Easy as pie. Without having to worry about the messy business of knowing the password for a central mail server, in fact without having to worry about knowing what their organisations webserver was called. They didn’t want to talk to the annoying messaging geeks. And they wanted to have the sender’s address as anything they cared to configure. 

They wanted to eat their cake and have it too.

But all this openness was about to bring down a storm, or maybe an avalanche. 

You probably don’t get that many penis enlargement emails any more. But that’s because you company, or google or whoever it is you trust, is already filtering out at least 80% of your email. They invest millions of pounds per day in effort holding back the tide. It’s never got any less.

In the early days it was good for messaging geeks. Sure we weren’t sorting out the shared password between MTAs anymore. But we were gainfully employed trying to stop spam, and porn and viruses.

SMTP’s open system and it’s terrible handling of attachments made it so easy. Spoofed emails were until a couple of years ago trivial to create. Me and my colleagues used to send them for fun on a rare quiet afternoon. But they are still one of the main sources of phishing attacks. Likewise the way that SMTP handles attachments is to convert them to text. It’s very messy and never been properly fixed. It’s a ripe area for malicious code because the attachments and message text are only separated by carriage returns. It’s trivially easy to make an executable look harmless. 

Even with the best efforts of the current technology SPAM is rife, spoofed emails are very common and viruses make up 50% of email traffic. None of these were possible with X.400

GCHQ and others are slowly trying to fix. If only we could turn back time. Maybe we would have battled a bit harder.

Way back in 2012 I wrote a post on this blog about Lance Armstrong. At the time he was still denying having cheated or having taken any sort of performance enhancing drugs. My post attracted hundreds comments. At least 80% of them defending Armstrong and criticising me. Within a 12 months he was on Oprah confessing all and asking for forgiveness. 

I don’t write this to blow my own trumpet. But because SKY are in so much trouble it’s worth a re-read. The parallels are pretty clear. Just as I claimed 6 years ago that everyone knew Armstrong was a doper. I think most sensible people are coming to the same conclusion as me about Team SKY: namely that while they might not have broken the rules, they have most definitely cheated the Therapeutic Use Exemption(TUE) process. 

And to be clear: I was no mind reader about Armstrong. I just had my eyes and ears open:

Keep reading

Great article from the National Cyber Security Centre(NCSC); which is part of GCHQ. 

https://www.ncsc.gov.uk/blog-post/trouble-phishing/

I know of one large organisation which decided to Phish it’s own users as part of an education campaign. 

Keep reading