We are aware how important your secure, confidential data is, and Visual Crossing takes great care to ensure that any confidential data entrusted to us stays completely confidential. Fortunately, you will find that Visual Crossing rarely handles and never stores confidential data except in very special and completely optional situations entirely under your control. (These will be discussed below in detail.)
We have specifically architected our system to have the minimum attack surface area possible as well as a zero payout for the attacker even in the case of a successful attack. Doing so reduces our costs allowing us to pass the savings onto our customers and gives you one less weakness to worry about when conducting security reviews.
In addition, we leverage industry-leading solutions to maximize the reliability and security of our system. Our production system is implemented using Amazon Web Service (AWS) technologies including their robust, multi-zone hosting platform; dynamically-scalable database solutions; and globally-accessible load balancing. For account management and payment processing, we use Stripe payment solutions to ensure that user data is optimally secure and all payments are processed securely without Visual Crossing itself needing to hold your payment details.
In this article we will discuss the various types of sensitive customer that Visual Crossing may handle, how our architecture ensures that data does not become compromised, and how you can reduce your minimal exposure even further by using some common-sense techniques.
To make optimal use of our service, we do require you to have a Visual Crossing Weather account. While some of our weather services are available for users without an account, those are generally limited to our dashboards and data previews.
In order to create a Visual Crossing account, the only required information is an email and a password. While you should always use best practices (such as those outlined by Microsoft) when selecting a password, we also take industry-standard measures to ensure that your account remains secure. We use a one-way hash when storing your password within your account. This allows our system to validate your password without ever being able to recover the actual password itself. This means that it would be practically impossible for an attacker to recover your actual password from our system even if he or she gained full control of our servers.
In addition, no one at Visual Crossing will ever ask you for your password via any channel. If someone ever asks you for your Visual Crossing password do not share it, and instead please contact our support team at firstname.lastname@example.org with as many details on the incident as possible.
If you are ever concerned that your Visual Crossing password has been compromised, you can easily change it online by clicking on the ‘Account’ button in the upper right-hand corner after you log into on our website. Then simply click on the “Change password” option. If you have any questions or problems doing this, please contact our support team for assistance. Likewise, if you forget your password, you can use the password recovery option on our login page.
For our payment and billing, we have partnered with industry-standard payment processor, Stripe. They handle the collection of billing information, credit card details, and all related data for our standard accounts. Rest assured that even when the form requesting this information is on a Visual Crossing page, we are embedding Stripe’s secure controls to do the collection and management. This means that Visual Crossing is never in possession of and never has access to your credit card billing details. It would be impossible for someone attacking the Visual Crossing infrastructure to gain access to this sensitive information.
Note that in the case of custom billing via invoicing or enterprise plans, Visual Crossing will be required to collect your billing details directly. However, payments at this level are never processed via credit card. They are typically handled via wire payment or other business-to-business payment options. In all cases, those payments are initiated by the customer, so there is no way that Visual Crossing could use that information to trigger an unauthorized payment on your behalf.
Your API Key is assigned by Visual Crossing and attached to your account. It is used by our servers to authenticate API requests as coming from your account. Although your API Key is stored in your account record, simply having an API Key does not allow those outside Visual Crossing to look up any additional details about your account.
However, having access to your API Key does allow any third-party to make weather queries using the privileges of your Visual Crossing Weather account. For this reason we request that you never share your API Key with others. Also this is the reason that you can request a new API Key at any time instantly via your online account page. Simply log into your Visual Crossing account, click on the Account button in the upper right and then click on the ‘Change Key’ option under your API Key. This action will invalidate your existing API Key and issue a new key immediately. You should do this right away any time you think that your API Key may have been compromised. You can also request help on this from our support team. However, since you remain responsible for all query activity associated with your API Key until it has been changed or deactivated, we highly recommend using the ‘Account’ section on our web page to change your API Key right away if you have reason to believe that it is compromised.
The Visual Crossing weather servers use your API Key to verify your license levels prior to running the query. This is done so that our servers do not need to directly store and manage your specific account and billing details. Your information remains stored securely in the repository of our 3rd-party payment processor Stripe. At no time in this transaction is your personal data sent to Stripe or back to our system.
The weather queries that you submit to Visual Crossing contain an explicit location or a date or date range that may be either explicit or implicit (in the case of forecasts). In most cases this combination of date and location is not considered confidential information. If you are querying weather information for store locations or active construction projects, for example, it is very likely that the query information that you submit to us could be easily obtained from another public source such as the store finder widget on your own website. If this is your usage situation, you can likely skip the remainder of this section.
However, in some cases, the query location alone or coupled with the a date can expose confidential business information. Consider the situation where a business is scouting for a new location and needs the locations being considered to be kept secret from competitors. The first thing to note is that Visual Crossing Weather does not store your API query requests (with the exception of user-approved debugging discussed below). In addition, we use encryption for all communication to and from our servers. So, your query requests are safe from man-in-the-middle attacks and bad actors “sniffing” your network traffic.
However, for those concerned about avoiding this vulnerability during the brief but existent window while our weather servers are processing your data, there is an easy way to structure your query to solve the problem. Since weather conditions apply to an area and not just a specific point, it is quite easy to give a more general location than required. The easiest way to do this is by removing some decimal precision from your latitude and longitude location values. It is already a best practice to pass latitude/longitude pairs instead of textual addresses as the location for your weather queries. (This ensures that you have complete understanding and control of the exact location being queried.) However, using latitude/longitude values with limited decimal precision can also be a valuable security strategy when your locations are sensitive.
It is useful to remember that four decimal places of precision in a latitude/longitude value is equal to approximately 11 meters (about 35 feet) of location accuracy. This is about the same accuracy as a high-quality GPS device without special correction procedures. Since weather data cannot currently be tracked below the 10-meter level, making a query using more than 4 decimal places of precision is unnecessarily wasteful. The third decimal place of the latitude/longitude values provides about 110 meters (about 350 feet) of accuracy. This level of accuracy generally does not allow a bad actor to identify a specific building. However, it may allow the viewer to identify a large plot of land or campus of buildings. Since this level is still higher accuracy than weather stations and forecast models, you can safely pass only 3 decimal digits and reduce the likelihood that someone viewing your latitude/longitude values can identify the specific address that interests you. Two decimal places on latitude/longitude values provide an accuracy of about 1.1km (about 0.68 miles). This level of accuracy covers a small town making it practically impossible for a nefarious viewer to learn anything specific about the location that you are searching. As before, since weather stations and forecasts generally are no more accurate than this, passing 2 decimal digits in your latitude/longitude queries will give you the weather results that you want while greatly limiting the useful information that can be gleaned by a nefarious viewer.
So, the short summary is that querying our service using latitude/longitude values with 2 or 3 decimal places of precision is an ideal way to get both accurate weather data and conceal the specific location of your query in the highly unlikely even that a bad actor sees your query string. In addition, doing queries in this way also improves the performance of your queries.
A similar trick can be done with query dates, if your specific date is confidential. Simply query a date range that includes the specific date of interest. Even if a hacker is able to view your query, they will be uncertain which date in the range is important to you.
An optional API feature that you should also use with caution if your use case has a high requirement for data security is the Name parameter. This parameter allows you to specify a custom value in the query that will be passed directly through to the output results. This value is intended to make it easy to join the result data back to its source business record. However, when you are concerned that your query request may be viewed by a nefarious agent, then a Name value is provided in your query input could give a bad actor extra information. One way to avoid this concern would be to use simple numeric ID values such as 1, 2, 3 instead of more descriptive values such as “NewHQ_1”, “NewHQ_2” and “NewHQ_3.” An even better option, however, would be to not supply a Name value at all in your request. You can simply skip this value entirely and, when necessary, join back to your business data in a different way. Doing so would completely deprive prying eyes of any additional information.
It is also it important to note that if you use the Visual Crossing web-based Query Builder and save your query either for downloading or scheduling purposes, by definition we need to store your query details including the location(s) and date(s). If you consider your locations and dates confidential, you can simply avoid using our Query Builder and thus avoid this concern entirely. Everything that can be done in the Query Builder can also be accomplished via our API.
One final note, as mentioned above, when our support team is working with you to debug a technical issue, we may request to put a trace on your account in order to log your query details for review. This logging is only ever done with the direct permission of the customer, and the results are only made available to the necessary support engineer(s) working on your specific issue. However, if you are concerned about your query data in this context, there is a simple resolution. If our support team makes this request to you, you can simply deny our request to enable this logging for your account. We will never enable this logging without your permission and nearly always can find alternate ways to debug issues.
Visual Crossing has designed its system carefully to avoid, wherever possible, Visual Crossing storing and even directly handing sensitive data including credit card details and query details. This means that in most applications, Visual Crossing itself is not a security concern. This is especially true in use cases where weather query locations and dates are not considered confidential information. However, even in the use cases where query locations and dates are sensitive, it is quite easy to architect your usage pattern as described above to ensure that the information passed to Visual Crossing is never specific enough to be a security risk.
Of course, Visual Crossing uses industry best practices to help ensure that its networks and production servers are as secure as possible. However, it is even better for you, as a weather query user, to make the minor adjustment to your usage to ensure that you never need to worry about the robustness of Visual Crossing security in relation to your data.
Should you have any additional questions or need more information on this or any other weather data topic, please reach out to our support team at email@example.com.