So you‘re looking into UserVoice but wondering if you‘re even allowed to use it and if it‘s safe. Don‘t worry. The more than 160,000 organizations that use UserVoice asked the same questions, but we understand it‘s still important to find out on your own.

If you‘re interested in our policies, definitely check out our Terms of Service and Privacy Policy. We strive hard to make those as human and readable as possible (while still keeping our lawyers happy). However, if it‘s compliance and security you‘re worried about, then you‘ve come to the right place.

Compliance

UserVoice is Section 508 Compliant.

Section 508 Compliant

UserVoice is section 508 compliant & WGA1 (Levels 1, 2) compliant. This means we‘ve built UserVoice to modern standards to ensure that UserVoice sites are as accessible as possible to those using screen readers or other accessibility technology.

UserVoice is Safe Harbor Compliant.

Safe Harbor

Our datacenters are all in the United States (Dallas, TX) but we‘re self-certified Safe Harbor compliant. That means all of our friends in the EU won‘t run afoul of EU privacy protection laws by using UserVoice. Don‘t believe us? Check out our record with the US Department of Commerce.

UserVoice is PCI DSS Compliant.

PCI DSS

UserVoice doesn‘t store credit card information in our database (all credit card data is stored securely in our payment gateway, Braintree, which is also PCI compliant), but credit card information does transit through our system so we‘ve verified as Payment Card Industry Data Security Standard (PCI DSS) compliant. This compliance is handled by SecurityMetrics and includes a self-questionnaire and quarterly security scan (last scan March 15, 2013) of our servers.

UserVoice is able to be used by U.S. Government entities.

We've worked with the GSA to amend our standard Terms of Service to comply with restrictions specific to United States federal laws and regulations. The complete details of this amendment can be found here: Amendment to UserVoice Terms of Service.

Data Security

As is common for software-as-a-service vendors, UserVoice runs on leased servers provided by Softlayer technologies, located in Dallas, TX, to deliver our service.

UserVoice‘s hosting provider Softlayer is SSAE 16 certified.

SSAE 16

SSAE 16 (Statement on Standards for Attestation Engagements) has replaced the Statement on Auditing Standards No. 70 (SAS 70) as the primary standard for reporting on controls at service organizations. It is an attestation standard issued by the American Institute of Certified Public Accountants (AICPA). Specifically, SSAE 16 addresses engagements conducted by service auditors on service organizations for purposes of reporting on the design of controls and their operating effectiveness. See Softlayer certifications.

Access to all UserVoice servers is secure.

  • Firewalls (IPTables) on all servers are set to default-deny. The only services that are allowed are SSH (all servers; non-standard port) and HTTP/HTTPS (web servers only).
  • Database connections are only accepted from other UserVoice servers on the internal private subnet. No other organization‘s servers reside on the UserVoice subnets at Softlayer.
  • All communication with servers (outside of public HTTP/HTTPS access) is over encrypted secure shell (SSH) and password authentication is disabled. SSH authentication is available only via public/private key authentication.
  • A network diagram is available upon request.

UserVoice servers and software are running the latest versions of software and security patches.

  • We strive to keep all server software on the latest version; however, when that‘s not possible we do ensure that the latest security patches are installed/up to date. This is reviewed monthly (though patches are often installed as soon as they come out).
  • We‘re running the latest version of Ruby on Rails 2.3 and we review/apply the latest security patches as they come out.

UserVoice is written to protect against SQL injection attacks.

UserVoice is built on the Ruby on Rails platform and uses all the built-in protections for sanitizing query parameters in SQL statements.

UserVoice is written to protect against cross-site scripting attacks (XSS).

UserVoice runs the XSS plugin for Ruby on Rails that escapes all user-generated data by default to prevent users from embedding malicious Javascript code in customer sites.

Your password is stored securely

For performance reasons our database itself is not encrypted (though backups are; more on that below), but all user passwords are hashed using the SHA1 algorithm with salt. Hashing passwords is actually more secure than encrypting them, because that means we don’t have access to the original passwords, nor does anyone else. So even if our database is compromised, everyone’s passwords will stay secure.

Your access to UserVoice is secure

All access to your UserVoice admin console (yourdomain.uservoice.com/admin) is always over a secure (SSL encrypted) connection.

Your users access to UserVoice is secure

All widgets through which customers submit support tickets are also always over a secure SSL encrypted connection. Only your UserVoice site itself (yourdomain.uservoice.com) is not SSL-only, but you can force that to SSL-only on premium plans (though it does break domain aliasing, which is why we don’t provide it for everyone).

User passwords are encrypted.

For performance reasons our database itself is not encrypted (though backups are; more on that below), but all user passwords are encrypted.

Access is logged.

Server access logs for auditing are kept for seven days. Access logs for web servers are kept for 30 days.

Data is co-mingled but secure.

UserVoice is a multi-tenant SaaS solution: customer data is co-mingled on the same database tables, but all data is scoped by an account ID to ensure that one account cannot access data of another account. Unit, functional, and integration tests are run continuously on our CI servers to ensure that it‘s not possible for account data to leak.

Development and test environments do not use customer data.

We use fake customer data in those environments.

Nightly backups are stored offsite and encrypted.

  • A live backup is performed in near real-time with slave databases.
  • Backups are always full backups of all tables in the UserVoice MySQL database.
  • Backups do not include secondary data (like pageview tracking, denormalized reporting data) that is stored in various NoSQL systems (Mongo, Redis).
  • Backups are done nightly and encrypted with a shared password and stored offsite.
  • Backups are tested and restored daily.
  • Backups are kept for 30 days.
  • Backups are never kept on portable/removable media.

Deleted data is retained for up to 60 days.

All data that‘s deleted in the UserVoice system is soft deleted and can be recovered inside of 30 days. After 30 days that data is hard deleted and can only be recovered via full backup for another 30 days.

Reliability

Uptime for the last six months was 99.97%.

As of July 1, 2012. We track uptime using Pingdom testing at feedback.uservoice.com at a one-minute resolution.

UserVoice assets and widgets load quickly from anywhere in the world.

All static files (JS, CSS, widgets, images) are compressed and served from our CDN (Akamai), which has edge servers located around the world. In addition, all DNS requests are handled by Dyn, which has multiple DNS servers throughout the world.

UserVoice widgets will not impact your page load times.

UserVoice widgets are written in such way that they won‘t block page load and instead only load after the initial page is loaded. This means that your page load times are not impacted by installation of any UserVoice widget.

Domain Name Service (DNS) redundancy.

Provided by our DNS provider Dyn. From their site: “Built on a global IP Anycast network that includes 17 data centers, our enterprise-grade platform boasts an easy-to-use, web-based management portal, advanced logging and reporting, IPv6 and DNSSEC support—all with the backing of our support team that is available 24/7/365.”

Network-level redundancy.

Provided by our hosting provider Softlayer Technologies.

Application-level redundancy.

  • Redundant front-end proxy web servers.
  • Behind them are multiple application servers sitting behind a load balancer that ensures that if a server goes offline requests are immediately funneled to the remaining servers.
  • Database is arrayed in a standard master-slave configuration to provide a live backup and failover database should the master database server go offline.
  • Redundant secondary (NoSQL) databases.

Internal as well as external monitoring means we respond quickly to any service issues.

  • Internal system monitoring tools (Nagios) check on all systems every five minutes, and critical systems or errors are checked every minute.
  • Any critical errors (ex: server offline) triggers SMS alerts to the entire engineering team.
  • Pingdom is used to both monitor uptime of UserVoice sites as well as our internal tools (Nagios). The watcher of the watchers, if you will.
  • Application level monitoring includes custom internal tools (based on statsd) to track application events, tracking all 500 errors (failed requests) using Airbrake and New Relic RPM to track error rates and response times.
  • A critical issue policy is followed to ensure that proper issue escalation occurs. After any critical incident (defined as any incident that impedes end-users from performing core functionality), engineering is required to provide a write-up and retrospective on what went wrong and how it can be prevented in the future. These write-ups are often shared with customers via our blog (blog.uservoice.com).
  • Twitter (@UserVoice) is used for real-time notifications about any current service delivery issues.

PII and Cookies

Names and emails are the only personally identifiable information (PII) stored in the UserVoice database.

Cookies are required for normal operation of UserVoice; however, no PII is stored in any of the cookies that UserVoice uses:

Cookie Name Expiration Description
__utma, __utmb, __utmc, __utmz, __utmvvariesUsed by Google Analytics.
_session_idend of sessionUsed to track whether you‘re logged in or not. See below for more info.
_uservoice_tz90 daysYour time zone.
_uservoice_utcd6 monthsUsed for analytics tracking. More info below
_uservoice_uid8 weeksUsed to track logged-in state.
uvfend of sessionUsed to track if the user has been saved to the analytics backend.
uvts1 yearUsed to track user usage analytics.
__uvtend of sessionUsed to test whether cookies are enable.
_rfend of sessionUsed to determine if your information is up to date. It‘s usually just a number like 0 or 1.
auth_token1 yearUsed for “remember me” functionality to keep you logged in between sessions (i.e. closing and reopening your browser). Only appears if you log in and click the “Keep me logged in” link, or if you vote anonymously.

_session_id.

The _session_id is something that all apps use in order to determine if you‘re logged in and authorized to do logged-in actions. All apps that require authentication use some version of it. That‘s the reason for those "you have to enable cookies in order to use this site" sort of warnings. If you were to delete it you would be logged out. If you log back in, we put it back with another securely random number.

_uservoice_uid.

The _uservoice_uid works in conjunction with the _session_id to help us to verify the security of your session data. If you were to delete your _uservoice_uid it would reappear the next time you loaded the page as a logged-in user.

_uservoice_utcd.

_uservoice_utcd is another random session number. It‘s what we use to do analytics, like pageviews and such, so we can tie an anonymous user with an identifier. This exists so that it‘s not connected to your _session_id. Therefore, it‘s completely anonymous; we don‘t connect real user information with these utcds. It can be deleted at any time with no effect on your use of our app.

Common Questions

We have over _____ pageviews a month. Can we install your widget on our site?

Yes. See the previous section on assets/widget performance. Your traffic will likely be a drop in the ocean for us. If you have more than 50 million pageviews a month, drop us a line first.

Do you have a have a rigorous screening process for your employees that includes credit checks, background checks, reference checks and cavity searches?

No. We will often check references, we will always verify that local standard for proof of eligibility to work, and we‘ll make sure that potential team members fit our company values, but we will do little beyond that. We also have every employee sign a confidentiality agreement before he or she can work for us. We also do performance and peer reviews twice a year and retrospectives after any critical issue. If someone is not meeting our own performance standard, including being the root or contributing cause of a critical issue(s), we will not hesitate to terminate our working relationship with that person.

Do your employees have to sign confidentiality agreements?

Yes, each and every employee.

Do you have a _____ ethics policy?

No. We‘re guided by our company values and good old common sense. We believe that policies around ethics lead to less ethical behavior.

Would you be opposed to us performing penetration testing on your network/systems?

No, but we‘d prefer you tell us first. Not because we‘ll do anything different but so we‘re not surprised by the slew of bad requests (and the notifications that will go with them) that come from such testing. More importantly, by telling us that you‘ll be testing we can make sure you‘re not mistaken for a spammer and blocked.

Phew! Wow, we can‘t believe you‘re still awake. Kudos to you! If you do have additional questions, please contact us and we‘ll help you out.