--- type: Article title: "[1211.4812] XSS-FP: Browser Fingerprinting using HTML Parser Quirks" resource: "https://arxiv.org/abs/1211.4812" tags: [article, webseclist-reference, en, arxiv-org] generated: by: webseclist-refs/1 at: "2026-08-19T16:44:49+00:00" status: stable stale_after: 2027-08-19 sources: - id: original resource: "https://arxiv.org/abs/1211.4812" title: "[1211.4812] XSS-FP: Browser Fingerprinting using HTML Parser Quirks" author: Erwan Abgrall, Yves Le Traon, Martin Monperrus, Sylvain Gombault, Mario Heiderich, Alain Ribault also_at: - "https://arxiv.org/pdf/1211.4812" authors: - Erwan Abgrall - Yves Le Traon - Martin Monperrus - Sylvain Gombault - Mario Heiderich - Alain Ribault canonical_url: "" cited_by: - "2012.md:88" commit: "" content_sha256: cf31c90af850a3611d99efdeb98a38731345627c2bd55bc946fa83a416fbae3a depth: full depth_reason: default kind: article language: en licence: unknown original_url: "https://arxiv.org/abs/1211.4812" published: "" publisher: arXiv.org publisher_english: "" raw_sha256: 4a1d06e30c07255edf21fc5f29f5a224b59bf6057c2581d86c57718e9de62018 retrieved_from: "https://arxiv.org/pdf/1211.4812" retrieved_kind: live retrieved_utc: "2026-08-19T16:44:49+00:00" slug: arxiv-org-xss-fp-browser-fingerprinting-using-html-parser-quirks snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # [1211.4812] XSS-FP: Browser Fingerprinting using HTML Parser Quirks **[1211.4812] XSS-FP: Browser Fingerprinting using HTML Parser Quirks** - Erwan Abgrall, Yves Le Traon, Martin Monperrus, Sylvain Gombault, Mario Heiderich, Alain Ribault, arXiv.org. - Published: date not stated - Original: - Also published at: - Preserved from: https://arxiv.org/pdf/1211.4812 (live) on 2026-08-19 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. 1 XSS-FP: Browser Fingerprinting using HTML Parser Quirks Abgrall Erwan, Yves Le Traon, Martin Monperrus, Sylvain Gombault, Mario Heiderich and Alain Ribault Technical Report, University of Luxembourg, 2012. HTML parser under specific inputs to fingerprint the type and Abstract—There are many scenarios in which inferring the version of browsers. We call those particular responses HTML type of a client browser is desirable, for instance to fight against parser quirks1 . Those specific inputs are the same that are session stealing. This is known as browser fingerprinting. This arXiv:1211.4812v1 [cs.CR] 20 Nov 2012 paper presents and evaluates a novel fingerprinting technique to used for cross-site scripting attacks. This is completely novel determine the exact nature (browser type and version, eg Firefox browser fingerprinting technique, with key advantages: 1) 15) of a web-browser, exploiting HTML parser quirks exercised compared to network-based fingerprinting, it can be achieved through XSS. Our experiments show that the exact version of a at the application level with no access to the low level network web browser can be determined with 71% of accuracy, and that stack. 2) it is hardly spoofable; simulating the behavior of an only 6 tests are sufficient to quickly determine the exact family a web browser belongs to. HTML parser is difficult without running the parser itself. We will give more details on these points in Section II. To the best of our knowledge, we are the first to use HTML parser I. I NTRODUCTION quirks to achieve browser fingerprinting. In computer security, fingerprinting consists of identifying Our experiments show that the exact version of a web a system from the outside, i.e. guessing its kind and version browser out of 77 can be determined thanks to its signature. [1] by observing specific behaviors (passive fingerprinting), Moreover, using classification techniques described by Hall et or collecting system responses to various stimuli (active fin- al. [6], only 6 XSS tests are sufficient to determine the exact gerprinting). A common example of fingerprinting is service family a web browser belongs to. fingerprinting. It consists of identifying the daemon behind Section II further discusses the rationales of browser fin- an open port of a server. For instance, a port scanner may gerprinting and using HTML parser quirks. Section III is an output that the daemon behind port 22 is not the expected overview of the approach. The next sections describe the XSS SSH server, but a SMTP daemon, instance of the software vector collection, and the dedicated tool we have developed package “Postfix”, in version 7. to execute the HTML parser quirks. Section VI describes OS fingerprinting is another popular kind of fingerprinting data mining classification we use to fingerprint browsers. [2]. For instance, by sending carefully forged packets to the Section VIII discusses our fingerprinting capabilities, includ- target, slight differences between implementations of the TCP ing a discussion on how fingerprints can be forged. Section protocol stack enable observers to identify the stack and its IX discusses browser fingerprinting from an expert security underlying operating system. Fingerprinting is used in many engineer viewpoint. Section X is a comparison against the situations. For instance, security engineers use it to check related work, section XI concludes the paper. whether known vulnerabilities may affect a software system or infrastructure. Similarly to service or OS fingerprinting, browser finger- II. R ATIONALES printing consists of identifying a browser implementation and version. Also similarly to OS fingerprinting, there are two The HTTP protocol specifies that browsers should send a kinds of browser fingerprinting. On the one hand, one may specific string, value of the HTTP request header User-Agent uniquely identify a browser (see e.g. [3]), on the other hand, (UA), for identifying themselves. In practice, all browsers do one may uniquely identify a browser type, that is, identifying send this header. The rationale behind this header is to offer the browser implementation (e.g. Firefox vs Internet Explorer) the server a way to infer browser capabilities and serve specific and its version number (e.g. IE8 vs IE9). They are orthogonal contents to more or less advanced browsers. concerns: the former is important w.r.t. privacy, the second is important w.r.t. security, and there is no direct relation between Can a server trust the User-Agent header to fingerprint a both. browser ? No, this value is set by the browser and it cannot In this paper, we address the latter, the fingerprinting of be trusted since an attacker can modify it by patching the browser type and version. There are many use cases of browser browser (some browsers even offer to set it as a configuration fingerprinting (see Section ??) for instance to address the point). The User Agent string is commonly used by exploit problem of credentials stealing detection. Previous work in kits to attack servers by embedding a malicious payload in the field of browser fingerprinting was based on analyzing the user-agent header. the JavaScript behavior [4] or the network behavior [5] of a browser. In this paper, we propose to use the behavior of the 1 The Merriam-Webster dictionary defines a quirk as a “a peculiar trait” 2 HTML Parser RSnake Quirks Dataset of Cheatsheet Dataset of XSS Vectors Browsers Browser Version Fingerprinting Shazzer (based on Hamming Distance) Dataset of Fingerprints (XSS Unknown XSS Signatures) Client Browser Execution Browser Family Driver Fingerprinting Legend: (based on Decision Trees) Data Minimum Building Optimal Fingerprinting Process Decision Tree Data Fig. 1: Overview of Our browser Fingerprinting Process A. Defeating Session Stealing with Browser Fingerprinting inventories of HTML parser quirks. This means we have tons Session stealing means stealing a cookie or a session ID in of HTML parser quirks to achieve browser fingerprinting. order to access unauthorized resources. Server-side software One might think that what we call “quirks” are essentially is responsible to detect session stealing. This can be done “bugs”. We think that this distinction is not binary. Indeed, the through checking whether the presented cookie or session ID root cause of some known XSS vectors can be found in the matches the HTTP user-agent header. However, as said, this specification itself (e.g. the HTML5 specification), that is it is does not work if attackers are able to steal both the credentials not a standard implementation bug. Consequently, we consider and the user-agent. Checking credentials with IP addresses is that the browser behavior under particular input is a “quirk”, not a valid way to check session stealing due to users mobility whether desired or not, and whether incorrect or not. and NAT mechanisms. Compared to network-based fingerprinting, HTML-based With browser fingerprinting, at any point in time, server fingerprinting can be achieved at the application level with software can: 1) verify whether the HTTP user-agent matches no access to the low level network stack. This means that an the inferred browser type (detection of UA spoofing) 2) verify application can use browser fingerprinting (for instance for whether the inferred browser type matches the browser that detecting session stealing), while remaining OS independent. was used on login (detection of session stealing). For instance, a server-side application written can still perform Beyond this key use-case, there are many other uses of browser fingerprinting independently of the application server browser fingerprinting, further discussed in Section IX. (Tomcat, JBoss, etc.), the Java virtual machine (IBM J9, OpenJDK, etc.) and the OS (Windows, Linux, etc.). B. The Benefits of Using HTML Parser Quirks For Finger- Last but not least, the behavior of an HTML parser is printing very complex (that’s why so many cross-site scripting attacks exist). Hence, the fingerprint of HTML parser quirks is hard to Previous work in the field of browser fingerprinting was spoof. In other terms, if an attacker wants to deploy counter- based on analyzing the JavaScript behavior [4] or the network measures to an HTML-based fingerprinting, he has no solution behavior [5] of browsers. In this paper, we use the HTML but running all browsers in parallel. parser quirks for browser fingerprinting. HTML parser quirks The implementation of such HTML parser checks can be are peculiar behaviors under specific inputs. They may have achieved through the inclusion of a small invisible iframe. different consequences, in particular incorrect rendering or Checks can be triggered upon sensitive actions or randomly. undesired execution of JavaScript code. We also imagine web application firewalls modifying some The latter point is daily exploited by cross-site scripting pages on the fly to add the signature checks based on HTML attacks (XSS). A cross-site scripting attack embeds an exe- parser quirks. cutable malicious payload into a piece of specific HTML code. By replacing the malicious payload by a simple binary output telling the server whether a specific parser behavior is observed C. Recapitulation or not, one can observe from the server-side the execution of There is a need for browser fingerprinting, since the HTTP HTML parser quirks. For us, those execution-based quirks are protocol has no means to fight against session stealing. A invaluable: they are testable. technique based on the observation of HTML parser quirks is Furthermore, HTML parser quirks are known. The very doable at the application level, and its counter-attack is hard, active community on cross-site scripting research has produced since HTML parser behavior is hardly spoofable. 3 III. OVERVIEW OF THE A PPROACH TABLE I: Composition of the XSS database (number of XSS vectors per source) Figure 1 presents an overview of our browser fingerprinting approach. Using quirks to fingerprint web browsers is feasible Rsnake Html5Sec Shazzer Total 69 163 291 523 only if these quirks are testable, in the sense that the specific behavior of the browser quirk can be observed through testing. This is why we build our own dataset of testable quirks. They developers to protect their applications accordingly and even come from different sources: collaborative, fuzzing techniques perform basic risk assessment, for instance when fixing a such as Shazzer, existing referenced vectors (see section IV-A). vector is in conflict with required application features. The Based on this set of testable XSS vectors, a framework H5SC set contains 1̃20 individual attack vectors alongside with called XSS Test Driver performs the full test suite on different detailed explanations on their inner workings. browsers, collecting as many XSS signatures as possible. Each signature contains attributes describing the results of all the tests. We consider an initial set of 77 browsers, C. Shazzer - Collabrative Fuzzing for Identifying XSS Vectors and the corresponding signatures are referred as the raw Shazzer2 is a collaborative website aiming at providing dataset of browser signatures. This dataset can be directly an interface for collaboratively specifying and identifying used for fingerprinting an unknown web browser, in order to possible XSS vectors. Shazzer offers enumeration templates determine (1) its exact version based on a Hamming distance and an internal render and storage engine. A user can for between browser signatures. This set can also be used (2) as instance define a vector template containing various different input for machine learning techniques in order to build an placeholders. After starting the actual fuzzing process, the optimized decision tree. Such a decision tree allows the quick placeholders will be iteratively replaced by the corresponding classification of the family (e.g. Firefox or Chrome) of an characters and rendered in an isolated iframe to see whether unknown web browser according to its responses to minimum the desired effect can be accomplished with the currently fingerprinting data (execution of a handful of quirks instead tested characters. Shazzer has been used by a large number of thousands). It has to be noted that the overall approach can of security testers to determine whether certain known an un- be applied using any testable quirks. All the fingerprinting known parser bugs in modern user agents have been discovered process steps are described in the following sections. and fixed. The set of sources of XSS vectors is summarized Table I. IV. A DATASET OF HTML PARSER Q UIRKS For a total of 523 vectors, the main provider is Shazzer (291). The full vector list is available at http://xss2.technomancie.net/ The following subsection describes the three sources we vectors/ have used to build a significantly large collection of XSS vectors usable for fingerprinting. These sources include static V. XSS E XECUTION D RIVER vector libraries as well as XSS fuzz generation tools. In this section we present XSS Test Driver, our framework to automatically perform the execution of XSS vectors for A. RSnake’s XSS Cheat Sheet - Legacy Vector Collection fingerprinting. We use our whole XSS vector set on a set of The XSS Cheat Sheet was created by R. ‘RSnake” Hansen et browsers, building a dataset of raw browser signatures. al., and provides a richresource for penetration testers and de- velopers. It showcases an overall of 1̃00 different XSS vectors A. Terminology demonstrating character and string parsing issues, especially for legacy browsers. The resource has not been updated for An XSS attack consists of executing code (mostly many years though; modern HTML5 and SVG based attack JavaScript) inside a browser via a website, by injecting a vector examples are not present in this document. A beta- content (e.g. by posting a comment on a page). The injected version of an overworked XSS Cheat Sheet was announced in content is an XSS vector. For instance a very simple XSS vec- 2010, but never found its way to a public release. The lack of tor is . An XSS updates of this document lead to community-driven projects vector can be logically decomposed of three parts: such the HTML5 Security Cheatsheet (H5SC). 1) The XSS vector contains one or several HTML tags and attributes 2) The payload is a piece of JavaScript code, B. HTML5 Security Cheatsheet - Community Vector Collec- 3) The payload format is a special way to encode the tion payload. The HTML5 Security Cheatsheet (H5SC) is a community In the above example, the vector is composed of the script driven project that aims at documenting and categorizing tags, the payload is a call to function alert , and the format is known XSS and other client-side attack vectors. The H5SC “identity” (i.e. the payload in not encoded at all). provides a simple JSON based storage model and allows This is a very simple example of XSS vector. More complex registered and approved contributors to add new XSS vectors, XSS Vectors benefit from the ever-growing functionalities modify existing data and most importantly provide version offered by browsers to developers. Each new API or language information on which user agents are affected by the demon- strated attack vector. This allows security professionals and 2 see http://shazzer.co.uk/home 4 subset that is able to execute or call JavaScript code can TABLE II: Examples of results of the XSS Test Driver be turned into an XSS vector. For more information on the Attr. browser 1-1-1 1-2-1 . . . 523-2-1 richness of XSS Vector forms, refer to section VIII-B and Value Safari 5 1 5 NA PASS NA Firefox 11 0 PASS SENT NA look at the XSS Vector sources described in IV An important characteristic of XSS vectors is that certain XSS structures accept payloads in very specific formats. For instance, some XSS structures require a link to JavaScript file, 5) If for some reason a test is skipped, or if a new others are successful only if the payload is encoded in base64. untestded vector is introduced, the test result is marked Such behavior is either related to a specific feature, or to a bug. Not Available (NA). An XSS vector can also depend on : This test logic avoids the use of JavaScript library, and uses no • The character set the browser should use to decode the interactions with the DOM. It can be fully automated by using HTMK a runner script opening the next test inside an iframe. Chaining • The content type of the transmitted resource test execution can also be done manually by browsing different • The HTML Doctype of the HTML Document tests. Since the browsers rely on those pieces of information to decode the received data and to parse them properly, some D. Callback Functions : Validating JavaScript Execution quirks can be triggered by playing with those parameters on Depending on the browser JavaScript Engine, and how and the server side (ie: sending HTML4 vectors within an HTML5 where in the DOM the JavaScript call is done, some function context). might not work. The first method in XSS Test Driver generates a JavaScript redirect of the web page to the test validation B. XSS Test Environment URL. But with some vectors, this method doesn’t trigger The test environment of an XSS vector consists of two the expected web page redirection. it is due to some iframe parts: the HTML context and the encoding. The HTML context sandbox mechanisms where the JavaScript code can’t access (that we call “Web Context”) is composed of the doctype and window.location DOM property. A cookie based execution generally all the HTML surrounding the vector as well as the validation was added then, adding a cookie in the browser to MIME type specified in the HTTP headers. The encoding is validate execution of a given test case, but it triggered security the character set declared in the http headers and used in the errors on Chrome iframe sandbox with srcdoc based vectors. document. A XMLHttpRequest call is also present in the test payload, XSS vectors can be tested in different web contexts and triggering a specific validation URL. But this one too was with different encodings. Hence, each XSS vector must be subject to some security restrictions with recent versions of executed by the product of the number of contexts and the Chrome. We eventually added a -based callback to the number of encodings. As we have 523 vectors, this may yield payload, adding an image to the DOM with an image source a combinatorial explosion if we run all possible encodings set to a validation URL delivering a green PASS verdict image. and web contexts. In the following experiments we limit the test set to two web contexts: quirks and html5, and to one E. Browser Instance Description encoding utf-8. Thus testing 523 Vectors with 2 web context and 1 encoding generated 1046 test cases to run. Increasing the For each tested browser, XSS Test Driver provides 1 signa- number of encodings tested allows using more discriminating ture instance (set of attributes) describing the results for the quirks but it is a trade off to be made during the signature whole test suite representing 1046 unitary test cases computed collection, since it increases the number of tests to execute. from the 523 base XSS vectors. Each attribute name issued from 1 test has the same name structure giving as many different attribute names (like 90-2-1 for example) : C. Test Logic • XSS vector number of our test bed: 1 to 523, We use the following logic to chain the tests and collect the • context of execution: 1 or 2, results: • context of encoding: 1. 1) Each XSS attack is served by a URL containing a The possible values of these attributes are : JavaScript payload encoded with the proper format. {SEN T, P ASS, N A} corresponding to the test logic, When the URL is requested, the test is marked as SENT. Section V-C. This set of attributes is completed with a free 2) The payload of an XSS attack contains a specific text describing the browser. Table II illustrates 2 instances JavaScript validation routine (described in V-D). When extracted from the real dataset. the validation mechanism is triggered (the validation routine is executed), the successful test is marked as VI. F INGERPRINTING M ETHODOLOGY PASS. 3) The server then points to a new test by redirecting the This section presents the methodology we use to fingerprint browser using a HTTP code 302 redirect. browsers using their responses when executing XSS vectors 4) Upon completion of the test suite, SENT tests cases are based tests. The signature dataset provided by XSS Test Driver considered failed and remains with this value. is used as input. 5 A. Exact Fingerprinting Based on Hamming Distance between MDF indicates whether a browser is close to its siblings or Browser Signatures not. If all browsers of a family have a low MDF, it means Similarity measurement is used to find nearest neighbors in that the family is cohesive and they do share the same HTML a set of vectors. An efficient way of doing it is to calculate the parser behavior. We also compute the Median Distance to the Hamming Distance between vectors. The Hamming Distance Dataset (MDD) to determine outlier browsers, those that do evaluates similarities between 2 vectors having the same not resemble any other browser. number of dimensions, and is defined as follow: for two vectors V1 and V2, this measure corresponds to the number of B. Browser Family Fingerprinting using Decision Trees dimensions where the element of the vector V1 differs from Identifying the browser family with a minimum of tests is the element of the vector V2. crucial when an attacker spoofs the UA string, in order to 1) XSS Browser Signature: We define the browser signature minimize the spoof detection time. The raw dataset produced as a vector computed from a browser instance provided by by XSS Test Driver is also used to validate the fingerprinting XSS Test Driver. The size of the vector is n where n is the methodology based on machine learning algorithms. number of XSS vectors in the database (see IV). As defined in the test logic section V-C, the value of each element is in 1) Classification based on Decision Trees: The classifica- the set: {s, p, n} where tion algorithms based on decision trees (DT) are useful in supervised data mining since they obtain reasonable accuracy • s corresponds to SENT and are relatively inexpensive to compute. DT classifiers are • p corresponds to PASS based on the divide and conquer strategy to construct an • n corresponds to NA appropriate tree from a given learning set containing a set Let us consider the following simple signatures Sb1, Sb2 of labeled instances, whose characteristic is to have a class and Sb3 that are obtained from executing three XSS vectors attribute. As a well known and widely used algorithm, C4.5 on three web browsers b1, b2 and b3. (developed by Quinlan [7]) generates accurate decision trees • Sb1 = pps that can be used for effective classification. We have used • Sb2 = pns J48 decision tree algorithm, a Weka [6] implementation of • Sb3 = pnp C4.5. It builds a decision tree from a set of training data also Sb1 captures the fact that the two first XSS-vector execu- with the concept of information entropy. It uses the fact that tions are PASS and the last SENT. each attribute of the data can be used to make a decision that To deal with browsers for which we do not have enough splits the data into smaller subsets. Like C4.5, J48 examines significant data for fingerprinting, we define a confidence value the information gain ratio (can be regarded as normalized based on P the percentage of XSS information gain) that results from choosing an attribute for P vectors the web browser executes: (P ASS|SEN T )/ (XSSvectors). If this value splitting the data. is too low for a given browser, we cannot trust its instance. The attribute with the highest information gain ratio is Browsers with signature confidence above 90% are used in the one used to make the decision. The decision trees are this paper. constructed as a set of rules during learning phase. Rules 2) Modified Hamming Distance: To measure similarity can be seen as a tree composed of nodes containing tests on between two browser signatures, we propose a modified Ham- attributes and leading to leaves containing the class of the ming distance (MHD) in order to ignore NA in the signature. learned instance. It is then used to predict the class of new Our distance works as follow: given two browser signatures, instances belonging to a testing set, based on the rules. it computes the Hamming distance only on XSS results that 2) Labeled Browser Instance Description: XSS Test Driver are s or p in both signatures (not n). The modified Hamming provides the initial dataset needed to fingerprint the browser distance between Sb1 and Sb2 is 0, and the MHD between family. The chosen browser families correspond to recent Sb1 and Sb3 is 1. browsers: Android, Chrome, Firefox, Internet Explorer(IE), When XSS Test Driver collects a signature, we compute Opera and Safari. Table III summarizes the number of tested the MHD between this signature and the known signatures browsers per browser family, a subset of 72 instances. To build from the browser dataset. When two browser signatures in the the labeled dataset, we consider as attributes for classification database have a MHD of 0, the fingerprint cannot distinguish the P, S and N values of the XSS test execution, and we add among those corresponding browsers: they are similar, mean- an attribute labeled family. This family attribute may have one ing that we may have many signatures of very close versions of the 6 possible values listed in table III. e.g., Firefox 10.1.1 and Firefox 10.1.2. If there is no browser Table IV presents 2 labeled instances extracted from the real signature in the database with a distance of 0, we consider data set. the nearest neighbor defined the browser signature(s) with 3) Building the Decision Tree: We configure Weka Ex- the smallest MHD. Having a a nearest neighbor with a large plorer to use J48 classification algorithm and family as class MHD means that the browser is clearly distinguished among attribute. Firstly, We consider the whole labeled data set the dataset. containing 72 instances to train J48 classifier. The generated As a complement and to evaluate how the browsers belong- DT is composed of nodes containing tests on attributes values, ing to a family are grouped, we calculate the Median Distance until the leaf containing the class attribute filled during the to the Family (MDF) of the browser. As its name suggests, learning phase. After the training phase, we use the same data 6 TABLE III: Distribution of Browser Families TABLE V: MHD Fingerprinting Efficiency analysis Family Instances MHD=0 nb of browsers FP rate Well Fingerprinted Android 15 22 77 28,57% 71,42% Chrome 19 Firefox 15 IE (Internet Explorer) 6 TABLE VI: Browser family classification results Opera 6 Total number of instances 72 100.00% Safari 15 Correctly classified instances 71 98.61% Incorrectly classified instances 1 1.38% TABLE IV: Example of labeled signatures Attr. 1-1-1 1-2-1 . . . 523-2-1 family Value N P N Safari dataset indicates its proximity with the rest of its family. The P S N Firefox Firefox family and the Chrome family both contains a bigger number of elements due to the higher pace of release. Time and differences between two major versions of Firefox or Chrome set to test our DT and we compare the class obtained with the is equivalent to minor version changes for IE or Safari in term DT to the class present in the instance: a difference reveals a of release time line. misclassification. The quantity of errors of this first evaluation gives an estimation of the classifier produced by the whole Rekonq Linux, Origin and Konqueror browsers use Webkit data set regarding the class attribute family. as HTML parser, as also do Safari, Chrome and Android. We can see that browsers in the same family have similar MDF (e.g. M DF = 15 for Firefox). This shows that MDF correctly VII. E XPERIMENTAL R ESULTS captures clusters of related browsers. In this section we analyze the results of our browser The summary of this experiment is that if two browsers fingerprinting experiments. share the same HTML parsing code base, they also share highly similar fingerprints. A. Exact Fingerprinting Results We have applied the method described in VI-A to fingerprint B. Browser Family Fingerprinting Results our dataset of browsers in order to see whether the resulting fingerprints are discriminant. Tables VIII and IX (at the end of We use the whole dataset to train and build the decision tree the paper for sake of readability) present our results. The first presented of Figure 2. We use this tree to classify the training column lists all browsers of our dataset. The second column set, giving the results presented in table VI. The key point of indicates the nearest neighbor within the dataset according this decision tree is that one can classify 98% of the dataset to the Hamming distance between browser signatures. The using only 6 runs of XSS vectors. third column gives the distance between those two neighbors. The confusion matrix highlights the accuracy of the classi- The fourth and fifth columns are the median distances to fication using our DT. The diagonal of the matrix counts how the browsers of the same family (MDF) and the number of many instances belonging to a class are correctly classified elements in the family. The last column is the median distance in this class. One can observe that the instance incorrectly to the whole dataset (to see whether they are family or true classified belongs to Android and is classified as Chrome. outliers). The results are ordered by MDF. Since Chrome and Android share a significant code base, it is First, one sees that for all browsers with a MHD of 0 to logic that some instances of Android are close to some Chrome their nearest neighbor, the neighbor is a browser of the same instances. family with a very close version number. This confirms the Vectors #89, #90, #128 and #258 come from Shazzer and soundness of our approach. use parser bugs to special characters like 0x00. Vector #397 is Second, i.e. 78% of our browser dataset have a nearest specific to Gecko-based browsers and come from html5sec3 . neighbor at a MHD distance higher than 0. This means that As a first experimentation, we plan to develop this approach those browsers can perfectly be discriminated and that MHD as a piece of software in a web application firewall. This first is an appropriate distance to capture both the family and the step needs further investigations to validate our decision tree version information. This confirms our intuition that browser on a larger set of browsers. fingerprinting using XSS vectors is very discriminant. Interestingly, browsers 89, 25 and 27 are exotic browsers like the ones you can find inside set top boxes or smart-tv. C. Recapitulation Their MDD is very high, showing that MDD actually cap- tures the originality of browser implementation. For instance, Our experiments show that the exact version of a web browsers with an older code base like Konqueror are at a browser can be determined with 71% of accuracy (within huge distance from the dataset mainly composed of recent our dataset), and that only 6 tests are sufficient to quickly browsers. Also, the nearest neighbor of Rekonq is Safari 5.0.6, determine the exact family a web browser belongs to. which makes sense since they use the same major version of the webkit engine (534). The MDFs of each browser in the 3 http://html5sec.org/#15 7 PASS Firefox !=PASS Chrome 397-1-1 !=PASS 90-2-1 !=PASS Android PASS 128-1-1 SENT Safari !=PASS 89-1-1 PASS 258-1-1 !=SENT Opera PASS IE Fig. 2: Executing only 6 XSS vectors enables us to classify the browser family with 98% precision. VIII. D ISCUSSION 4.0.5 (distance of 13 much higher than zero). To conclude, it does not seem possible to relate the quirks A. On Time and XSS discrimination power to general factors, while it seems that The fact that one can determine the browser exact version a potential explanation may be flaws in the development just using quirks is appealing. In particular, one can wonder processes. It is interesting to observe (see annexes) that the whether there is some underlying logic in the way the quirks plots are completely different from one browser family to occur, making them predictable. Indeed, we could expect two another. successive versions of a given browser to exhibit more similar The classification of web browsers according to quirks must quirks than more temporally distant ones. There may be thus follow another explanation than time. We develop this general temporal factors explaining the discrimination power point in the next section. of HTML parser quirks. One of such explanation factor could be the evolution of JavaScript and HTML norms over time. In this section, we investigate two research questions to bet- B. On Kinds of XSS ter analyze the discrimination power of quirks (at least those In this section, we provide some explanations on the dis- provoked by our XSS vector dataset) on which we build the crimination power of HTML parser quirks. The arguments fingerprinting technique. The two research questions are: RQ1) come from observations done during the experiments, as well Can we observe general trends relating the temporal distance as from the experience of two authors (junior and senior se- of two web browser instances with their exhibited quirks? curity engineers in an IT security company). These arguments RQ2) Does the discrimination power of quirks decrease when form a kind of taxonomy of XSS vectors. the versions of a given web browser family are close? a) Vendor-dependent Vectors: Some vendors (especially Figure 3 answers to those questions. Each plot represents a Opera and Microsoft Internet Explorer) ship a large variety of pair of web browser instances. The X-axis value is the time features that are unique. This includes CSS expressions, Visual period in days of the release dates of the two browsers. The Basic Script support, CSS vendor prefixes such as -o-link Y-axis value is the Hamming distance between both as defined and other exclusive and often non-standard features. Gecko- above. What we see in this figure is that there is no general based user agents supported by an installed Java Runtime rule of the form, the longer between two versions, the more Engine (JRE) and corresponding browser plugin support a differences between HTML quirks. Also, HTML quirks cannot non-standard feature called LiveConnect. Those unique ven- be only related to JavaScript or HTML evolution. dor features often come with XSS holes (vendor dependent This is a strong argument in favor of our approach because vectors), and are gold for fingerprinting. For instance, vector it means that one can trust the fingerprinting prediction, even #397 selected by the classifier is known to work only under if the client browser is of an unknown type. Firefox family browsers. Concerning RQ2, we go more in depth in the analysis and b) Feature-dependent Vectors: Some XSS vectors de- consider local factors, that may be related to the development pend on a specific feature (yet not vendor specific). Example process into a same web browser family. Usually regression are the VML-based JavaScript execution and DOM modifica- tests are run to ensure that a new version does not behave in a tion vectors functioning in older versions of Microsoft Internet different manner than the previous one, at least for its existing Explorer (IE). Indeed, IE browser is the one supporting the functionalities. We should thus observe that two versions close legacy VML feature (a vector graphics format predecessor of from a temporal viewpoint have nearly the same Hamming SVG – Scalable Vector Graphics). It has to be noted as that distance. As an example, Figure 4 (Opera alone) plots every support for this feature started with version 5.5 and ended pair of web browser versions for Opera. Surprisingly, no clear with version 8. Following versions 9 and 10 are not able to trend appears. This also applies to other browser families. render VML-based images without further effort, document It seems that there is no systematic development processes mode switches or additionally loaded behavior files. On the explaining the apparition or desperation of HTML browser other hand, early versions of Internet Explorer are not capable quirks. For browser fingerprinting, this is again very valuable, of displaying SVG images properly – while IE9 and IE10 do. because it enables us to also discriminate between two close c) Version-dependent Vectors: Some quirks are really browser versions. For instance, as shown in Table IX, we are dependent on the version, especially HTML5-based XSS vec- to very clearly discriminate between Safari 4.0.4 and Safari tors. Partial feature support can usually be detected without 8 TABLE VII: Confusion matrix Second, we have shown that our technique enables defend- classified as a b c d e f ers to precisely determine the browser family and version. a = Safari 11 0 0 0 0 0 However, in reality, most users will be using IE, Chrome, b = Firefox 0 15 0 0 0 0 c = IE 0 0 6 0 0 0 or Firefox at their latest versions. In other terms, an attacker d = Opera 0 0 0 6 0 0 would just have to deploy a handful of browsers at runtime e = Android 0 0 0 0 14 1 as a counter measure to our fingerprinting approach. This f = Chrome 0 0 0 0 0 19 is not only a limitation, in order to defeat spoofing of our fingerprinting technique, it is a good idea to use a ”rare” browser, both in terms of family and version. large effort and allows very distinct version determination. Third, XSS bugs get fixed over time. This may be a An example for this classification is the support for features limitation since our fingerprinting capabilities may decrease such as Iframe sandboxes and the srcdoc functionality. Google over time. So far, this is not true. According to our empirical Chrome and Webkit browsers implemented partial support for data, until now, the rate of XSS introduction (due to new it, and made many minor releases until full its implementation. features) is comparable to the rate of XSS removals (due to As a consequence, fingerprinting across such minor versions bug fixing). among the same browser family can be accomplished. Finally, the technique we propose only considers the quirks d) Parser-dependent Vectors: Some very discriminant related to html parsing, which can be seen as a limitation. Our vectors are only dependent on parser specificities such as han- technique cannot fully protect a defender but should be used dling padding characters. Earlier versions of Google Chrome as a lightweight technique to be used in complement to more for instance allowed to use non-printable characters from the heavy-weight techniques (see related work). lower ASCII range to be used as padding in URL protocol handlers. This strange behavior was later on removed and IX. OTHER U SES OF B ROWSER F INGERPRINTING therefore enables a precise fingerprint distinguishing minor versions of Webkit-based browsers. Similar effects can be Whatever the fight is, when the weapons are comparable, observed when testing against tolerance for white-space and harming a target requires the identification of weaknesses line breaks. Man browsers accept exotic characters such as the to adapt the attack accordingly. Conversely, defending from OGHAM SPACE MARK as valid white space and therefore an attacker also requires a similar analysis that enables an semantically relevant part in HTML elements and attributes. appropriate counter-attack. Besides, both opponents will de- Vectors 89,90,128 and 258 selected by the classifier belong to velop their own protecting measures, improving the armor this category. they wear; history has shown many examples of such up-to- e) Mutation Behavior: Many browsers have slightly extreme improvements (e.g. plate armors of late occidental different behaviors once certain DOM properties are being Middle Age). accessed and mutated: it includes the properties innerHTML This symmetrical aspect of a fight, with the same offensive and cssText, DOM nodes and CSS objects. Depending on the weapons, also occurs in nowadays web security, in which the context and browser version, character sequences are being notion of counter-attack is becoming crucial. While an attacker changed, entities are being decoded and escapes removed. will try to identify the exact web browser his victim uses to Special characters and ASCII non-printable may removed or imagine a dedicated attack, a defender of a web site may want mutated as well – and thereby provide yet another goldmine to detect the exact web browser the attacker uses, improving for successful fingerprinting. his ability of counter-attacking him. In this section, we describe such sophisticated couter- f) Recapitulation: There are many sources of HTML measures and malicious usage of browser fingerprinting from parsing specificities (vendors, features, versions, etc.). The key the viewpoint of both security engineers and malicious attack- reason of our fingerprinting capability resides in using all of ers. them in a single unified framework of testable parsing quirks of the form of XSS vectors. A. Browser Exploit Kits Malware propagation via browsers is done through browsers C. Limitations exploit kits. This is a piece of server side software that We now discuss the important limitations of our approach. fingerprints client browsers in order to deliver malware. Users First, a common weakness of browser fingerprinting tools is are attracted to such malicious servers through advertisement that responses from the browser can be forged by the attacker: systems or compromised websites. For instance, users present- the proposed technique does not offer an exception to this ing a Firefox user agent receive an specific exploit based on its rule. To spoof a victim XSS-based fingerprint, an attacker version. These exploits are written in JavaScript for browser must either emulate the behavior of a specific web browser exploits, or in plugin specific languages (VBScript, ActiveX, or have an adaptation environment enabling the deployment Java, Flash . . . ) for plugin specific exploits. of the appropriate web browser at runtime. The economical Browser exploit kits mainly use User Agent to naively aspect of security is a key factor in cyber-attacks, and our fingerprinting browsers. Browser exploit kits rely on browser technique makes user-agent based attacks more costly for the specific capabilities (DOM Tree, VBScript execution . . . ). At attacker. the time of writing, only specific JavaScript engine behaviors 9 [8] are used as an advanced browser fingerprinting mechanism, X. R ELATED W ORK but very few studies are available on the subject. Browser A. Passive OS Fingerprinting (pOf) exploit kits will implement more and more advanced browser In this paper, Lippmann et al. show how OS fingerprinting fingerprinting mechanisms. Studying them improve our under- could be a major advantage in Intrusion Detection Systems: standing of these future issues for malware fighters. the use of the surface of attack of an OS permits to dismiss an alert when a vulnerability cannot be exploited for the identified B. Defense Using Client Side Honeypots OS [13]. We can exploit our works in the same way. The A client side honeypot is a browser like application suited objectives of the paper are to demonstrate 1) how pOf is used to collect browser exploits and malware samples when visiting to determine accurately OS by analyzing TCP/IP packet 2) the an website suspected to host a browser exploit kit [9]. Two evaluation of pOf tools and 3) the assessment of a new clas- family of honeypot exists, low interaction, and high interaction sifier using data mining and pattern classification techniques. honeypot clients (or honey-clients). The main difference between pOf and active fingerprinting Low interaction ones like honeyc [10] are made of spoofed is that pOf does not send frames to the targeted host but browser User Agent and just follow links provided by exploit instead analyses headers of packets exchanged during normal kits and collects any executable they find. These pieces of traffic. Thus, pOf is less accurate than active OS fingerprinting. malware are then automatically submitted to malware analysis Different classifier techniques are presented and evaluated: k- platforms like Anubis [11]. By spoofing various popular user nearest neighbor (KNN), binary tree, Multi-Layer Perceptrons agents and iterating connections on exploit kit URL, a single (MLP) and Support Vector Machine (SVM). The confidence in honey-client can collect a subsequent amount of browser a technique depends on the number of fields analyzed during exploits. However, if the browser exploit kit uses advanced pOf. browser fingerprinting, such low interactions honey-client fail to identify malicious website and to collect malware. B. Passive Fingerprinting of User Agent from Network Flow To overcome this problem, high interaction honey-clients Logs combine are made of instrumented browsers running into virtual machines like phoneyc [12]. “High-interaction” means Yen et al. use machine learning to passively fingerprint that the honey-client can respond to all kind of fingerprinting browsers based on their network behavior [5]. The number of challenges sent by the browser exploit kit (such as JavaScript TCP connections launched, number of requests and frequency, execution). This approach is very heavyweight. By knowing all these parameters are dependent of the browser implemen- browser fingerprints summarizing high interaction fingerprint- tation and provide a Fingerprint that can be automatically ing challenges, low interaction client side honeypots are much built out of Bayesian belief networks. The main advantage easier to build and maintain compared to high interaction of this technique is that it only needs coarse traffic summaries honey-clients. to identify the browser family. They use two techniques to classify browser: per-browser or generic classifiers with a C. Detection of XSS Proxification maximum difference in precision of 15%. Our technique is XSS proxification consists of using a cross-site scripting more accurate since it can fingerprint browser versions (XSS) vulnerability on a website to force the victim’s browser to request web pages on behalf of an attacker and to send C. Fingerprinting using Browser Scripting Environment the result back to it. In other words, it turns the victim Fioravanti proposes usage of various JavaScript features and browser in a traditional HTTP Proxy. The beef project tun- specific API elements to determine the browser family [14]. neling proxy features implement such an attack4 . Detection But these elements collected from JavaScript can be altered of XSS proxification with all kinds of techniques based on by the usage of a specific plugin (like user-agent switcher in TCP network shape, HTTP headers (incl. user-agent) and IP Firefox) or by overwriting the tests results with the correct addresses is vain, since the infected browser itself does the values. The main difference of our approach is that it uses request. However, browser fingerprinting can be used to detect HTML parser specificities, much harder to spoof because it XSS proxification since the browser engine of the attacker is requires the same database of quirks than the fingerprinting likely to be different from the infected engine. database, and modification in the parsing engine itself to implement the behavior. D. Detection of Disguised Crawlers Malicious crawlers tend to use user-agents strings of stan- D. Panopticlick: Browser Uniqueness Fingerprint dard client browsers. On the one hand, they don’t have to de- In this paper, Eckersley et al. collect bits of information clare themselves, on the other hand, this allows them to access from various browser properties (user agent string, screen resources that are restricted to robots and crawlers. Detecting resolution, installed fonts and plug-ins) to fingerprint the user disguised crawlers is especially important to ban clients that browser [3]. These pieces of information are collected through are eating all resources up to all kinds of deny-of-service. We Java, Flash, and JavaScript. Using all these properties a user think that techniques based on browser fingerprinting may be can sometimes be uniquely identified. Compared to our work, used to detect whether a client is a bot or not. the differences are important. First, uniquely identifying a 4 https://github.com/beefproject/beef/wiki/Tunneling-Proxy browser instance does not necessarily imply knowing the 10 browser type and version for attacks or counter-measures. [13] R. Lippmann, D. Fried, K. Piwowarski, and W. Streilein, “Passive Second, Panopticlick uses Java, Flash, and JavaScript, which operating system identification from tcp/ip packet headers,” in Workshop on Data Mining for Computer Security, 2003, p. 40. is a stronger assumption on the client browsers than ours (we [14] M. Fioravanti, “Client fingerprinting via analysis of browser scripting only rely on HTML). However, we think that it would be an environment,” in SANS Information Security Reading Room, 2010. interesting area of future work to combine our approach with Java, Flash, or JavaScript fingerprinting mechanisms. E. Fingerprinting Information in JavaScript Implementation Mowery et al. use measures from 39 performance tests to generate a signature in the form of a 39 dimension vector representing test timing results [4]. They have a browser family detection rate of 98.2% in the conditions of the experiment. But when dealing with subversions of given browsers, the precision drops to 79.8% for major version identification. The most interesting contribution is the underlying architecture fingerprinting capability. XI. C ONCLUSION In this paper, we have presented an approach to fingerprint- ing web browsers based on XSS vectors. This approach is able to perfectly fingerprint 78% of our browser dataset. To fingerprint only the browser family, the recognition ratio is 98% with only six XSS vectors to be executed. We are now working on extending our browser signature database using Amazon’s Mechanical Turk. We also plan to mix different browser fingerprinting techniques (JavaScript, network traffic, etc.) to achieve even higher recognition rates. R EFERENCES [1] R. Adhami and P. Meenen, “Fingerprinting for security,” Potentials, IEEE, vol. 20, no. 3, pp. 33–38, 2001. [2] L. Greenwald and T. Thomas, “Toward undetected operating system fin- gerprinting,” in Proceedings of the first USENIX workshop on Offensive Technologies. USENIX Association, 2007, pp. 1–10. [3] P. Eckersley, “How unique is your web browser?” in Privacy Enhancing Technologies. Springer, 2010, pp. 1–18. [4] K. Mowery, D. Bogenreif, S. Yilek, and H. Shacham, “Fingerprinting information in javascript implementations,” in Proceedings of Web, vol. 2, 2011. [5] T. Yen, X. Huang, F. Monrose, and M. Reiter, “Browser fingerprinting from coarse traffic summaries: Techniques and implications,” Detection of Intrusions and Malware, and Vulnerability Assessment, pp. 157–175, 2009. [6] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. Witten, “The weka data mining software: an update,” ACM SIGKDD Explorations Newsletter, vol. 11, no. 1, pp. 10–18, 2009. [7] J. Quinlan, C4. 5: programs for machine learning. Morgan kaufmann, 1993. [8] M. Egele, P. Wurzinger, C. Kruegel, and E. Kirda, “Defending browsers against drive-by downloads: Mitigating heap-spraying code injection attacks,” Detection of Intrusions and Malware, and Vulnerability As- sessment, pp. 88–106, 2009. [9] N. Provos, “A virtual honeypot framework,” in Proceedings of the 13th USENIX security symposium, vol. 132, 2004. [10] C. Seifert, I. Welch, P. Komisarczuk et al., “Honeyc-the low-interaction client honeypot,” Proceedings of the 2007 NZCSRCS, Waikato Univer- sity, Hamilton, New Zealand, 2007. [11] U. Bayer, A. Moser, C. Kruegel, and E. Kirda, “Dynamic analysis of malicious code,” Journal in Computer Virology, vol. 2, no. 1, pp. 67–77, 2006. [12] J. Nazario, “Phoneyc: a virtual client honeypot,” in Proceedings of the 2nd USENIX conference on Large-scale exploits and emergent threats: botnets, spyware, worms, and more. USENIX Association, 2009, pp. 6–6. 11 Fig. 3: Analysis of the relation between browser birth date and modified Hamminng distance. Fig. 4: Analysis of the relation between browser birth date and modified Hamminng distance for the Opera family 12 TABLE VIII: Distance analysis using Modified Hamming Distance (first part) Browser Nearest Neighbor (MHD) MHD MDF Fsize MDD #89 - Origin Browser #28 - Safari 5.1.5/MacOSX 10.7.3 3 - 1 129.0 #25 - fbx v6 #8 - Safari 5.1.5 7 - 1 127.5 #27 - Rekonq Linux #40 - Safari 5.0.6 15 - 1 131.0 #11 - Konqueror 4.7.4/KHTML #46 - Chrome 3.0.182.2 52 - 1 88.5 #5 - Firefox 11.0/Win7 #39 - Firefox 11.0 0 0,5 15 67.5 #9 - Firefox 10.0/Ubuntu/Linaro #39 - Firefox 11.0 0 0,5 15 67.5 #16 - Mozilla Firefox 11.0 Ubuntu #39 - Firefox 11.0 0 0,5 15 67.5 #21 - Firefox 10 #39 - Firefox 11.0 0 0,5 15 62.5 #39 - Firefox 11.0 #59 - Mozilla Firefox 9.0 0 0,5 15 67.5 #51 - Mozilla Firefox 8.0 #39 - Firefox 11.0 0 0,5 15 67.5 #59 - Mozilla Firefox 9.0 #39 - Firefox 11.0 0 0,5 15 67.5 #60 - Mozilla Firefox 10.0 #39 - Firefox 11.0 0 0,5 15 67.5 #4 - Firefox 8.0.1 #88 - Firefox 11.0 linux 0 1 15 68.5 #88 - Firefox 11.0 linux #4 - Firefox 8.0.1 0 1 15 68.5 #62 - Chrome 12.0.742.91 #63 - Chrome 13.0.782.99 0 2 19 71.5 #63 - Chrome 13.0.782.99 #62 - Chrome 12.0.742.91 0 2 19 71.5 #58 - Chrome 10.0.648.133 #57 - Chrome 9.0.597.94 1 3 19 72.5 #1 - Chrome 18.0 #15 - Chromium 18.0 0 3,5 19 69.5 #15 - Chromium 18.0 #65 - Chrome 16 0 3,5 19 69.5 #64 - Chrome 14.0.814.0 #15 - Chromium 18.0 0 3,5 19 69.5 #65 - Chrome 16 #15 - Chromium 18.0 0 3,5 19 69.5 #70 - Chrome 17.0.963.8 #15 - Chromium 18.0 0 3,5 19 69.5 #75 - Chrome 18 / Win XP 32 #15 - Chromium 18.0 0 3,5 19 69.5 #66 - Chrome 15.0.874.106 #15 - Chromium 18.0 1 3,5 19 69.5 #56 - Chrome 8.0.552.215 #57 - Chrome 9.0.597.94 0 4 19 73.5 #57 - Chrome 9.0.597.94 #56 - Chrome 8.0.552.215 0 4 19 73.5 #83 - Firefox 11.0 #4 - Firefox 8.0.1 4 5 15 70.0 #19 - Firefox 7.0 #39 - Firefox 11.0 5 5 15 70.5 #55 - Chrome 7.0.517.41 #57 - Chrome 9.0.597.94 3 7 19 72.5 #53 - Chrome 6.0.453.1 #57 - Chrome 9.0.597.94 7 7,5 19 72.0 #96 - Chrome Nexus S #15 - Chromium 18.0 6 8,5 19 69.5 #73 - Chrome 18.0 #15 - Chromium 18.0 9 11 19 76.5 #68 - Opera 11.65 Mac OS X 10.7.3 #2 - Opera 11.11 9 14 6 124.0 #107 - IE 9 #3 - IE 9.0 9 17,5 6 69.0 #24 - IE 7.0 #86 - IE 7.0 1 21 6 76.0 #86 - IE 7.0 #24 - IE 7.0 1 21 6 77.0 #2 - Opera 11.11 #7 - Opera 11.52/Win7 3 21 6 136.0 #84 - IE 7.0 #86 - IE 7.0 4 22 6 78.0 13 TABLE IX: Distance analysis using Modified Hamming Distance (second part) Browser nearest neighbor (MHD) MHD MDF Fsize MDD #7 - Opera 11.52/Win7 #2 - Opera 11.11 3 24 6 134.0 #18 - Opera 11.62 #68 - Opera 11.65 Mac OS X 10.7.3 14 24 6 133.0 #31 - Firefox 3.0.17 #32 - Firefox 3.0.15 0 25 15 79.5 #32 - Firefox 3.0.15 #31 - Firefox 3.0.17 0 25 15 79.5 #29 - Firefox 3.0.6 #31 - Firefox 3.0.17 2 25 15 81.5 #85 - IE 8.0 #107 - IE 9 23 25,5 6 100.0 #95 - Android 2.3.3 #94 - ANdroid 2.3.1 13 26 15 160.5 #100 - Samsung galaxy ace #105 - Samsung Galaxy S 13 26,5 15 151.0 #104 - LG p970 #106 - Sony Xperia s 11 27 15 142.0 #94 - ANdroid 2.3.1 #95 - Android 2.3.3 13 27 15 154.5 #106 - Sony Xperia s #104 - LG p970 11 27,5 15 152.5 #101 - Samsung galaxy y #100 - Samsung Galaxy Ace 13 29 15 154.5 #105 - Samsung galaxy s #100 - Samsung Galaxy Ace 13 30 15 155.0 #48 - Chrome 4.0.223.11 #52 - Chrome 5.0.307.1 4 31 19 73.5 #52 - Chrome 5.0.307.1 #48 - Chrome 4.0.223.11 4 31 19 75.5 #98 - Samsung galaxy tab #104 - lg p970 15 31 15 157.0 #3 - IE 9.0 #107 - IE 9 9 32,5 6 85.0 #17 - Internet Explorer 9 Win 7 64b #107 - IE 9 15 35 6 80.0 #46 - Chrome 3.0.182.2 #48 - Chrome 4.0.223.11 10 37 19 64.5 #6 - Opera 12/Android 2.3.3 #68 - Opera 11.65 Mac OS X 10.7.3 27 37 6 127.0 #79 - Android 1.5 #80 - Android 1.6 19 39 15 144.0 #80 - Android 1.6 #79 - Android 1.5 19 41,5 15 147.0 #99 - HTC Desire hd #100 - Samsung Galaxy Ace 40 44,5 15 151.5 #82 - Android 2.1 #95 - Android 2.3.3 38 47 15 158.5 #37 - Opera 10.6 #2 - Opera 11.11 41 49 6 127.0 #92 - Safari 3.2.1 #91 - Safari 3.1.2 1 54 11 149.0 #91 - Safari 3.1.2 #92 - Safari 3.2.1 1 56,5 11 148.0 #69 - Safari 4.0.4 #90 - Safari 4.0.5 13 60,5 11 148.5 #81 - Safari 5.0.5 #69 - Safari 4.0.4 20 64,5 11 152.5 #40 - Safari 5.0.6 #8 - Safari 5.1.5 9 65 11 126.0 #90 - Safari 4.0.5 #69 - Safari 4.0.4 13 65,5 11 157.0 #28 - Safari 5.1.5/MacOSX 10.7.3 #89 - Origin Browser 3 68 11 132.0 #8 - Safari 5.1.5 #25 - fbx v6 7 68,5 11 121.5 #87 - Safari iPhone #40 - Safari 5.0.6 25 74 11 138.0 #23 - Safari 5 Windows 7 64b #8 - Safari 5.1.5 19 75 11 119.5 #103 - Android 3.0 #28 - Safari 5.1.5/MacOSX 10.7.3 21 78 15 135.0 #93 - Safari 3.0.4 #92 - Safari 3.2.1 41 81,5 11 181.0 #74 - Samsung GT-S5570 Android #11 - Konqueror 4.7.4/KHTML 116 139 15 137.5 #97 - Google Samsung Nexus #96 - Chrome Nexus S 10 151,5 15 69.5