Data and Security Overview
This document is an overview of Purple security and data protection policies, intended to answer customers’ commonly asked questions in a transparent and user-friendly way.
Data and data security
Data in transit
All public facing portals and websites are encrypted with TLS (Transport Layer Security). TLS is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. Purple support TLS 1.2 minimum.
Purple regularly review TLS ciphers offered, and remove ciphers that are no longer considered to meet minimum security requirements.
Data at rest
All Purple-hosted data is hosted within cloud services such as Google Cloud (GCP) or Amazon Web Services (AWS), and all disks hosting data are encrypted (AES-256) using the security controls available with those cloud providers.
All passwords are encrypted with the bcrypt hashing function.
Data protection
Purple host and handle data in a way consistent with the standards of the EU’s GDPR regulations.
All data purposes and rights are explained clearly and transparently to the end user in Purple’s EULA and privacy policy, which are presented in concise and user-friendly terms.
Separate active opt-in is sought for all marketing consents within the EU and as activated by customers elsewhere, and any EULA or opt-in consent is stored against the user and venue with the date, time and language of opt-in. Once a user has logged in, they are sent a link to an end user profile where they can view data held about themselves, view (and change) any opt-in consents and immediately delete all data collected about them.
Additionally, users can email the Purple Data Protection Officer (via a clearly displayed email address) with any queries, for any changes to their data or to exercise their right to be forgotten.
Data is only used for the stated purposes, and Purple do not collect more data than is strictly needed (although the individual customers decide their own data uses and configure the portal to collect the information required by themselves, as well as uploading their own additional EULAs and privacy policies where required, consent of which is tracked individually).
Purple have a declared data retention period of 13 months of inactivity, after which all PII data about a customer are destroyed.
Captive portal
The captive portal is the mechanism via which users accept Purple terms of use, provide any authentication information that the customer requires before allowing access to the WiFi, and consent to any marketing.
When a user joins a Purple SSID and reaches the splash page, their device MAC address and user agent are stored, as well as the AP MAC (and therefore venue the user is at). When a user logs in via the WiFi, any user data they provide is also stored against their profile. The exact data collected varies according to the login method chosen and the configuration created by the customer, but can include personally identifiable information (PII; see PII section below), as well as other potentially sensitive information such as a user’s Facebook likes. This data is either submitted by the user via web form, or transferred from their social media account if they grant access. Data in transit via the captive portal is always secured via TLS, and all data collected is initially stored local to the captive portal software in a document store.
Once a user is connected, RADIUS accounting data should be passed from the network controller to Purple’s RADIUS servers, providing basic network usage metrics: the time the session started, ended, the reason for the session end and data upload and download.
DNS data
If configured by the customer, Purple may additionally collect domain lookup data via a third party company, WebTitan, by using WebTitan’s own DNS servers (the same mechanism for blocking access to prohibited websites). Domain look-ups are logged against the venue’s web-facing IP, and aren’t traceable to an individual user or device.
Location-based services
Location data is data collected passively about devices (both authenticated and non-authenticated) by compatible network access points. Typically, an AP records a received signal strength indication (RSSI) value, a MAC address (which may be randomised, depending on the client software) and a date/time for each client WiFi probe. With the right hardware and 4 or more APs, this data may be enhanced to an estimated geometric coordinate of the device relative to the uploaded floor-plan.
When a client MAC is recognised as having logged in via Purple in the past, some demographic data may be associated with the location data records (gender, age). Where a user has logged into this venue before and accepted the venue’s T&Cs, a recognised device will be linked against the user record, regardless of whether the user is currently authenticated to the WiFi.
Purple are voluntary supporters of the Future of Privacy Forum (fpf.org), via which a user can opt out of client MAC tracking across a range of services.
Purple do not store data about randomised MAC addresses (devices like modern iPhones that do not present their true MAC addresses until authenticated to the WiFi), and anonymous MAC addresses (addresses that haven’t authenticated to the WiFi) are one-way hashed with a company-specific salt on export to prevent sharing of data about anonymous devices and comparisons with third party data sources.
Connectors
Customers can configure ‘Connectors’, which are third party integrations that copy data into or out of Purple’s hosting. This information is typically basic CRM data about end users (e.g. names and email addresses being exported to third party email lists, under accounts run by the same company).
Connector connection/session data is stored encrypted.
API
A RESTful API exists for extracting most end user data in raw format. Access to this service is via signed public/private keys, provided on request by the Purple support team once a customer’s rights to the data have been verified. Access to Purple APIs is encrypted in transit using HTTPS, and requested are signed with a nonce to prevent replay attacks, and a full audit log exists of all requests, including the source IP of the requests.
Webhooks
Users can also define Webhooks that trigger data export on certain actions (e.g. a user logging into the WiFi) via an HTTPS POST to a user-defined endpoint, which allows for real-time responses to events. These endpoints must be HTTPS with a valid certificate, and are verified by header.
Personally identifiable information (PII)
Depending on the customer’s configuration of their captive portal and the access method chosen by the end user, Purple may capture and store the following data classified by Purple as PII: first name, last name, date of birth, email address, mobile number, and social user ID (e.g. Facebook ID). Additionally, Purple can collect other data that is categorised as being potentially personally identifiable when combined with other data: client/device MAC, gender, login date/time, Facebook likes, Facebook/Twitter location/home town, postcode/zip code.
PII data is stored in three locations: the access document store (where the user logs into the WiFi), the central analytics data store (where the data is stored/processed) and in the end user-facing profile document store (where the end user themselves can review, modify and delete their own data). It is encrypted in all three locations, as detailed above.
When a user requests to be forgotten or when a user has been inactive long enough to meet the end of the data retention period, all PII data is removed from the user record and the user’s sessions become anonymous. Purple retain basic anonymous demographic information: the age and gender of the user at the time of log-in.
It is possible for customers to add custom data fields or survey questions for the user to complete, which can include other PII data such as national IDs or passport numbers. All custom data like this is treated as PII.
Payments
Purple do not handle or store any user financial data. Any payments are taken via a direct communication between the end user and our payment gateway provider ‘Stripe’ (www.stripe.com). Stripe are fully PCI-DSS compliant. Purple record only a one-time transaction ID for potential refund purposes.
ISO compliance
Purple are both ISO 9001 compliant for business practice and ISO 27001 compliant for data security and storage. The business is audited annually by an accredited third party company to check that we remain compliant. This is in addition to our own in house interim audits and management reviews. Certification can be supplied upon request.
Data sovereignty
All data gathered by the Purple platform resides in one of three GCP hosting locations depending on where the customer is located in the world, they are as follows:
- California for North and South America
- London, UK and Amsterdam, Netherlands for Europe, Africa and the Middle East
- Sydney for APAC, APJ, ASEAN and ANZ
Purple is compliant with regional data storage/privacy requirements where implemented, to retain data within the geographical boundaries determined by local legislation.
Data Retention
All user data is anonymized after a period of 13 months of inactivity. This means Purple will store a user’s personal data, in its full form, for at least 13 months, and after 13 months of inactivity (not logging back into the WiFi) we strip out anything which is deemed personally identifiable. This includes name, email, telephone number, etc. However, we do maintain non-identifiable information such as age and gender at the time of login, and session metadata such as time of login, network data usage and connection method used.
Purple may discard raw data sooner. For example individual location data records from location services can be dropped after 24 hours, but an aggregated record of when the device was present on a floor plan and what zones were visited will be kept.
Data storage and backup
All of our databases are replicated to a secondary instance in a different Zone. The replication is real time. In the event of planned database maintenance, DB instance failure, or a Zone failure, the affected cloud service (e.g. Amazon RDS or Google CloudSQL) will automatically failover to the standby. This means that we do not have a single point of failure.
Purple runs daily snapshots on all databases, which means we have the ability to restore our database quickly should the need arise..
Data ownership
The customer will have full ownership of, and access to, the end-user data and engages Purple as a data processor to provide the solution. The data is hosted within the region in which it is collected – for example customers in North America will have their data hosted in the US cloud.
Application components
Captive portal
When a user connects to a SSID, they will be redirected to a captive portal splash page hosted by Purple. This splash page is configurable by Purple customers, and will present the user with one or more access methods (e.g. a registration form or social media login such as Facebook). Upon choosing an access method, the user will be presented with a T&Cs popup which they must accept to continue. This pop up contains links to Purple’s terms of use, privacy policy and any user-defined terms. Upon declining the terms, the user will be returned to the splash page. Upon accepting the terms, the user will either fill in the form or grant Purple OAuth access via a social media platform. Purple will then authorize the user on our RADIUS server and redirect the user back to the network controller which will release the user from the captive portal so they can access the wider Internet.
Captive portal splash pages are hosted on access nodes which is an elastically scaling PHP application backed by a scaling NoSQL database. Static content is served from Amazon’s Cloudfront.
Our RADIUS servers are FreeRADIUS servers that store data on a GCP Cloud SQL database.
Location / presence data collection
Location-based services such as Cisco MSE, Ruckus SPOT or Meraki Cloud can be used with the product. These collect the MAC addresses of WiFi-enabled devices within range of the network APs and either provide basic RSSI information (which can be used to estimate the distance from the AP to derive footfall, dwell time, conversion and bounce rate stats) or estimated X/Y coordinates that can be used to place a user on a map and track paths a user takes around a venue. Location data can be linked to known WiFi users via MAC address.
Customer portal
The portal is the application where resellers and customers manage their licenses, infrastructure and view reports. Access to this application is controlled by username and password. User accounts can be given granular rights (read or write access to many individual sections of the portal) and are assigned hierarchically (e.g. with rights to a single venue, a group of venues, a whole company or a whole reseller, etc). Platform rights are granted by individual users, and a user cannot grant or revoke rights beyond their own scope.
When a new portal user is created, they are sent a username (email) and a randomly generated password in email format. Upon first login, they are asked to change this password to one of their choice, which must be greater than 8 characters and contain both numbers and capital letters. The user must change their password every 90 days and they are not allowed to reuse any password from the past 12 months.
Radius
All traffic to our Radius server has to be authenticated with a called station id and password. Without this traffic is denied access. For additional security a one time password is also created and once used is discarded and cannot be used again.
Personnel Management, Procedures and Policies
Staff access
Access to Purple’s system within GCP is strictly limited to key members of staff, which is reviewed on a regular basis to ensure only appropriate staff have accounts.
Contractors and outsource companies are occasionally retained to do greenfield development work. Access to live data, servers or services and existing code is strictly prohibited, and all code produced is subject to the same peer review as any code created by our internal team.
Staff access roles are clearly defined and reviewed quarterly and on contract change. Access to data and applications is established on a least privilege basis, with users only being granted access to what they need to fulfil their role for as long as they need it. Staff have minimal access rights while on their three month probation period, and non-employees (e.g. contractors) have no access to any customer data, live services or code repositories.
Development and testing procedures are clearly defined in our secure development policy. All code is submitted via pull request and peer-reviewed by the team and at least two senior developers prior to merge. It then goes through regression testing processing with our QA team who create and maintain standardised test sheets. Unit testing is used throughout the code base, and test-driven development encouraged. UAT may be carried out with selected partners prior to the release of large new features in the form of betas/trials.
Releases
Deployments occur at least weekly for general maintenance and bug fixes are deployed as required. Large releases follow a quarterly deployment schedule. All deployments go via Purple’s test platform for final sign-off by our QA team.
Vulnerability/threat management
Purple carries out monthly automated vulnerability/threat analysis tests of all of our applications and infrastructure, and on every significant change (large code releases, infrastructure/architecture changes or after software upgrades). Software patches are applied at least weekly. Should a vulnerability be found during these tests, the threat will be assessed for level of impact and patched immediately should it be deemed necessary or have the fix rolled into the next release.
A full third party penetration test/audit is performed by our security partner as required and at least once per year.
Incident response
As part of Purple’s ISO 27001 certification, we implement a Security Incident Reporting Policy that gives staff clear guidelines to protect the integrity of data collected by Purple. This ensures that security incidents, or potential incidents, are identified, brought to the attention of the Information Security Manager/Data Protection Officer and dealt with in a manner appropriate to the urgency and impact of the breach.
Purple maintain a list of data protection contacts at all customers, and these customers are notified as soon as is reasonably possible about any breach impacting them
Staff termination
Purple has a clear procedure for staff termination. Requests to remove access to systems and recall hardware are logged as change requests on the in-house service desk.
- Data and Security Overview
- Created on 08 June 2023
- Last updated on 03 December 2024