Today we're introducing a new category of data to our service called operators. This differs from our previously available providers data as it contains data about who is actually operating an address as opposed to who owns it in the internet address registry.

Adding this extra data is important because it adds context to our responses. Previously If you checked an address and it came back as a VPN you would only receive information about the registered owner of that address. The problem is the owner of that address is rarely the company responsible for running the VPN software from that address.

That is where our new operator data comes in. When checking an address that we know is being operated by a VPN company we will show that extra operator information in both our v2 API result and on our threat pages.

The data we'll be exposing through the API includes the operator name, the level of anonymity they offer, how popular the VPN service is, which VPN protocols they support and specific policies they have such as if they offer free or paid plans, accept anonymous payment options or offer port forwarding and adblocking.

In addition to exposing this data through our API we've also added this data to the custom rules within the dashboard allowing you to block specific VPN operators by name or operators that allow anonymous payment options and the blocking of ads. In-fact we've added support for almost everything in the operator API response to be utilised by your custom rules.

We've also made some general improvements to the custom rule feature itself such as when setting a custom output modifier you can now add multiple pieces of information as a nested array. You can also convert singular values to arrays and then add to their contents. You can see how this is done on the right in the below screenshot.

Additionally we've added categories to the API Provided Values dropdown within the condition section of custom rules as shown on the left in the above screenshot making it easier to find the data you want to use in your rule especially now that we have so many data providers.

Below we've included a screenshot showing one of the new operator cards that appear on our threat pages when using dark mode, there is of course a light version of these cards as-well.

As you can see above the colors featured on the card match the logo of the operator to give a consistent appearance. You'll find this is present for all the operators we've profiled. For example here are some cards for NordVPN, CyberGhost and WeVPN. Three popular VPN operators with distinctive color use.

To access the new operator data via our API you merely need to be using the latest version of our API which is selectable from the customer dashboard version dropdown. If you're already set to always use the latest version then you will have been upgraded already.

This new API version is dated the 2nd of December 2021 and is manually selectable through the API directly when using the version flag, for example &ver=02-December-2021. This can be useful if you want to try the new API version without changing which version your production requests use.

So that's all the updates we have for you today. We would very much like for you to visit some of the links above so you can see the card designs for yourself and we hope everyone is having a great week.

Today we've upgraded our PHP version from 7.3 to 8.1 for our v2 API. This is an upgrade we've wanted to do for quite a while, in-fact we've been running tests against 8.0.x versions of PHP for the past 12 months. It has taken some effort to upgrade our code due to the many changes between PHP versions and specifically the deprecating of old functions and changes to the behaviour of current functions

In addition to those required code updates we had to do a lot of performance testing due to the low latency nature of our API we're incredibly sensitive to code interpreter changes that could introduce performance regressions. And whilst PHP versions 8.0 and 8.1 introduce many great ways to improve performance including AVX instruction use, JIT compilation and improvements to OpCache there can be performance regressions dependant on the methods your code uses.

Often in coding there are a multitude of ways to complete the same goal, even a simple array iterating function can be implemented in many different ways with each having wildly different performance characteristics.

Thus we had to do a lot of performance testing. We've run billions of requests through PHP 8.x since it was released and through this testing we've identified and changed parts of our code where needed to get the best results. This work didn't just happen in the last month but has been an ongoing effort since November 2020 when PHP v8.0 was released.

And so today is the day that our v2 API is finally upgraded to a 8.x PHP branch and specifically v8.1.0 the latest and greatest version of PHP.

With this change we're seeing a steady 25% latency improvement over our previous code which directly translates into being able to handle more requests per second. But remember this isn't just down to us switching PHP versions this improvement also includes all the work we did to bring our code up to the PHP 8 implementation standard. Many of our code changes by themselves have improved performance simply by using newer or faster functions and methods.

One of the pitfalls when doing an upgrade like this is code debt. We now support four different versions of our v2 API and the oldest of these needed more work than our newest to even execute consistently under PHP v8.x. We also had to recompile some of our own libraries that we include within our PHP environment to bring them up to 8.x compatibility.

You may have read in a previous blog post how we had rewritten our caching library. The main reason for this was to bring support for builds of PHP 8.x although we were able to improve performance simultaneously just through the natural iterative design process.

At current only our v2 API is using the newest PHP 8.1 interpreter but we have done testing with the customer dashboard and other parts of our site including administrative backends and it looks promising for a full site rollout over the next few months.

So that's todays update, thank you for reading and we hope everyone is having a great weekend.

When making a request to our API you may be surprised to learn that the majority of the response you receive from us isn't actually JSON data, it's headers.

In-fact an average request to our API results in a 1358 byte response but most of the time our JSON makes up only 448 bytes of that when performing what we call a full lookup containing the most data our API offers. That's a ratio of just 33% JSON to 66% headers.

Which is why we've gone through all the headers we send and removed ones that don't make sense to send in our API responses. Headers that explain encoding, cache times and how you can access the API using a newer HTTP standard will remain as these are important for compatibility and efficiency. But headers for both tracking and debugging our CDN (Content Delivery Network) have been removed.

A lot of these headers are not actually originated by us but are generated automatically by our CDN partner. These extra headers make perfect sense to include with a normal page load where the extra 910 bytes are considered minuscule compared to the almost 1MB size of most web pages today.

But for an API like ours where the JSON is only 448 bytes that extra 910 bytes taken up by headers doesn't make sense. So the end result is today we've managed to reduce those headers from taking up 910 bytes to using 359 bytes. This results in a total average payload size of 807 bytes. This is still sizeable but it's much lower than the previous 1358 bytes and when extrapolated over the billions of requests we handle it really adds up.

The end result of course is you get answers from our API faster as there is literally less data to be transferred. This change has been enabled on our v2 API today and there's nothing for you to activate or change, you should already be benefitting from it as you read this.

This change alongside our activation of HTTP/3 and 0-RTT that we mentioned in our previous blog post are all part of a general efficiency drive we're doing which has included the addition of a new North American server node, operating system upgrades, new webserver deployments and new server-side code interpreters.

One thing we've not mentioned in a blog post until now is we also recently rewrote our server-side database caching system which has resulted in a huge reduction in initialisation time. This is especially important because this piece of code gets initialised on every single API request and so any improvement in startup time has dramatic effects when extrapolated across our entire request load.

We hope this post was interesting, we do enjoy these deeper dives into what we're doing and hope to make these kinds of posts on a more regular schedule.

Thanks for reading and have a wonderful weekend!

Today we've added support for HTTP/3 and 0-RTT across our entire website including all versions of our API. To explain why briefly, these technologies enable us to decrease access latency for establishing secure connections and the resumption of prior secure connections with dramatic results.

HTTP/3 (with QUIC) Explained

HTTP/3 is built using the QUIC protocol which uses UDP instead of TCP and through its ingenious implementation reduces the back and forth chatter between your client and the server you're requesting content from substantially.

Traditionally HTTP requests are initiated by a client sending a TCP SYN to a server which answers by sending back a TCP SYN + ACK then your client sends another ACK followed by a TLS request and a HTTP request which are replied to with a TLS setup response and a HTTP response.

HTTP/3 does away with most of this. Instead the connection is initiated by a client sending both a QUIC request and a HTTP Request simultaneously and receiving back a QUIC response and a HTTP response simultaneously. This reduces the back-and-forth required by traditional handshakes by an entire round-trip.

0-RTT Explained

While HTTP/3 with QUIC enables very fast initial connection establishment by removing an entire round-trip off the handshake process 0-RTT takes this a step further with connection resumption.

This is where those prior handshakes that were negotiated through HTTP/3 can be reused without renegotiation. And the way this works means your client can send a new request for API data in its very first round-trip to our servers.

Performance Implications

The end result is a much faster TTFB (Time to First Byte) and a fast conclusion to the entire API request followed by much lower latency for subsequent requests.

Latency is very important to us because it can be the determining factor in whether our API is deployed in a specific scenario or not. If our API is too slow for where it's needed we could lose a potential customer because of it.

And while we launch these new features today we're currently in the midst of an infrastructure upgrade that will bring improvements in the future too. This morning we deployed a new web server on one of our nodes (NYX) which offers us both new capabilities and opportunities for performance gains across our site and API. It also affords us tighter integration with our CDN (Content Delivery Network) by better matching their capabilities. To put it simply, there is more yet to come.

If you've been using HTTP/1.1 or HTTP/2 to access our API before now there is no need to worry as you still can. For those who already have or are willing to upgrade their clients to support HTTP/3 with QUIC we welcome you to do so, the latency benefits are too good to ignore especially if you're performing millions of requests to us on a regular basis.

That's all the updates we have for you today, thanks for reading and have a great week!

As the service has continued to grow in North America we've continued to invest in new infrastructure to serve those users. Adding new servers to a region doesn't just enable more customers and increased performance, it also provides redundancy against server failures and network malfunctions.

For our new LETO node we've chosen a new datacenter in the United States and we're running this node from what is now the most powerful server in our cluster utilising AMD's EPYC 2 Rome architecture. Previously we've placed one other node in the US and two in Canada run by two different companies, this LETO node is now using a third company.

It's important to diversify infrastructure like we are doing, utilising not just different datacenters but placing them in different regions and having them run by different companies as it's possible for a singular entity to have unexpected downtime. It was only a few months ago that the biggest host in Europe had a total infrastructure failure lasting an entire hour, something we were insulated from due to our use of many different datacenter partners.

As we mentioned above Leto is now the most powerful node in our cluster. In node terms it's the equivalent of two previous North American nodes put together and we intend to make this our new baseline of performance when we upgrade our previous servers or add new ones.

We're still planning a future expansion into Asia with 3 server nodes but due to the chip shortage and the resultant high server prices we've as yet been unable to execute on that. We continue to look for good options though and will take this step when the time is right.

Thanks for reading and have a great weekend.

Today we've made a change to our v1 API (which we sunset and have not supported since March 2020) that essentially replaces it with a translator for our current v2 API. This means for the users who are still making requests to our v1 API you will now actually be making requests to our v2 API and having the result altered to use our v1 format.

This does have a performance penalty of a few milliseconds which is why we've waited to do this now when 99.9% of all our API requests are already made natively to our v2 API. Until now we've maintained the v1 API in a minimal fashion, it was functional but lacked many of our new features and even some of our newer data wasn't available.

With this change the handful of paid customers and a few hundred free customers who have been using the v1 API for years can still do so and it reduces our technical debt in that we no longer need to update the v1 API if we make database scheme changes for instance.

If you're still using the v1 API we would highly recommend you update your implementation to target our v2 API as not only will it be slightly faster in answering your queries but you gain access to a lot more data and features such as safe connection types, Custom Rules and our CORS feature.

Thanks for reading and have a great week!

Today we've refreshed the website with a renewed user interface. This new design brings what we call our glass theme found on our homepage to all the pages of our site for both our slate and snow themes.

Alongside giving our pages a more modern appearance it serves to bring design harmony and consistency. We've loved the topological map design featured on our homepage and we're very happy to now have that available on all our pages.

With this change we've also worked on site design from a functionality standpoint. We've taken extra time to tweak the way our content is displayed across the entire site for smaller screened devices.

Prior to today up-to 25% of your screen may be wasted on empty margins if you were using a phone, tablet or other small display. Now the content can use up-to 98% of your display with only the very smallest of margins making our pages more usable on smaller displays.

Thanks for reading and we hope you love the new design as much as we do.

Today we've enhanced the custom rules feature found within the customer dashboard to support two new conditions and to display the last modified time on your rules thus helping you to keep track of why a rule was made.

The new last modified time looks like the screenshot above, we were able to fit in the modified time without altering the height of the rules which is important when you have many and need to scroll through them quickly.

When saved or toggled whether individually or when using the global controls the last modified time will update on the page in real-time.

In addition to this we've added two new condition types which are Greater than or equal to and Lesser than or equal to. Both of these conditions join our previous Greater Than and Lesser Than conditions but allow slightly expanded functionality so you can use one condition to cover two scenarios and without needing to test how our interpretation of Greater or Lesser is implemented.

We've also made some efficiency changes to how custom rules are applied within our API resulting in lower response times to your queries especially when you use many conditions that compare numbers in your rules.

Support for these new conditions have been applied to all v2 API versions starting from June 2020 all the way to the current August 2021 dated version so you can use the new condition types immediately and without changing your selected API version.

Thanks for reading and we hope everyone is having a great week!

For as long as there has been data to keep there has been data kept for far longer than necessary. This is no less true than when it comes to technology companies. In-fact today tech companies hold so much information about people they may know you better than you know yourself.

And while we're not a large tech company holding lots of private information we do hold some information generated by our customers. Things like your usage of our service and where you're deploying it, the email address you signed up with and some limited payment information if you purchased a subscription.

These are things that we only really need while you actually use our service which is why we recently introduced a self-deletion feature which enables you to both close your account and erase all the associated data we held about you.

Today we're taking this a step further by automatically removing unused accounts. After 30 days from the creation of your account if you've not used it at all (meaning you never logged into the dashboard or made a single query to the API using your API Key) we will schedule your account for deletion and notify you via email.

When scheduled you'll have 15 days to cancel it but these deletions noted above are for completely unused accounts so there shouldn't be much need to reverse the scheduled deletion as you can still signup again when you do need the service.

In addition to this we will be removing inactive accounts after 1 year from their last moment of activity. So if you've logged into the dashboard or made a single API request even once we consider that activity which would push back any scheduled deletion by a year. Similarly to the unused account deletions when scheduled you'll be notified via email and have 15 days to cancel the deletion.

We're making these changes because we think user privacy and the control of your data has been headed in the wrong direction across the tech industry and we want to do our part to nudge the line in the right direction. It's your data and you should always be in control of it and we should turn back time and make it as if you've never used our service when it's clear you haven't needed it in a while.

Thanks for reading and have a great week.

With the release of iOS 15 by Apple a new feature has been enabled for paid subscribers of their iCloud storage product called iCloud Private Relay and it's essentially a VPN service for the Safari browser on iOS 15 and macOS Monterey.

We've been monitoring the service throughout the beta of iOS 15 and we've determined that Apple is using three content delivery networks as partners for this feature which we've been able to detect without issue. Today we've enabled this detection on our API which means by default users of iCloud Private Relay will now be detected as VPN's when visiting your sites and services.

We know that since this is baked into iOS 15 and macOS Monterey it may become a popular service amongst your users and so you may not want to block users from accessing your sites and services when they use iCloud Private Relay.

Due to this we've added a new custom rule to the dashboards rule library (Big Business -> Allow iCloud Private Relay) which when enabled will allow these users to bypass being detected as VPN's while keeping other VPN services blocked. We will say that since iCloud Private Relay is a paid service and most Apple users do not pay for iCloud you may not deem it necessary to whitelist the service but we've made the rule available to you just in case.

Thanks for reading and have a great week.