Search Blog


Get the latest on what's happening at itomic

Informative commentary on the web industry from the experts at Itomic.

October 12, 2017

SSL certificates are like condoms: you can have one, you don’t have to use it, but you should.

By Ross Gerring

Website with ssl certificate - green address bar in browser window

Like condoms, there is a major difference between having an SSL certificate, and using that SSL certificate. If you have one, but don’t use it, then you don’t enjoy the benefits.

Using an SSL certificate for your online site or application is a good and important thing. How do we know this? Because Google says so.

How do you check if you have an SSL certificate and, critically, whether it’s any good?

Here’s our favourite test using our own domain name by way of example. Just replace our domain with yours:

You should see all ticks, and no crosses. If you see any crosses for our domain name, please let us know!

If there are any crosses (failures) in the sslshopper report, then you want to get those fixed. No point using a condom if it’s got holes in, right? Speak with your web developer and/or hosting provider.

How do you check if you’re using your SSL certificate?

If you visit the http (non-SSL) version of your site, e.g., does it immediately auto-redirect to the https (SSL) version, e.g. If it doesn’t, then you might have a good SSL certificate available for use, but you’re not using it, and you need to be. Speak with your website and/or hosting provider.

FYI this auto-redirection from http to https is known as “Always On SSL” (AOSSL) or “HTTPS Everywhere“.

Further reading:

Secure your site with HTTPS (Google)
What is SSL, TLS and HTTPS

September 13, 2017

Help Me Help You. What makes a great software bug report

By Ross Gerring

At Itomic we love helping our customers.

Tom Cruise saying "Help Me Help You"

We know that they love the convenience of being able to send an email to our support email address. This action automatically creates a support ticket for them. Thereafter, they can choose to continue the support conversation 100% via email. And/or they can choose to login to our support ticket system to view and manage all current and historical tickets.

But there’s a problem.

By allowing emails to be sent as support requests – instead of forcing clients to fill in structured online forms – the helpfulness of the information initially provided can vary a lot. Often our first (human) response is to ask them to provide all the missing information that will help us to help them better and faster. Anyone who’s ever been the recipient of tech support requests via email will know what we’re talking about.

What’s the solution?

Education. Helping our clients to help us to help them, by letting them know what a great software bug report looks like.

But we can’t expect clients to remember this all the time, to keep a bug report checklist pinned to their monitors.

So this is what we’ve done: each time a new support request is received by email, the auto-response received by the sender contains a brief list of what makes a great software bug report. Sure, it might be too late for the support request they’ve just made.  But we reckon that, over time, this information can only produce better and better results – for everyone.

And what does this checklist look like? Here it is:

  1. Does you website appear to be down (offline)? Is so, use this excellent tool to see if it’s down for the rest of the world, or just you:
  2. A screenshot is worth 1,000 words.
  3. Impact? Is this a mission critical showstopper, or more of an annoyance?
  4. When was the issue first spotted, approximately?
  5. If you’re seeing an error message, please tell us exactly what it says (if the screenshot doesn’t).
  6. Steps to reproduce the issue? If someone else reported this to you, can you reproduce yourself? If we (Itomic) can’t reproduce it, then the issue is *probably* localised to a single PC or your local area network, and you may need to contact your local PC/network support person for additional support.
  7. Is the issue intermittent or permanent?
  8. URL (website address) where the problem is occurring?
  9. Do you have to be logged-in to see the issue? If so, which account are you logged in as (typically an email address)?
  10. Can you think of anything that’s happened recently to your site that might have triggered this issue? Major content edits? Users being added/deleted? New add-ons installed?

Suggestions for improvement always welcome!

August 23, 2017

Your team should be making more software feature requests

By Ross Gerring

Meme - Can't tell if bug or feature requestEver noticed how people (e.g. your team members) are very quick to report bugs in software, but much slower to make feature requests?

We think these are the main reasons why:

1. Assumption that bugs are more likely to be fixed for free.
2. Assumption that software companies aren’t accessible for, or interested in, receiving feature requests.
3. They’re just not thinking outside the box about how the software can and should serve them better. They’re “ok” with the status quo.

To which I respond:

1. Software is increasingly delivered as a paid subscription model. Your subscription is already paying for bug fixing *and* the software’s ongoing development and improvement. Under this particular SaaS model, it’s highly unlikely that the developer will reply with “well, that’s going to cost you $x”.

2. Most software development companies I know are *hungry* for feature requests. It’s the market helping to tell them, for free, which direction they should be travelling. Sure, your request will likely go into a queue and won’t be delivered tomorrow. But much better that it’s actually in the queue and voted for, than not being in the queue at all.

3. OK, you got me, not everyone is hard-wired for out-of-the-box, bar-raising thinking. But if you remind your team of my points #1 and #2 above then perhaps, on the margin, people will feel more empowered to make feature requests than before.

March 16, 2017

What is Always On SSL (AOSSL)?

By Ross Gerring

Always On SSL, or AOSSL for short, is the practice of ensuring that all pages of a website are always forced (in a nice way!) to be using an SSL certificate.

Q. How do you know that a web page is using an SSL certificate?

The closed padlock, the word ‘Secure’, and https instead of http, show that this page is secure. This should be visible in the address bar of your web browser.

The closed padlock and the word 'Secure' shows that this page is secure




Q. How you know that a web page is NOT using an SSL certificate?

The words ‘Not secure’ show that an SSL certificate is not in use. You may also see http and not https. You may also see an open padlock, not a closed one.

The words 'Not secure' prove that an SSL certificates is not in use.




Q. What does “secure” actually mean?

It means that information you’re supplying to a website is completed encrypted, and not visible/readable in plain text to anyone who might be snooping (maliciously or otherwise) on the data being exchanged. You are exchanging data with a website when, for example when you are:

  1. Filling in a “Contact Us” form.
  2. Logging in to a members-only area.
  3. Buying something, i.e. an e-commerce transaction.

When you are exchanging data with a web page, your data is actually travelling across multiple computer networks, with multiple owners of those networks. At an absolute minimum, there’s the owner of your internet connection (i.e. your ISP), plus there’s the data centre where the website is being hosted. In other words, there are lots and lots of touch points between your data and the destination website (hosting server), and therefore multiple potential points where someone – if they really wanted to – could attempt to capture, store and read your data.

Q. How does a web developer force a website to be always-on SSL (AOSSL)?

Here’s a test: try to visit What happens? The URL should get automatically changed to (or possibly a local country version of Google, e.g. or The page went from not secure, to secure. Note 2 things:

  1. http got changed to https
  2. got changed to See for information about this.

You (the visitor) went to visit the website on a non-secure (http) connection, and you got automatically redirected to the https version. And it doesn’t matter what Google web page you visit, you’ll (almost certainly!) get auto-redirected to the https version if you initially attempted to visit the http version.

OK, from a website developer perspective, what we do is:

  1. Ensure that the website actually has a valid SSL certificate associated with it in the first place. The great news here is that there’s no longer any excuse for a website to be without an SSL certificate, because some SSLs are now free:
  2. Add some code to your website which detects if the site is being visited on an http URL, and auto-redirects it to the https equivalent page. Getting more technical, we typically use a thing called a 301 redirect.

Q. Why not just ensure that the pages where information might be exchanged (e.g. a ‘Contact Us’ page) are using the SSL certificate, and not the others?

Two reasons:

  1. Too hard to maintain. It’s technically easier to ensure that all web pages on a website are using the SSL cert, and not just some of them.
  2. Google is actively preferring websites that always have SSL protection, versus those that don’t. Which means that, all other things being equal, a website with SSL protection will rank more highly than one that doesn’t.

Q. Why are sites only now getting on the SSL bandwagon? If all the above is true, surely all sites should have been AOSSL as standard, years ago?

  1. Until the relatively recent advent of free SSL certificates, purchasing an SSL for your website used to be a relatively expensive exercise, especially for small businesses. Therefore many have opted not to bother.
  2. Many websites – even some big ones – offer little or no functional opportunity for a visitor to supply any information. Or if they do, then the information being exchanged is considered to be of low confidentiality or sensitivity, i.e. relative to, say, credit card information.
  3. Google has recently (2016/17) ramping up the pressure to increase security on the web, and one of the ways they can do this is to strongly encourage AOSSL websites by methods that have been identified above.

Q. How do I check if my website currently has an SSL certificate?

Our favourite tool is: Look for all ticks, and no crosses, of course.

Q. My website appears to have an SSL certificate, but isn’t auto-redirecting visitors to the https version. Why not?

It’s one thing for your website to have an SSL certificate available, it’s another for your site to be actually making use of it. That’s where you website developer comes in handy, see below.

Q. How do I get my website to have AOSSL?

Speak with your website developer and/or website hosting company. Don’t forget to remind them that SSL certificates can now be acquired at no cost! That said, note that it’s reasonable for a web developer to charge a small fee to make AOSSL happen on your site, given that skilled labour is required. Itomic does.

March 3, 2017

Itomic en-route to Transform 2017

Itomic is headed to transform 2017 in March to sharpen our senses and stay on top of the upcoming trends in Australian government digital services.


It’s a 2 day conference focused on the business of transforming and (obviously!) improving the delivery of government services, principally by digital means. The venue is the prestigious National Museum of Australia, with workshops and presentations on March 29th and 30th, 2017.

We are attending for two main reasons:

  1. Itomic is privileged to work with a number of government clients, some of whom no doubt we’ll enjoy meeting at the conference. It’s our interest and opportunity to keep bang up-to-date with all the latest ideas, trends, initiatives, challenges, etc. that are impacting, or will, impact our friends in government.
  2. We’re taking the side opportunity for a mini “Itomic retreat” in Canberra. Key personnel from our Perth and Melbourne offices will be there to strategise Itomic’s performance and direction, both independently from, and including, what we learn from the conference.

Speakers are both domestic and international, including:

  • Ben Holliday, lead designer for the UK’s largest government department, the Department for Work & Pensions (DWP)
  • Dan Sheldon, technology consultant, and author of the “Self-Harm Playbook” (how IT in government tends to self-harm!)
  • Ariel Kennan, Director of Design and Product at the NYC Mayor’s office.

All these speakers know that digital transformation in the modern age is necessarily an ongoing process. It’s never “set and forget”. The more we can all get this message out there, the better.

Are you in government, or a service provider to government, like Itomic? As the website says, “Transform is designed for everyone involved in government transformation: service designers, Web designers, front end developers, product owners, product designers, UX experts, user researchers, web, interaction designers, agile and transformation coaches in all levels of government, and independent professionals and agencies who work with them.

We hope to see you there!