In MIDAS v4.37, we’re deprecating some outdated privacy and security settings.
In this post, we’ll outline what’s changing and explain the reasons behind the decision to remove these options.
“SSL Access” setting has been removed
In the early days of the World Wide Web, you connected to websites over “http”.
“http” connections were not secure and could be intercepted. So along came “https”, which allowed visitors to connect to websites over encrypted Secure Socket Layer – or SSL – connections.
However, adoption of “https” was initially slow by the majority of the World Wide Web. Primarily, this was due to SSL certificates being very expensive. Large financial institutions were naturally quick to jump on https. However, the price of SSL certificates put securing websites with https out of reach of the average webmaster. Especially when the cost to renew them every 1-2 years was factored in.
Now, as you may know, we’ve been developing our web based MIDAS room booking software for nearly 20 years now! When we first began to offer a “cloud hosted” booking system to customers (way back in 2007), SSL/https use around the web was not wide spread, and was expensive to implement.
Initially in 2007, we offered our cloud-hosted customers the option of being able to access their hosted MIDAS system over secure https. This was available via an optional (paid) addon for their scheduling system.
By June 2011, we’d recognized the importance and benefit of secure SSL connections for all our customers to their MIDAS systems. We therefore introduced better support for secure SSL connections with MIDAS v3.13.
As part of this, we added a new “SSL Access” setting to v3.13. This allowed administrators to control whether insecure http and/or secure https connections would be permitted to their MIDAS system.
In August 2012, we then took the further decision to include an SSL Certificate to enable secure connections for all our existing and future cloud hosted customers. At the same time, we enforced https connections to all hosted MIDAS system.
Consequently, the “SSL Access” option first introduced in MIDAS v3.13 became redundant for our cloud-hosted customers. Since 2015 and MIDAS v4.09, this option has no longer been available in cloud-hosted editions of our booking system.
In the following years, gradually the cost of SSL certificates reduced. Then in 2016, along came a game-changing service called “Let’s Encrypt“. Let’s Encrypt offered FREE SSL certificates for all. This finally allowed every webmaster the ability to “secure” visitor connections to their websites at zero cost.
In May 2018 we migrated all our cloud-hosted customer’s SSL certificates from expensive GlobalSign certificates to ones issued for free by Let’s Encrypt instead.
Now, in 2024, SSL/https certificates are the norm – in fact, all modern web browsers now alert you if you attempt to visit an insecure website via http.
So whilst we removed the “SSL Access” settings in cloud-hosted MIDAS systems back in 2015, we’re now also removing these settings for self-hosted customers starting with MIDAS v4.37.
“Allowed IP Range” setting has been removed (self hosted editions only)
The “Allowed IP Range” setting is one of the earliest security settings we provided in our room booking system. In fact, it was first introduced in v1.35 back in August 2007.
The setting allows an administrator to restrict access to their MIDAS system to an IP address or range.
This can be useful if a MIDAS system is hosted on a public-facing web server, which potentially could be accessed by anyone worldwide. The “Allowed IP Range” setting can be used to restrict access to users in your own country, organization, or to just you!
However, one of the limitations of this setting is that it only supports ipv4 address, and not ipv6 addresses.
Also, in the years since this setting was first introduced, other security and firewall products are available which provide greater control over access to websites, apps, and servers.
Therefore, starting with MIDAS v4.37, we have removed the “Allowed IP Range” setting in self-hosted editions.
If you’re a self-hosted customer and wish to restrict access to your MIDAS system by IP address you should consider other options to achieve this.
For instance, on Apache servers, you can easily allow/deny access by ip address/range in your httpd.conf or .htaccess files. For more information, please see Apache’s guidance on access control.
“Do Not Track (dnt)” has been superseded by “Global Privacy Control”
“Do Not Track” – or ‘dnt’ for short – was an official HTTP header first proposed in 2009. It was intended to allow user to opt-out of tracking by websites.
By 2011, all major web browsers had implemented support for the proposed “Do Not Track” features.
In 2017, with the release of MIDAS v4.16, we included an “Honor user’s Do Not Track preference” setting.
If enabled (and if an end-user had also enabled the “Do Not Track” feature in their browser), MIDAS would not log the user’s IP address in the Recent Activity Log.
However, globally, recognition and support of the “Do Not Track” HTTP header by websites was poor. So much so that in January 2019, the “Do No Track” HTTP header was officially deprecated. A month later, Apple removed DNT support from their Safari browser.
Whilst some other browsers still continue to offer a “Do Not Track” setting, it has since been supersede by a new “Global Privacy Control” – or GPC – header.
At time of writing, Global Privacy Control is still classed as an “experimental” and “non standard” technology, and it’s behaviour may change in the future.
But for MIDAS v4.37, we’ll support both DNT and GPC features. The “Honor user’s Do Not Track preference” setting will be renamed to “Honor user’s privacy preferences” to reflect this.
It’s likely that in a future update we’ll fully drop support the deprecated “DNT” header. At time of writing though, as some browsers still support it, we’ll continue to support it too.