Optimizely Behind the Scenes: WEB SECURITY & ARCHITECTURE 101
Run High-Performing Experiments While Keeping Your Site and Data Safe
WEB SECURITY & ARCHITECTURE 101 2
.00TABLE OF CONTENTS
.01 Introduction: Optimizely in a Nutshell 3
.02 Optimizely Architecture: Day in the Life of an Experiment 5
.03 JavaScript Reliability: Keeping Pages Loading Fast 14
.04 Scalability: CDNs and Load Balancing 20
.05 Privacy, Security, and Compliance: Ensuring Safety 23
.06 Conclusion 31
WEB SECURITY & ARCHITECTURE 101 3
Marketers, product leaders, and growth teams rely on A/B testing and optimization to understand their website visitors, make data-driven decisions, and optimize to drive business results.
That’s why we created Optimizely — to make the technical work of instrumenting online experiments dramatically easier, and to put the power of A/B testing and targeting and testing in the hands of teams that previously couldn’t. Our web application enables any business to create high-performing online marketing and revenue optimization campaigns supported by actionable data.
Implementation is straightforward and fast. Copy and paste the Optimizely snippet (one line of JavaScript code) on your webpage to get started.
.01 INTRODUCTION: OPTIMIZELY IN A NUTSHELL
WEB SECURITY & ARCHITECTURE 101 4
Minimal technical expertise is necessary to use Optimizely, as we have built a visual editor for launching website experiments. Load your website into the editor, click on an element, and make your changes. For power users, we also provide the ability to write custom variation code using JavaScript or jQuery.
Optimizely was built with speed, reliability, and security in mind. The trust of our customers is at the foundation of everything we build. As an application with the ability to visibly alter a compa-ny's homepage, we understand that performance and security are fundamental elements of a strong A/B testing and optimization product. When you’re working with a third party service, you can’t afford to take any chances — you need to make sure that you are working with the most reliable, high-performing, and safe solu-tion out there.
If you’re considering Optimizely, you (or your IT team) may have questions about your website performance, data, and risk exposure. That’s why we wrote this guide — to explore the most frequently asked questions about the platform’s technical and security architecture. We’ve ensured that you’ll have everything you need to make an informed, strategic decision about whether Optimizely is the best choice for your business, covering the following topics:
› Product & Architecture
› JavaScript Reliability
› Scalability
› Security, Privacy, & Compliance
WEB SECURITY & ARCHITECTURE 101 5
I - Getting Up and Running
WEB
Optimizely is deployed on the web through a single line of Javascript, the Optimizely snippet. To run Optimizely experiments on your website, you’ll need to add a small snippet of JavaScript to the <head> tag of your website’s code. For simplicity’s sake, many teams will add the snippet sitewide; however, you can choose to add the code on specific pages that you want to test.
.02 OPTIMIZELY ARCHITECTURE: A DAY IN THE LIFE OF AN EXPERIMENT
WEB SECURITY & ARCHITECTURE 101 6
Optimizely experiments can modify anything on the webpage to which they’re applied. We recommend that customers place the JavaScript file at the very top of their websites as a synchronous load (although Optimizely can also be configured to support an asynchronous load). This prevents the experiment from being loaded after the entire webpage (i.e. a ‘flicker’ effect). The Optimizely snippet will ping Optimizely’s content delivery network (CDN) servers to load a JavaScript file with experiment data before any other website content.
WEB SECURITY & ARCHITECTURE 101 7
The following diagram illustrates the order of operations for the Optimizely code snippet as it would execute synchronously during page load. The cookies in this diagram are described in section II.
On average, pulling down the Optimizely JavaScript file takes approximately 150ms and can be monitored here. You can read more about our CDN’s performance in this whitepaper here.
User Not bucketed into Experiment
OPTIMIZELY CODE SNIPPET ORDER OF OPERATIONS
Segment User
Does User Meet Targeting Conditions
for active experiment?
Traffic Allocation Algorithm Determines
which Variation to serve
YE
S
NO
Experiment Variation Code Execution
Experiment Global CSS/JS Execution
OPTIMIZELY PAGE VIEW TRACKING CALL
Goals attached to page elements
Remainder of page resources load
DOM Ready
optimizelyEndUserId cookie set
optimizelyBuckets cookie set
optimizelySegments cookie set
KEY
Optimizely Snippet Activity
Optimizely Cookie
Asynchronous Optimizely
Tracking Call
WEB SECURITY & ARCHITECTURE 101 8
The Optimizely dashboard helps you manage your experiments, audiences, dimensions, and project-level settings. Projects are designed to help you better organize your experiments across multiple sites (or different sections of large sites.) The hierarchy of experiment organization looks like this.
Experiment Experiment Experiment
Project
Experiment
Project
ExperimentExperiment
Optimizely Account
THE DASHBOARD
Optimizely’s website (Optimizely.com), also called the ‘Web Application,’ is powered by Google App Engine. This is where we host key pieces of information regarding your account, but actual experiment data is stored on Amazon’s cloud servers. You can think of the web application as the place where you tell Optimizely what to do in terms of defining the experiments that you want to run.
II - Defining, Managing, and Editing Experiments
WEB SECURITY & ARCHITECTURE 101 9
Every time you make a change in the Optimizely Editor, Optimizely creates a line of jQuery code that finds the selected element, and then makes the changes you selected in the Editor. You can see (and edit) this code by clicking <Edit Code> in the lower-right-hand corner of the Editor, which pops open the Code Editor (also known as a "code store"). You can write your own code directly in the <Edit Code> box using JavaScript or jQuery. Experiments are then published to Optimizely’s Content Delivery Network (CDN) (reference page number in the guide that talks about CDNs).
Using projects, you can group your experiments in ways that make sense for your organization. For example, if you run experiments on multiple domains, you can assign a unique project for each domain.
THE VISUAL EDITOR
The Optimizely Visual Editor, also known as the WYSIWYG (What You See Is What You Get) Editor, allows you to create variations of your pages for your experiments, all in a visual format.
WEB SECURITY & ARCHITECTURE 101 10
III - Web Application Security
USER PERMISSION LEVELS
Optimizely is designed for use cases ranging from single account holders to large teams. You can invite users to your account without giving all team members the same levels of access.
User roles are available for Enterprise accounts and specify differ-ent levels of permissions that you can use to manage collaborators on an Optimizely project. They are especially useful when there are multiple people working on the same project or experiment. There are four types of user roles: Administrators, Project Owners, Editors and Viewers. The following article describes how to implement the user roles and the access given to each role.
› Administrators have full access to all projects and account billing information. They can also add or remove other administrators. If you make someone an Administrator, they are one on every project. If you demote an Administrator to any other role, they lose all privileges on other projects.
› Project Owners can create, edit, start, and stop experiments, preview variations, and view results. A project can have more than one Project Owner. Project Owners can also create new projects and invite editors and viewers to the project(s) they are owners of.
› Editors can create and edit non-running experiments, preview variations, and view results.
› Viewers can preview variations and view results.
These user permission levels limit exposure to risk by ensuring that Optimizely users see exactly what they need to run impactful experiments. Administrators have the most control over the Web Application and have the tools they need to quickly take action in the event of a security breach.
USER AUTHENTICATION & PASSWORDS
Optimizely requires authentication for all application pages and resources, except for those specifically intended to be public. All authentication controls must be enforced on a trusted system (e.g. The Server), and all authentication controls fall securely. The Web Application ensures that only cryptographically strong one-way salted hashes of passwords are stored and that the file that stores password hashes is only readable by Optimizely’s application.
Authentication failure responses will not indicate which part of the authentication data was incorrect. For example, instead of "invalid username" or "invalid password", Optimizely uses "invalid username and/or password" for both. Optimizely uses only HTTPS POST requests to transmit authentication credentials—the exception being REST API tokens.
Logs are kept at all account levels for changes made to user accounts for both Optimizely Administrators and end users. Logs are kept indefinitely. Logs are not reviewed by default, but can be reviewed upon request to Optimizely’s support team.
WEB SECURITY & ARCHITECTURE 101 11
Optimizely maintains records of the following information:
› Account
› Sign-in
› Sign-out
› Automated e-mails sent
› Experiments
› Archiving
› Creating
› Deleting
› Start/Pause
› Updating
› Update Project Settings
We enforce the following password requirements and security standards:
› Passwords must be a minimum of 8 characters in length and include a mix of uppercase and lowercase letters as well as numbers and symbols.
› Multiple logins with the wrong username or password will result in a locked account, which will be disabled for a period of time to prevent a brute-force login — but not so long to allow for a DoS attack.
› Password entry is obscured on the user’s screen.
› Email-based password resets are sent to pre-registered email address with a temporary link/password.
› Optimizely monitors multiple login attempts from the same email address.
› Salted one way hashes of passwords are stored.
WEB SECURITY & ARCHITECTURE 101 12
Google App Engine
Define KPIs
Create Experiment
AUTHOR A/B TESTS
Start Experiment
Compute Statistics
Display
RESULTS DASHBOARD
Amazon Web Services
Store JS File
S3
Send Purge Request
Elastic Load Balancer
Hadoop
EC2
Content Delivery Networks
Customer Website
//cdn.optimizely.com/js/123456.js
Track KPIs
OPTLY CLIENT-SIDE JS
Akamai
EdgeCast
DUAL CDN ARCHITECTURE
Compiled JS file
Pull from S3 Bucket
Browser Request JS
Image RequestXMR Request
OPTIMIZELY
IV - Backend & Data Processing
WEB SECURITY & ARCHITECTURE 101 13
BEHIND THE SCENES
At its core, Optimizely is a system that measures changes to conversion rates. Metrics are calculated based on unique conversions per unique visitor — a user that performs a single conversion more than once will count as a single conversion. Users are identified based on a unique cookie, which determines whether a user has completed an action on a site previously. Optimizely’s backend counts and de-duplicates these events.
A log service, which transmits information from the browser to EC2 via XMLHttpRequests (XHR requests), receives these events and places them into a queue to be processed. Another service inserts them into the database. A third service reads them out of the database and then counts them. The final service is an API service (not to be confused with the Optimizely's publicly available REST API and JavaScript API), which requires the presence of a token for authentication. Google AppEngine relies on this API service to connect to the backend, as the Web Application does not connect to the backend directly. Everything else is stored in a separate Amazon product called S3.
S3 operates under the principle of least privilege through firewalls — Optimizely employees and customers can only access information through authorized and intended channels. Results are calculated client-side in the browser.
WEB SECURITY & ARCHITECTURE 101 14
I - Cookie Management
OPTIMIZELY COOKIES
Optimizely mainly uses first-party cookies to report on visitor interactions on your website. These cookies are used to store technical information required for the operation of our services. We use the data to provide Optimizely products and services to you — including but not limited to targeted experiments as well as granular, visitor-level reporting data.
Optimizely’s service collects the following types of data:
› Visitor interactions with Content/Tests (for reporting to customer)
.03 JAVASCRIPT RELIABILITY: KEEPING PAGES LOADING FAST
WEB SECURITY & ARCHITECTURE 101 15
› Unique ID assigned to a visitor
› ID of the experiments and variations seen by a visitor
› Customer’s account number
› String identifying conversation goal (such as page URL)
› Date and time of visit
› Visitors’ browser and operating system versions
› Visitor’s IP address(es)
IP Addresses: Every computer and device connected to the Internet is assigned an Internet Protocol (IP) address. IP addresses are needed by websites in order for the Internet to function. You already have access to the IP addresses of your visitors regardless of whether or not you use Optimizely. Optimizely uses IP addresses to provide and protect the security of the service, and to give you a better idea of where your visitors are coming from.
Optimizely provides you with the option to anonymize IP addresses before we store results data. This feature is available on a per experiment basis and only applies to future collection of IP addresses if you enable it for a particular experiment.
The Optimizely snippet creates and sends first and third-party cookies to the user's browser. Some of these cookies are persistent and others are session-based, but in all cases the cookies collect anonymous usage data that is meaningless outside
of the context of tracking user behavior in an experiment.
From an information security standpoint, users have several options via Optimizely’s JavaScript API to configure these cookies to restrict their scope: (1) so that they can be accessed from fewer locations and (2) to reduce their lifespan, for a shorter amount of time before expiring.
1 - Setting Domain
Instruct Optimizely to set its cookies on a specific subdomain instead of the default website’s top-level domain. You must call "setCookieDomain" prior to loading the Optimizely snippet. By default, Optimizely sets its cookies on the domain, in order to work across subdomains.
window['optimizely'] = window['optimizely'] || [];
window['optimizely'].push(["setCookieDomain", "www.
example.com"]);
In this example, the cookies Optimizely sets will be available only on "www.example.com", ("www.example.com" and all of its subdomains), rather than on ".example.com", which is the default domain.
2 - Setting expiration
Specify the number of days before the Optimizely visitor cookies will be set to expire. You must call "setCookieExpiration" prior to loading the Optimizely snippet. The minimum number of
WEB SECURITY & ARCHITECTURE 101 16
days that can be set is 90 (approximately 3 months). For more information on how Optimizely uses cookies, visit our Knowledge Base.
Note: Some Optimizely cookies are reset every time a visitor comes to the site, which means the expiration period set with this API call will be used each time the cookie is set.
window['optimizely'] = window['optimizely'] || [];
window['optimizely'].push(["setCookieExpiration", 365]);
3 - Disabling third-party cookies
Disable Optimizely's third-party cookies. You must call "optOutThirdPartyCookies" prior to loading the Optimizely snippet. This will prevent cross-domain visitor bucketing and measurement. For more information on Optimizely's use of cookies, please see our Knowledge Base.
window['optimizely'] = window['optimizely'] || [];
window['optimizely'].push(["optOutThirdPartyCookies"]);
FIRST-PARTY COOKIES
A first-party cookie is a cookie whose domain is set to your website (i.e. .yoursite.com.) Optimizely sets the first-party cookies to the highest level domain available on your site. This ensures that a user will be tracked through all subdomains. A brief summary:
optimizelyEndUserId
› What: Contains the end user's unique identifier. It is a combination of a timestamp and random number. No information about you or your customer is stored within the cookie.
› Example: oeu1383080393924r0.5047421827912331
› Expiration: 10 years
optimizelyBuckets
› What: Stores JSON of the experiments and variations that a user has been bucketed into. This ensures the user consistently sees the same variation, even across multiple sessions.
› Example: {"138736319":"138725428","138750142": "138754098"}
› Expiration: 10 years
› In a multivariate test, the variations a visitor sees are concatenated with an underscore, like this: {"experimentID":"section1variationID_section2variationID_section3variationID"}
› Example: {"138736319":"138725428_138825412_135555542", "138750142":"138754098"}
optimizelySegments
› What: Stores JSON of the user's audience and dimension information (e.g., browser, campaign, mobile, source type, custom dimensions).
WEB SECURITY & ARCHITECTURE 101 17
› Example: {"139230617":"direct","139230618":"false", "140036362":"gc","159151144":"none"}
› Expiration: 10 years
optimizelyCustomEvents
› What: Stores a history of the last 10 custom events that a user has triggered.
› Example: {"oeu1383080393924r0.5047421827912331":["event_name_1", ..., "event_name_10"]}
› Expiration: 10 years
optimizelyRedirect
› What: In the case of a redirect experiment, stores the user's original referring URL. This helps detect a redirect loop.
› Expiration: 5 seconds
optimizelyPendingLogEvents
› What: Used as a cache of a user's actions between tracking calls. When the tracking call is made, the cookie will be wiped. This is to ensure that all events are tracked, even if the user is committing actions in rapid succession.
› Expiration: 15 seconds
THIRD-PARTY COOKIES
The domain for these cookies is set to ".optimizely.com" (thus classifying them as a third party cookie in relation to your page). Optimizely employs these cookies in order to tracks users across domains and reconcile their actions to an experiment or variation on the original domain.
Similar information and names are used as the first-party cookies:
› optimizelyEndUserId
› optimizelyBuckets
› optimizelySegments
OPTIMIZELY EDITOR COOKIES
These are first-party cookies that are only set when using Optimizely's editor. Therefore, an end-user of your webpage will never see these cookies:
› optimizelyReferrer: Stores the document.referrer property.
WEB SECURITY & ARCHITECTURE 101 18
II - Variation Code
DEPLOYING EXPERIMENTS
When you create a variation of your page in the Optimizely Editor, each action you take in the editor is encoded as a line of JavaScript. After you've begun your experiment, this JavaScript is executed when your visitors load that page in order to display the variation. For example, when you swap one image out for another, the corresponding JavaScript code looks something like this:
$("img#hplogo").attr({"src":"//cdn.optimizely.com/img/a/
05ac207c778548959fe1ff374d111296.gif"});
This line of code literally tells your visitor's browser to swap the image you highlighted in the editor with a new one you uploaded (which is now stored on Optimizely's servers here.)
While creating variations in the Optimizely Editor you can always click "Edit Code" in the bottom right-hand corner of the screen to see this code and, if you feel comfortable, edit it yourself.
STRUCTURE
The Optimizely Editor generates a line of JavaScript for each change you make in a variation of your experiment page. These auto-generated lines of JavaScript have the following structure:
$("img#hplogo").css({"width":254, "height":112}); |__
IDENTIFIER_| |____________ACTION____________|
Lines of JavaScript in the variation code are composed of a jQuery identifier for the currently highlighted element (in this case, an image with id attribute "hplogo"), along with an action (in this case, adjusting the width and height dimensions.)
WEB SECURITY & ARCHITECTURE 101 19
EVALUATING VARIATION CODE
Optimizely must deal with two constraints while evaluating variation code:
› The code must be evaluated as soon as possible, so that the "Original Page" content does not flash on the screen.
› The code cannot be evaluated before the elements on the page to which it refers are loaded into a browser's memory.
In order to navigate these constraints, Optimizely uses the following algorithm to evaluate variation code, line by line:
Does the next line of JS fit the INDENTIFIER.ACTION template?
YE
S
This must be manually edited
JavaScript.
Execute remaining variation code
Wait until the DOM is ready
Is the element referred to by INDENTIFIER
part of the DOM yet?
Evaluate this line of JS
Wait 50msN
O
YESNO
YE
S
NO
Is the DOM ready?
WEB SECURITY & ARCHITECTURE 101 20
I - The Importance of Response Times
A one-second delay in website response time results in 11% fewer page views, a 16% decrease in customer satisfaction and a 7% loss in conversions.
The reason is that response times can be impacted both by (a) the number of visitors making a request from a web server at the same time and (b) the physical distance of that visitor from the web server. This is why it’s become increasingly important for website owners to use content delivery networks (CDNs) to host their website content.
.04 SCALABILITY: CDNS AND LOAD BALANCING
WEB SECURITY & ARCHITECTURE 101 21
II - Decreasing Load Times and Increasing Scalability Through CDNs
A CDN is a network of web servers located around the world. Each of the web servers in the network hosts a version of the assets that make up a website (e.g. images, styles, JavaScript, etc.). This architecture reduces the load on any individual server and decreases the amount of physical distance between visitors and the web server.
At the highest level, a “balanced” CDN architecture is one that leverages two or more CDNs hosting identical content to increase (a) the overall number of physical Points of Presence for the network (PoPs) and (b) the proximity of those PoPs to the end users accessing them around the world.
Websites with high volumes of traffic cannot afford to take the risk of working with a third-party service that could negatively impact their web performance. For many website owners, it can be difficult to weigh the value of adding third party code to a page against the relative impact of adding additional milliseconds to the page’s response time.
Prior to implementing a balanced CDN architecture, Optimizely’s snippet already responded in a virtual blink of the eye. Optimizely’s CDN Balancing strategy, introduced in November 2013, allows experiment code to be served by a combination of the two fastest and most widely used CDN providers in the world. You can read how here.
III - Loading the Optimizely Snippet on the Web
Earlier in this guide, we mentioned that to run Optimizely, you’ll need to add a small snippet of code to your website’s <head> tag. This snippet includes your unique Project ID, and it allows the experiments you create in Optimizely to execute on your site.
After this, you won't have to update the snippet for future experiments. The snippet will automatically update to run any tests you create in the Optimizely editor, retrieving experiment data through our CDN infrastructure. You can deploy experiments without modifying the JavaScript on your website.
If you archive an experiment, the information will be available from your account, but the snippet will be regenerated as a clean experiment, without any historical variation code. The process of purging an experiment takes about 3 to 5 minutes until changes are live to the CDN.
Optimizely’s snippet is hosted and delivered via the Akamai and EdgeCast CDNs, and we use load balancing to determine the physically closest server to the website’s end user from which to deliver the JavaScript snippet to their browser. You can read information about Akamai's security here, EdgeCast's here, and our overall approach to CDN balancing here.
For fine-grained experiments—including those with geotargeting or geolocation features, there is a request to Akamai Edgescape,
WEB SECURITY & ARCHITECTURE 101 22
which is set up asynchonously. If the service times out, the experiments will not display at all.
VI - CDN Quick Facts
Optimizely’s CDN relies on balanced architecture with Akamai and EdgeCast. We utilize Dyn’s RTTM (Real Time Traffic Manager) to push users toward the best performing CDN in various geographical regions. We also use Catchpoint to monitor CDN performance in 10 minute intervals in 43 nodes around the world.
ASIA PACIFIC: 11 NODES
› Bangalore, IN (BHARTI)
› Beijing, CN (Telecom)
› Guangzhou, CN (Telecom)
› Melbourne, AU (Multihomed)
› Quanzhou, CN (Telecom)
› Singapore, SG (PACNET)
› Singapore, SG (PCCW)
› Shanghai, CN (Telecom)
› Shenzhen, CN (Telecom)
› Sydney, AU (AAPT)
› Tokyo, JP (NTT)
EUROPE: 11 NODES
› Amsterdam, NL (TELIA)
› Berlin, DE (KPN)
› Dublin, IE (Level 3)
› London, UK (TELIA)
› Madrid, ES
› Manchester, UK (Cogent)
› Milan, IT (Telecom Italia)
› Moscow, RU (Multihomed)
› Munich, DE (Level 3)
› Paris, FR (TELIA)
› Zurich, CH (Level 3)
NORTH AMERICA: 21 NODES
› Atlanta (NTT)
› Atlanta (Zayo)
› Chicago (Level 3)
› Chicago (NTT)
› Dallas (Cogent)
› Dallas (Telx)
WEB SECURITY & ARCHITECTURE 101 23
.05 PRIVACY, SECURITY, AND COMPLIANCE: ENSURING SAFETY
I - Data Management
INTERNAL ACCESS TO DATA
Access to customers’ information is restricted within Optimizely for the purpose of providing direct customer support.
Optimizely team members also consult customer data during feature development processes — for instance, to understand how an engineering change affects a group of customers. Sensitive customer data is never, under any circumstances, shared with anyone outside of Optimizely.
Optimizely takes the safety and security of your information seriously. We have implemented employee access controls that protect your information from unauthorized use.
WEB SECURITY & ARCHITECTURE 101 24
› Your account data is used only to provide services to you. Optimizely does not sell, rent, or otherwise disclose the information you provide to us in setting up your account for any other purpose.
› We limit access to your content and information to Optimizely employees who require such information to perform their jobs, or as required to provide support to you.
› Access to systems containing your sensitive information is logged and audited.
› Optimizely requires the use of secure passwords and 2-factor authentication (where available.)
› Optimizely employees are subject disciplinary action, includ-ing but not limited to termination, if they are found to have abused their access to customer information.
WEB SECURITY & ARCHITECTURE 101 25
1 - Who has access to customer data?
Customer data is accessible by our
Engineering and Customer Success teams.
Any employee with access to customer
data is required to sign Optimizely’s
Customer Information Access Agreement,
stating that they will not access, use, or
disclose for any purpose any Optimizely
customer information, except as strictly
necessary for performance of job
responsibilities.
2 - Is customer data shared with third parties?
Optimizely shares data with service
providers including Amazon, Google,
CDNs and Salesforce, as required to run
our services.
3 - Where is data stored at rest?
Data at rest is stored on Amazon Web
Services EC2 and S3.
4 - Is data encrypted at rest?
No. The data is anonymous event-driven
data, and thus is not required to be
encrypted at rest.
5 - Is data encrypted/protected during transmission?
Yes. All data is transmitted over 128 bit
SSL.
6 - Which information security standards and regulations does Optimizely comply with?
Web Application Security Consortium
(WASC) - A 501c3 nonprofit that includes
an international group of experts,
industry practitioners, and organizational
representatives who produce open and
private security standards for the World
Wide Web.
The Open Web Application Security
Project (OWASP) - A worldwide, nonprofit
charitable organization that is focused on
improving software security.
7 - What recent independent audits and pen tests have taken place in last 12 months?
Optimizely undergoes two types of third
party audits: automated, continuous scans
conducted by White Hat Security and non-
automated, annual audits performed by
iSEC Partners.
The White Hat Sec covers top Web
Application Security Consortium (WASC)
and Open Web Application Security
Project (OWASP) vulnerabilities. The iSEC
Partners audit references the White Hat
Sec results and performs an independent
analysis.
9 - What is the impact to an Optimizely customer of service not being available?
If Optimizely.com is down, all currently
running campaigns will continue to run
and data will still be collected; however,
you will not be able to update any of these
campaigns until service is restored.
10 - What is the impact to an Optimizely customer if service experiences loss of data?
You will have incomplete data in the
result of your A/B or multivariate test. In
a worst-case scenario, your A/B test will
need to be re-run.
FREQUENTLY ASKED QUESTIONS ABOUT OPTIMIZELY’S CUSTOMER DATA
WEB SECURITY & ARCHITECTURE 101 26
CUSTOMER CONTENT AND TEST RESULTS
You will always own the content you provide to Optimizely. You will also own the results from your tests.
Please be aware that Optimizely does not monitor, limit or otherwise restrict or censor any content or information you provide to us. This is a critical point: because we do not know what content/information you are using, you are solely responsible for this content or information.
In order to ensure the best possible customer experience we ask that you:
› Not share Personally Identifiable Information from end users with us;
› Not share sensitive information or trade secrets with us;
› Not share illegal content with us;
› Not share any content/information belonging to third parties with us without their explicit permission;
› Not upload content or information for testing that includes any information you would not want the general public to see, as these may be displayed to your website visitors;
› Ensure that everyone with access to your Optimizely account understands that content or information provided by you to Optimizely may be displayed to visitors to your websites.
Optimizely’s service collects the following types of data:
› Visitor interactions with Content/Tests (for reporting to cus-tomer)
› Unique ID assigned to a visitor
› ID of the experiments and variations seen by a visitor
› Customer’s account number
› String identifying conversation goal (such as page URL)
› Date and time of visit
› Visitors’ browser and operating system versions
› Visitor’s IP address(es)
IP Addresses: Every computer and device connected to the Internet is assigned an Internet Protocol (IP) address. IP addresses are needed by websites in order for the Internet to function. You already have access to the IP addresses of their visitors regardless of whether or not you use Optimizely. Optimizely uses IP addresses to provide and protect the security of the service, and to give you a better idea of where your visitors are coming from.
Optimizely provides you with the option to anonymize IP addresses before we store experiment result data. This feature is available on a per experiment basis and only applies to future collection of IP addresses if you enable it for a particular experiment.
WEB SECURITY & ARCHITECTURE 101 27
II - Checklists
Optimizely customers often have questions related to session management, input validation, error handling and logging, and compliance standards. We’ve created the following checklists and ‘quick review’ sections to connect you with some of the questions that you’re likely thinking about:
SESSION MANAGEMENT
Optimizely uses the server or framework’s session manage-ment controls. The application recognizes only these session identifiers as valid.
Session identifier creation is always done on a trusted system (i.e. the server).
Session management controls use vetted algorithms that en-sure sufficiently random session identifiers.
Optimizely sets the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site.
Logout functionality fully terminates the associated session or connection.
Optimizely generates a new session identifier on any re-au-thentication.
Optimizely does not expose session identifiers in URLs, error messages or logs header.
New session identifiers are generated through HTTPs only. HTTP is not allowed.
“Secure” attributes are set for cookies transmitted over a Transport Layer Security (TLS) connection.
INPUT VALIDATION
Input data sources are classified into trusted and non-trusted, and all data is validated from untrusted sources.
There is a centralized input validation routine, module, or pro-cedure for the Optimizely at all input points.
Optimizely encodes data to a common character set before validating.
Optimizely specifies proper character sets, such as UTF-8, for all sources of input.
All validation failures result in input rejection.
Optimizely validates all client provided data before processing, including all parameters, URLs, and HTTP header content via Google App Engine.
Optimizely verifies that header values in both requests and responses contain only ASCII characters.
Optimizely validates all input against a “white” list of allow characters. If any potentially hazardous characters must be allowed as input, Optimizely implements additional controls such as output encoding.
WEB SECURITY & ARCHITECTURE 101 28
Optimizely checks for null bytes, new line characters, and “dot-dot-slash” path alterations characters.
CRYPTOGRAPHY
All cryptographic functions used to protect secrets from the application user are implemented on a trusted system.
Optimizely protects master secrets and keys from unautho-rized access.
Cryptographic modules are designed to fail securely.
All random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic mod-ule’s approved random number generator when these random values are intended to be un-guessable.
ERROR HANDLING AND LOGGING
Optimizely does not disclose sensitive information in error responses, including system details, session identifiers, or ac-count information.
Optimizely implements generic error messages and uses cus-tom error pages.
Optimizely handles all application errors and does not rely on the server configuration.
Logging controls support both successes and failures of speci-fied security events.
Optimizely uses a master routine for all logging operations.
Optimizely does not store sensitive information in logs, includ-ing unnecessary system details, session identifiers or pass-words.
SAFE HARBOR
Optimizely complies with the US-EU Safe Harbor framework as set forth by the U.S. Department of Commerce regarding the collection, use and retention of personal data from European Union members countries. Optimizely has certified that it adheres to the Safe Harbor Principles of notice, choice, onward transfer, security, data integrity, access and enforcement. To learn more about the Safe Harbor program and to view Optimizely’s certification, please visit: http://www.export.gov/safeharbor/
IP ANONYMIZATION
IP Addresses: Every computer and device connected to the Internet is assigned an Internet Protocol (IP) address and IP addresses are needed by websites in order for the Internet to function. You already have access to the IP addresses of their visitors regardless of whether or not you use Optimizely. Optimizely uses IP addresses to provide and protect the security of the service, and to give you a better idea of where your visitors are coming from.
Optimizely provides you with the option to anonymize IP
WEB SECURITY & ARCHITECTURE 101 29
addresses before we store results data. This feature is available on a per experiment basis and only applies to future collection of IP addresses if you enable it for a particular experiment.
PCI COMPLIANCE
At this time, Optimizely as an overall software platform or business is not PCI certified. PCI compliance is a top development priority for the company, but specific strategy and implementation choices are still in the planning stages.
The only scenario in which Optimizely transmits information across the Internet is with goal tracking. When we track a pageview, click, revenue, or custom event goal, we make a call to our own event log servers, in which that URL contains query parameters with user and event-specific information. For custom event and revenue goals, you make a JavaScript API call within the code on your site. In both of these cases, you are free to specify any value you want for the eventName (the value that you choose to pass to the API). When you do, this information will temporarily be stored in the optimizelyPendingLogEvents cookie until the event log server is pinged with this information. The optimizelyPendingLogEvents cookie expires after 15 seconds.
The log call looks like this, and you may also see the URL we ping in the network traffic section of your browser console when a goal is fired. If you do not wish to use the JavaScript API call, you may manually construct and ping the log URL yourself. The
“n” parameter corresponds to the eventName described above, and again is a field you may provide in a custom event or revenue goal, and only if you choose to pass PII or PCI information will we collect and store it. A custom event is essentially a true/false flag mapping to the completion of a customer action, and by default revenue goals only consider the monetary amount (in cents) of that purchase.
Optimizely’s snippet and JavaScript API calls can be deployed once to your site and audited, and all experiments can require no future code releases. You are free to make as many and as frequent changes within the Optimizely platform as you like, and all these changes are quickly deployed to the snippet in near-real-time. The only way potentially malicious code can be inserted into the snippet is if someone gains access to your Optimizely account and provides that code as part of a variation, or if someone gains access to your copy of the self-hosted snippet. In both cases, because Optimizely is delivered client-side, any user data on your site must also exist client-side to be accessed. These considerations may mitigate the frequency with which you would need to audit our snippet.
Optimizely’s software and architecture are regularly audited by a third party firm for security vulnerabilities, and we actively address any findings. If this still presents a security concern, you may install Optimizely on any or all pages except the billing page where credit card information is collected. You will be unable to make changes or track goals on this page alone.
WEB SECURITY & ARCHITECTURE 101 30
III - Disaster Recovery
Optimizely’s infrastructure is designed to provide the best customer experience to you and minimize service interruption due to hardware failure, natural disaster, or other catastrophes. Features include:
State of the art cloud providers. We use Google App Engine and Amazon Web Services, which are trusted by 1000s of businesses to store and serve our data/services.
Data replication. To help ensure availability in the event of a disaster we do not host our data/services onsite. We store this in replicated file systems located in different data centers.
Continuity plan. In addition to the redundancy of data and our world class infrastructure, we have an office located in Amsterdam, the Netherlands to ensure that regional issues at our global headquarters located in San Francisco, California do not disrupt our ability to provide the services or support to you.
WEB SECURITY & ARCHITECTURE 101 31
.06 CONCLUSION
Running controlled experiments and delivering targeted expe-riences requires a reliable, secure, and scalable solution. That’s why Optimizely is built with the performance and security needs of customers in mind. With Optimizely’s simple implementation, powerful balanced CDN architecture, and rigorous processes for protecting customer data, you can rest assured that your business and customer data is safe and secure. Optimizely is already trust-ed by members of the Fortune 500, startups, non-profits, and over 8,000 other businesses around the world.
Learn more about Optimizely by checking out the following resources:
For support, visit: https://help.optimizely.com
To learn from fellow marketers, check out: http://community.
optimizely.com/
For Optimizely’s developer platform, visit: http://developers.
optimizely.com/
For customer stories, visit: https://www.optimizely.com/customers/
customer-stories/
WEB SECURITY & ARCHITECTURE 101 32
ABOUT OPTIMIZELY
Optimizely is the world’s leading optimization platform, providing
A/B testing, multivariate testing, and personalization for websites
and iOS applications. The platform’s ease of use empowers
organizations to conceive of and run experiments that help them
make better data-driven decisions. With targeting and segmentation
using powerful real-time data, Optimizely meets the diverse needs of
any business looking to deliver unique experiences to their visitors.
To learn more about Optimizely, schedule a live demo today at
OPTIMIZELY.COM/DEMO
SAN FRANCISCO OFFICE
631 Howard Street, Suite #100
San Francisco, CA 94105
AMSTERDAM OFFICE
Nes 76
1012 KE Amsterdam
The Netherlands
Recommended