Our approach does not make any assumption on the architecture or libraries of web applications. First, proxy servers are used in most web architectures. Second, our approach does not require a single change to existing web pages and applications. As such, BikiniProxy is highly applicable and could be embedded in a service like Amazon/CloudFlare111https://cloudflare.com.
Our contributions are:
The design and implementation of a novel self-healing proxy, BikiniProxy, for today’s web.
An open-source implementation of BikiniProxy, publicly available for future research (repo, ).
The remainder of this paper is organized as follows. Section 2 explains the background of BikiniProxy. Section 3 details the BikiniProxy approach. Section 4 details the evaluation. Section 5 details the threats to validity of the contribution. Section 6 presents the related works and Section 7 concludes.
2.1. The Complexity of Today’s Web
2.3. Web Proxies
A web proxy is to be an intermediate component between a client browser and web server. In essence, a proxy transmits the client request to the server, receives the response from the server, and forwards it to the client browser. On the web, proxies are massively used for different purposes.
A Network Proxy is used to expose a service that is not directly accessible, because of network restrictions (luotonen1998web, ). The proxy, in this case, is a bridge between two networks and its only task is to redirect requests and responses. For example, a popular network proxy is nginx, it is used to expose websites on port 80 which are indeed served on other ports , this avoids granting root access to web applications.
A Cache Proxy is a proxy that is used to cache some resources directly in the proxy in order to improve the serving time to an external resource (pistriotto2000method, ). The cache proxy stores the response of the server locally and if a request is made for the same resource, the local version is directly sent to the client without sending the request to the server. A wildly used cache proxy is, for example, a content-delivery network (CDN) that provides optimized access to static resources on the Internet.
A Security Proxy is used to verify whether a client browser is legitimate to access a server (krueger2010tokdoc, ). This type of proxy can be used for example to protect a server against Denial-of-service attacks.
A Load-balancer Proxy is used on popular applications to distribute the load of users on different backend servers (bowman2003load, ). A load balancer can be as simple as a round-robin, but can also be more sophisticated. For instance, a load-balancer can try to find the least loaded server available in the pool.
2.4. Self-healing Software
Self-healing software refers to the idea that it is possible to engineer fully automated error recovery for software. Berger nicely puts it as software seatbelts and airbags (Berger2012, ). For instance, self-healing can consist of restoring invariants (demsky2003automatic, ). The literature uses different expressions to refer to this very same idea: automated recovery (gu2016automatic, ), failure-oblivious computing (rinard2004enhancing, ), runtime repair (lewis2010runtime, ). Note that “runtime repair” and “program repair”, although they share the word “repair” are fundamentally different (monperrus2014critical, ; baudry2015multiple, ): the former happens at runtime in production, and does not involve patches for developers, while the latter is offline and consists of generating patches for human developers. Despite its potential impact, self-healing capabilities for web applications is a very little researched area (carzaniga2010automatic, ; carzaniga2015automatic, ).
The intuition behind BikiniProxy is that a proxy between web applications and the end-users could provide the required monitoring and intercession interface for automatic error handling. This is the concept of ‘‘self-healing proxy’’ that we explore in this paper.
Figure 1 presents the architecture of BikiniProxy. BikiniProxy is composed of three main parts.
The Monitoring and Self-healing Backend (see Section 3.1.3) stores information about the known errors that have happened and the success statistic of each self-healing strategies for each error.
Let us start with a concrete example. Bob, a user of the website http://foo.com browses the page gallery.html and uses BikiniProxy to improve his web experience. Since BikiniProxy is a proxy, when Bob opens gallery.html, the request goes through the proxy. When the request is made, BikiniProxy queries the backend to know whether another, say Alice, has experienced errors on gallery.html. Indeed, Alice’s browser got a jQuery is not defined error two days before. The backend sends this error to the proxy, which consequently launches the JS/HTML Rewriter service to handle the error. For gallery.html, the rewriting is HTML-based and consists of by injecting the library jQuery in the HTML response. BikiniProxy also injects its error monitoring framework before sending the rewritten response to Bob’s browser. The rewritten page is executed by Bob’s browser, BikiniProxy’s monitoring tells the proxy that Alice’s error does not appear anymore, meaning that the rewriting strategy made it disappeared.
Definition 3.1 (Resource).
3.1.1. The Proxy
3.1.2. JS/HTML Rewriter
HTTP/HTTPS Redirector that changes HTTP URLs to HTTPS URLs.
HTML Element Creator that creates missing HTML elements.
Library Injector injects missing libraries in the page.
Line Skipper wraps a statement with an if to prevent invalid object access.
Object Creator initializes a variable with an empty object to prevent further null dereferences.
In addition, the JS/HTML Rewriter is plugin-based, it can be easily extended with new self-healing strategies to follow the fast evolution of the web environment.
The modern browsers have a policy to block unsecured content (i.e. HTTP resources) in secured web pages (HTTPS).
For example, https://foo.com cannot load
http://foo.com/f.js (no https). The rationale is that the unsecured requests can be easily intercepted and modified to inject scripts that will steal information from the secure page, for example, your banking information.
The self-healing strategy of HTTP/HTTPS Redirector is to change all the HTTP URL by HTTPS URL in HTTPS pages. By doing this, all resources are loaded and the unwanted behavior due to blocked resources is fixed.
HTML Element Creator
To do so, BikiniProxy has an initial offline training phase, missing libraries are simulated on a test website, and reference errors are collected for the top 10 libraries presented in (rankinglib, ). Based on these reference errors, error parsing rules have been manually written to determine which library is missing. When Library Injector detects that a web page contains an error related to a missing library, it injects the related library in the web page. The rewritten page contains the missing library and the web page can be completely loaded.
The second error, XXX is not a function, is triggered when a variable that is not a function is called. For example, the code var func = null; func() will trigger the error func is not a function.
3.1.3. Monitoring and Self-healing Backend
The third task is to provide a layout of communication with the developers about the monitored errors and the effectiveness of all self-healing strategies. For example, the following message can be given to the developer: ”The strategy Library Injector has injected jQuery 22 times in the page gallery.html to handle the error jQuery is not defined ”. This is valuable information to assist the developers in designing a permanent fix. And BikiniProxy backend also provides a visual interface that lists all the errors that the end-users face during the browsing of the web page.
The usage of BikiniProxy is practically zero cost, and as such, it is widely applicable. First, it requires no change to the original web pages or applications. Second, the usage of an HTTP proxy in web application is very common. A BikiniProxy self-healing proxies can be set up by: 1) a company in front of their web content; 2) a SaaS-based provider 3) a hosting service. Thus, BikiniProxy is an highly-applicable solution.
BikiniProxy can be a new technology to enrich an existing proxy solution. For example, Cloudflare by Amazon 666https://cloudflare.com is a professional proxy provider developed by Amazon.com. It provides different services for websites: it offers caching, protection against DDoS (Attack by Denied-of-Service), etc. BikiniProxy’s approach would perfectly integrate into Cloudflare (or another proxy company) to provide further added value.
In our evaluation, we answer the following research questions.
RQ2. [Outcome] What is the outcome of BikiniProxy’s self-healing strategies on the page beyond making the error disappear? In this research question, we explore what are the possible outcomes of BikiniProxy on buggy web pages. We will answer this research question by presenting real-world case studies of different possible outcomes.
RQ3. [Comparison] Do the different self-healing strategies perform equivalently? Finally, we present to which extent the different self-healing strategies are used: Which type of errors are handled by the five self-healing strategies?
We set up the following experimentation protocol to evaluate BikiniProxy. Our idea is to compare the behavior of an erroneous web page, against the behavior of the same, but self-healed page using our BikiniProxy. The comparison is made at the level of “web trace”, a concept we introduce in this paper, defined as follows.
Definition 4.1 (web trace).
The second step is to collect the new web trace of each erroneous web page with BikiniProxy (Recall that all resources are rewritten by BikiniProxy self-healing strategies). In addition to the web trace, we also collect data about the self-healing process: the strategies that have been activated, defined by the tuple (initial error, strategy type).
4.2.1. Web Page Finder
The first step of the creation of DeadClick is finding web pages that contain errors. In order to have a representative picture of errors on the Internet, we use a random approach. Our methodology is to take randomly two words from the English dictionary, and to combine those two words in a Google search request. A fake crawler then opens the first link that Google provides. If an error is detected on this page, the page URL is kept as tentative for the next step. The pros and cons of this methodology are discussed in Section 5
|# Visited Pages||96174|
|# Pages with Error||4282 (4.5%)|
|# Pages with Reproduced Errors||555|
|# Average # resources per page||102.55|
|# Average scripts per page||35.51|
|# Min errors per page||1|
|# Average errors per page||1.49|
|# Max errors per page||10|
|# Average pages size||1.98mb|
4.2.2. Web Trace Collector
For identifying reproducing errors, our idea is to collect the web trace of the erroneous page and to try to reproduce the exact same web trace in a controlled environment, see Section 4.2.3
We implement the trace collection using the library puppeteer from Google777puppeteer repository https://github.com/google/puppeteer, which provides an API to control Chrome in a programmatic manner. The big advantage of this library is that it uses the same browser engine as Chrome end-users, meaning that, by construction, DeadClick is only composed of errors that really happen on user browsers.
During this process, the Web Trace Collector logs 1) all errors that occur in the browser console and 2) all the requests (including the HTTP headers and the body) made from the browser. When the page is completely loaded, a screenshot of the page is taken, it provides a visual representation of the page. At the end of this process, for each page, the collected data is stored on disk if at least one error has been logged during the page browsing.
4.2.3. Web Page Reproduction
The last step of the benchmark creation consists of verifying that the collected errors can be reproduced. We consider that we succeed to reproduce the behavior of the web page when the observed errors during reproduction are identical to the ones in the originally collected web trace.
The reproduction of the error is done by browsing the erroneous page again but instead of using the resources from Internet, the Web Page Reproduction is cut from the Internet and only serves the resources stored on disk. In addition, it denies all the requests that have not been observed during the initial collection of the page.
|#||Error messages||# Web Pages||# Domains||
|1||XXX is not defined||200||166||307||184||59.93%|
|2||Cannot read property XXX of null||156||126||176||42||23.86%|
|3||XXX is not a function||92||86||111||11||9.9%|
|4||Unexpected token X||54||51||61||2||3.27%|
|5||Cannot set property XXX of null||21||17||24||11||45.83%|
|6||Invalid or unexpected token||18||12||21||0||0%|
|8||Script error for: XXX||8||3||10||2||20%|
|9||The manifest specifies content that cannot be displayed on this browser/platform.||5||5||7||0||0%|
|10||adsbygoogle.push() error: No slot||4||4||7||0||0%|
|53 different errors||555||466||826||248||30.02%|
4.3. Description of DeadClick
Table 1 gives the main statistics of DeadClick. The Web Page Finder visited a total of 96174 pages, and 4282 of the pages contains at least one error (4.5%), out of which 555 errors have been successfully reproduced. The final dataset contains errors from 466 different URL domains representing a large diversity of websites. There is on average 1.49 error per page, and each page has between one and ten errors.
4.4. RQ1: Effectiveness of Self-healing Web Applications
|Metric Name||# Pages||Percent|
|All Errors Disappeared||176/555||31.76%|
|Some Errors Disappeared||42/555||7.58%|
|No Strategy Applied||196/555||35.31%|
We now present the results of this first research question. Table 2 shows the top 10 types of errors in the considered benchmark and how they are handled by BikiniProxy. The first column contains the rank of the error type. The second column contains the error type, represented by the message of the error. The third column shows the number of web pages that contain this errors. The fourth column presents the number of different domains where the error is present. The fifth column contains the initial number of occurrences of the error in the DeadClick. The sixth column contains the number of healed error with BikiniProxy. The seventh column contains the percentage of the evolution, a negative percentage represents a decrease of the number of errors, a positive percentage an increase in the number of errors.
The first major result lies in the first row. It presents the error ”XXX is not defined”, which is the most common on the web according to our sampling. This error is present in 200 web pages across 166 different domains. It is thrown 307 times (meaning that some web pages throw it several times). With BikiniProxy, this error is healed 184/307 times, which represents a major improvement of 59.93%.
Now we discuss the categories of healed errors. We identify whether:
All errors disappeared: no error happens anymore in the page loaded with BikiniProxy, meaning that one or a combination of rewriting strategies have removed the errors.
Some errors disappear:, there are fewer errors than in the original web trace.
Different errors appear: at least one error still, and it is a new error (new error type or new error location) that has never been seen before.
No strategy applied: the error type is not handled by any of the strategies and thus there are the same errors than in the original web trace.
4.4.1. Case study: Unhandled Errors
In summary, Table 3 shows that BikiniProxy is almost able to heal all the errors from a third of DeadClick. The second third of the benchmark is pages that cannot be healed with BikiniProxy. The last third contains web pages that are partially headed or that the self-healing strategies produce new errors.
4.5. RQ2: Outcome
In this second research question, we focus on category “All Errors Disappeared”, and further refines the classification as follows:
The errors have disappeared but no behavioral change can be seen by the end-user.
The errors have disappeared and new UI features (eg. new buttons) are available to the end-user.
The errors have disappeared and new content is available for the end-user.
Contrary to RQ1, it is not possible to automatically classify all pages with this refined category, because it requires human-based assessment of what is new content or new features. For this reason, we answer to this RQ with a qualitative case study analysis.
4.5.1. Case study: Error Handled but No Behavior Change
4.5.2. Case study: new Feature Available
With BikiniProxy, the self-healing strategy ”Object Creator” ensures the initialization of the variable if it is null. This execution modification allows the execution to continue and to finally enter in an error handling block written by the developer, meaning that the event loop does not crash anymore. The execution of the page continues and results in two buttons being displayed and enabled for the end-user. Figure 4 presents the two buttons that are now available for the user.
4.5.3. Case study: new content available
One other outcome of BikiniProxy is that additional content is displayed to the end-user.
Let us consider the web page http://personal.lse.ac.uk/birchj1/ that is the personal page of a researcher. This page triggers the following error: $ is not defined at (index):20
This error is thrown because a script in the HTML page calls the jQuery library before the library is loaded. The script that throws the error is responsible to change the visibility of some content in the page. Consequently, because of the error, this content stays hidden for all visitors of the page.
Using BikiniProxy, the error is detected as being caused by a missing jQuery library. This error is healed by rewriting strategy “Library Injector” Consequently, BikiniProxy rewrites the content of the page by injecting the jQuery library and sends back the rewritten page to the browser. When the rewritten script is executed, jQuery is available, and consequently, the script is able to change the visibility of hidden HTML elements, resulting in newly visible content.
Figure 3 presents the visual difference between the page without BikiniProxy (left side), and loaded with BikiniProxy (right side). All the elements in a grey box on the right-hand side are missing on the left image, they have appeared thanks to self-healing.
Answer to RQ2. All three possible outcomes: (1) no visible change; (2) new features; and (3) new content; are present in our benchmark. The fact that BikiniProxy is able to automatically restore broken features or broken content represents a significant improvement to the web experience of all users in front of a BikiniProxy instance.
4.6. RQ3: Strategies
|Self-healing Strategies||# Activations||
|HTML Element Creator||14||2|
In this research question, we compare the five different self-healing strategies of BikiniProxy. For each strategy, Table 4 shows the number of times it has been activated to heal errors of DeadClick, and the last column presents the number of different error types for which the strategy has been selected. For example, the first row of Table 4 shows that “Line Skipper” has been selected to handle 233 errors, and it has healed four different error types.
The most used strategy is ”Line Skipper” with 233 activations. It is also the strategy that supports the highest number of different error type: 1) ”XXX is not defined”, 2) ”XXX is not a function”, 3) ”Cannot read property XXX of null”, 4) ”Cannot set property XXX of null”. The second most used strategy is ”Object Creator” with 109 errors for which it has initialized a null variable. This strategy handles two different error types: ”Cannot set property XXX of null” and ”Cannot read property XXX of null”. These two strategies have something in common, they target the failure point, the symptom, and not the root cause (the root cause is actually unknown). For example, the error CitedRefBlocks is not defined is triggered in the web page https://www.ncbi.nlm.nih.gov/pmc/articles/PMC504719/, because the function CitedRefBlocks is not defined. Line Skipper strategy avoids the error by skipping the method call, it is a typical example of a fix at the failure point and not at the root cause of the absence of CitedRefBlocks.
On the contrary, ”Library Injector” addresses the root cause of the problem: the missing library is extracted from the error message and it is used to rewrite the content of the request. In this case, BikiniProxy exploits the fact that we have a direct relation between root cause (no included library) and symptom (unknown used library name) for this error type.
The case of ”HTTP/HTTPS Redirector” is the opposite. Recall that ”HTTP/HTTPS Redirector” directly looks in the HTML body of the resource if there are scripts that will be blocked. This means that the rewriting addresses the root cause of potential future problems. For example, the page https://corporate.parrot.com/en/documents tries to load the resource http://www.google-analytics.com/urchin.js, but the request is blocked by the browser (HTTP request in an HTTPS page). Consequently, the Google tracking library is not loaded and function urchinTracker is not defined, resulting in the error urchinTracker is not defined. “HTTP/HTTPS Redirector” strategy rewrites the URL of the resource in the <SCRIPT>tag to https://www.google-analytics.com/urchin.js, and this fixes the error of the page. This strategy can potentially fix error types that we cannot envision, hence, we do not know the exact number of handled error types, so we put “NA” in Table 4.
Finally, strategy ”HTML Element Creator” is applied to more rare errors happening only 14 times in our benchmark.
Answer to RQ3. The usage of strategies depends on the prevalence of the underlying errors in the field: in our experiment, the most used strategy is “Line Skipper” because it covers four common error types.
5. Threat to validity
We now discuss the threats to the validity of our experiment. First, let us discuss internal validity. Our experiment is relying on the implementation of our prototype, consequently, a bug in our code may threaten the validity of our results. However, since the source code of the approach and of the benchmark is publicly available (repo, ), future researchers will be able to identify these potential bugs.
Our approach has been carefully designed to maximize representativity, with two main advantages: 1) the randomness of keyword choice allows us to discover website about many different topics, done by a variety of persons, with different backgrounds (on website on CSS done by a web developer is likely to have fewer errors then a website on banana culture done by a hobbyist). 2) the ranking of Google provides us with a filter which favors popular websites. If errors are detected on those websites, they likely affect many users. It means that if BikiniProxy heals those errors, it would have a large impact.
6. Related Work
Self-healing in Production
Rx (qin2005rx, ) is a self-healing system that changes the environment upon failures. Rx employs checkpoint-and-rollback for re-executing the buggy code when failures happen. Assure (sidiroglou2009assure, ) is a self-healing system also based on checkpointing. Perkins et al. (perkins2009automatically, ) propose ClearView, a system for automatically repairing errors in production by monitoring low-level registers to learn invariants. When ClearView detects that an invariant is violated, it forces the restoration of the system to a previous valid state. Rinard et al. (rinard2004enhancing, ) present a technique called “failure-oblivious computing” to avoid illegal memory accesses by wrapping each memory operation during the compilation process. Long et al. (long2014automatic, ) also explore this idea with the concept of “recovery shepherding”.
Carzaniga et al. (carzaniga2012self, ; carzaniga2013automatic, ) present ARMOR a technique for self-healing Java applications based on workaround that can be deployed at runtime. Armor injects checkpoint and rollback mechanism in the application, this mechanism is used to rollback when a failure is detected and explore workaround alternatives.
-  Bikiniproxy repository. https://github.com/Spirals-Team/bikiniproxy/, 2018.
-  We crunched 1 billion java logged errors - here’s what causes 97% of them. https://blog.takipi.com/we-crunched-1-billion-java-logged-errors-heres-what-causes-97-of-them/, 2018.
-  S. Bae, H. Cho, I. Lim, and S. Ryu. Safewapi: Web api misuse detector for web applications. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 507–517. ACM, 2014.
-  B. Baudry and M. Monperrus. The multiple facets of software diversity: Recent developments in year 2000 and beyond. ACM Computing Surveys (CSUR), 48(1):16, 2015.
-  E. Berger. Software Needs Seatbelts and Airbags. ACM Queue, 10, 2012.
-  M. K. Bowman-Amuah. Load balancer in environment services patterns, June 10 2003. US Patent 6,578,068.
-  G. Candea, E. Kiciman, S. Zhang, P. Keyani, and A. Fox. Jagr: An autonomous self-recovering application server. In Autonomic Computing Workshop. 2003. Proceedings of the, pages 168–177. IEEE, 2003.
-  A. Carzaniga, A. Gorla, A. Mattavelli, and N. Perino. A self-healing technique for java applications. In Software Engineering (ICSE), 2012 34th International Conference on, pages 1445–1446. IEEE, 2012.
-  A. Carzaniga, A. Gorla, A. Mattavelli, N. Perino, and M. Pezze. Automatic recovery from runtime failures. In Proceedings of the 2013 International Conference on Software Engineering, pages 782–791. IEEE Press, 2013.
-  A. Carzaniga, A. Gorla, N. Perino, and M. Pezzè. Automatic workarounds for web applications. In Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering, pages 237–246. ACM, 2010.
-  A. Carzaniga, A. Gorla, N. Perino, and M. Pezze. Automatic workarounds: Exploiting the intrinsic redundancy of web applications. ACM Transactions on Software Engineering and Methodology (TOSEM), 24(3):16, 2015.
-  B. Demsky and M. Rinard. Automatic detection and repair of errors in data structures. ACM SIGPLAN Notices, 38(11):78–95, 2003.
-  T. Durieux, B. Cornu, L. Seinturier, and M. Monperrus. Dynamic patch generation for null pointer exceptions using metaprogramming. In Software Analysis, Evolution and Reengineering (SANER), 2017 IEEE 24th International Conference on, pages 349–358. IEEE, 2017.
-  T. Gu, C. Sun, X. Ma, J. Lü, and Z. Su. Automatic runtime recovery via error handler synthesis. In Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, pages 684–695. ACM, 2016.
-  S. A. Gurguis and A. Zeid. Towards autonomic web services: Achieving self-healing using web services. In ACM SIGSOFT Software Engineering Notes, volume 30, pages 1–5. ACM, 2005.
-  E. Kiciman and B. Livshits. Ajaxscope: a platform for remotely monitoring the client-side behavior of web 2.0 applications. In ACM SIGOPS Operating Systems Review, volume 41, pages 17–30. ACM, 2007.
-  T. Krueger, C. Gehl, K. Rieck, and P. Laskov. Tokdoc: A self-healing web application firewall. In Proceedings of the 2010 ACM Symposium on Applied Computing, pages 1846–1853. ACM, 2010.
-  C. Lewis and J. Whitehead. Runtime repair of software faults using event-driven monitoring. In Software Engineering, 2010 ACM/IEEE 32nd International Conference on, volume 2, pages 275–280. IEEE, 2010.
-  F. Long, S. Sidiroglou-Douskos, and M. Rinard. Automatic runtime error repair and containment via recovery shepherding. In ACM SIGPLAN Notices, volume 49, pages 227–238. ACM, 2014.
-  A. Luotonen. Web proxy servers. Prentice-Hall, Inc., 1998.
-  M. Monperrus. A critical review of automatic patch generation learned from human-written patches: essay on the problem statement and the evaluation of automatic software repair. In Proceedings of the 36th International Conference on Software Engineering, pages 234–242. ACM, 2014.
-  J. H. Perkins, S. Kim, S. Larsen, S. Amarasinghe, J. Bachrach, M. Carbin, C. Pacheco, F. Sherwood, S. Sidiroglou, G. Sullivan, W.-F. Wong, Y. Zibin, M. D. Ernst, and M. Rinard. Automatically patching errors in deployed software. In Proceedings of the ACM SIGOPS 22Nd Symposium on Operating Systems Principles, SOSP ’09, pages 87–102, New York, NY, USA, 2009. ACM.
-  J. C. Pistriotto and K. Montinola. Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category id with the request, Oct. 24 2000. US Patent 6,138,162.
-  F. Qin, J. Tucek, J. Sundaresan, and Y. Zhou. Rx: Treating Bugs as Allergies—A Safe Method To Survive Software Failures. SIGOPS OSR ’05.
-  M. C. Rinard, C. Cadar, D. Dumitran, D. M. Roy, T. Leu, and W. S. Beebee. Enhancing server availability and security through failure-oblivious computing. In OSDI, volume 4, pages 21–21, 2004.
-  S. Roy Choudhary, M. R. Prasad, and A. Orso. X-pert: accurate identification of cross-browser issues in web applications. In Proceedings of the 2013 International Conference on Software Engineering, pages 702–711. IEEE Press, 2013.
-  M. Schur, A. Roth, and A. Zeller. Procrawl: Mining test models from multi-user web applications. In Proceedings of the 2014 International Symposium on Software Testing and Analysis, pages 413–416. ACM, 2014.
-  S. Sidiroglou, O. Laadan, C. Perez, N. Viennot, J. Nieh, and A. Keromytis. Assure: automatic software self-healing using rescue points. In ACM Sigplan Notices, volume 44, pages 37–48. ACM, 2009.
-  J. Wang, W. Dou, C. Gao, and J. Wei. Jstrace: Fast reproducing web application errors. Journal of Systems and Software, 2017.
-  X. Zhang, A. S. Ross, A. Caspi, J. Fogarty, and J. O. Wobbrock. Interaction proxies for runtime repair and enhancement of mobile application accessibility. In CHI, 2017.