Mini Project I: Literature Search

Fernando Galindo Michal Janku

fegal10@student.sdu.dk mijan10@student.sdu.dk
Dušan Pilný
dupil10@student.sdu.dk
September 24, 2010

1 Introduction
This mini projects looks at 3 different articles. JavaScript is in most of the web-
sites and implements important parts of them. It is important that JavaScript
programs run fast, although they have dynamic features which have to be
checked while the program is running and might affect people perception.
It is important to say, that not even JavaScript is perfect. Browsing web
pages coded in JavaScript code can cause plenty of security problems. Fortu-
nately there are many new research on this questions, that offer us new inventive
solution and make browsing web pages safer.
The first article tries to present a solution based on points-to analysis based
on some constrains. The second article describes security risks of browsing web
pages via Mozzila, which are created in JavaScript code. It also characterizes
ordinarily used security policies implemented in Mozzila.The third article deal
about V8 JavaScript engine. In this article are shown main reasons to develop
V8 JavaScript engine. The main part of the article was devoted to introduce
function and performance of garbage collector.

1.1 Point-to Analysis for JavaScript [5]

Summary 1: The article evaluates a points-to analysis for JavaScript. In
JavaScript objects are stored in an associative array. When we try to access a
property of an object we do not know if that property had been created yet,
because the name of the property is a string that is statically unknown. This
property name is resolved while program is running. This article tries to find
a solution of this dynamic feature of JavaScript while we are accessing objects
properties. If there are less dynamic features, programs will run faster.
The article defines a restricted language of JavaScript called SimpleScript
that is based on Thiemanns’s work [6] so that it can focus in the main idea of this
research (points-to Analysis). But it does not worth mention this language here.
After that, they define a ”flow- and context insensitive points-to analysis” it is
based on set expressions, constraint generation rules and constraint solving rules
for SimpleScript. They show how rules are applied in SimpleScripts expression,
creating new simpler constrains, which finally they can be solved modifying

1
original expressions. Modification of original expressions is a process that can
be computed to get the solution.
Results for prototype that they have done run a popular JavaScript bench-
mark. Average time for execution programs is less than 200 microseconds; this
means that this prototype could be done at runtime. Also results focus on es-
pecial case ”Redundant Property References”, these References are present in
most JavaScript programs, so trying to eliminate these References will improve
JavaScript execution time. Elimination of Redundant Property References has
to be done on source code level; this technique transformation introduces new
assignment expressions in the code that must be taken into account while bench-
marks are running. In all cases shown applying this technique, reduce execution
time of programs.It is important to mark that all improves, like shown in arti-
cle, that can be made in a JavaScript program benefits execution time making
efficient code that is very useful.

1.2 Detecting malicius JavaScript code in Mozilla [2]

Summary 2:The JavaScript language is used to enhance the visage of web
pages. It is common, that JavaScript code is embedded in HTML code. JavaScript
code yields security risk, because there can be executed accesses from the
JavaScript engine to the OS through the browser process. This can lead in
steal of sensitive personal information or other threats. Today’s JavaScript se-
curity solution is based on executing JavaScript code within a sand-box, which
allows the code to perform a restricted set of operations and which is similar to
Java sand-box.
JavaScript code is parsed, compiled, and executed by SpiderMonkey, which is
embedded in Mozzila. Mozilla is open-source software written in both C, C++,
and implements two main JavaScript security policies the same-origin policy
and the signed-script policy. The same-origin policy saves documents or scripts
loaded from one protocol, host, and port, from getting or setting properties of a
document from a another protocol, host, and port. It isolates the scripts from
different origin thereby it ensures that downloaded document cannot be changed
by JavaScript code from different source. The signed-script policy offers to a
user more choices how to define a different security policy and offers to scripts
more functionality. It also allows get a script out of the sand-box. Mozilla
also implements configurable security policies (CAPS), which empowers user to
configure his own security policies. Another different sand-boxing method was
created. It is called Janus. But both mentioned methods are too general.
By default, JavaScript code is not able to read files on the local drive .
Communication between JavaScript, Java applets and other plugins is provided
by LiveConnect technology. By using LiveConnect, signed scripts with correct
privileges are able to access Java classes implemented in web browser that allow
writing and reading to files and directories. Malicious code can abuse this access
to Java classes in order to attack the computer. Systems for detection malicious
code can be divided into two main groups: anomaly detection systems and
misuse detection systems. Anomaly detection systems define ”default” script
behavior and confront it with behavior of downloaded script. Every divergences
are evaluated as a problem. The second is based on knowledge in a large set
of predefined attack scenarios. It compares operation of a downloaded script
to every element of this set. Usual examples of malicious JavaScript Codes are

2
Crosssite scripting, permanently calling Windows.alert() in short interval, which
leads to impossibility of exit Windows.
The paper, I was focused on, offered potential solution of mentioned prob-
lems. Unfortunately additional code extends computational time and therefore
should be optimized. I was not able to find any method of testing additional
code of success in a protecting against malicious code.

1.3 V8 JavaScript Engine and Garbage Collector

Summary 3: Before three years Google begun develop own web browser Google
Chrome. Google was decided to apply in Chrome rendering core WebKit (used
in browser Safari developed by Apple). The WebKit core was effective and
easily modifiable. However Google was disappointed with implementation of
JavaScript in WebKit because it was relatively slow and ineffective. Therefore
Google decided to supersede old JavaScriptCore by own implementation and it
was originate of V8 [3].
V8 [4] is thus Googles open source JavaScript engine written in C++.
V8 is especially designed for fast execution of large JavaScript application. In
Many benchmark tests V8 is faster than Jscript (IE), SpiderMonkey (Firefox)
or JavaScriptCore (Safari). The size of the improvement depends on how much
JavaScript is executed and the nature of that JavaScript. For example, if the
functions in the application tend to be run again and again, the performance
improvement will be greater than if many different functions tend to run only
once.
One of the huge problems with languages like JavaScript is garbage collec-
tion. The garbage collector inside V8 JavaScript engine is relatively advanced.
To ensure fast object allocation, short garbage collection pauses, and no mem-
ory fragmentation V8 employs a stop-the-world, generational, accurate, garbage
collector [1]. In the moment when V8 decide to clean up memory it stops pro-
gram execution. Memory space of allocated JavaScript objects is denoted as
”old” and it is prepared new memory place. Consequently all objects from old
memory which are accessible from running program are copied to new memory
space and pointers to these objects are actualized (refreshed). When copying
all accessible objects from old memory space is finished, the old memory space
is reallocated and all inaccessible objects from running program are deleted.
By executing garbage collection are copied just only accessible objects. The
pointers in the table of variables are refreshed. The process of garbage collection
is time demanding and in the time of executing garbage collection is program
stopped. In fact process of garbage collection executes piecewise. It means that
garbage collector doesnt process all object together, but alternatively triggers
program and executing of garbage collection. In consequence of this process
is dividing one long time pause to several smaller time pauses which user cant
recognise.

2 Research Questions
1. Why are Points-to Analysis for each programing language (Java, C, JavaScript...)?Is
not posible to make a Analysis for all of them?

3
 2. Does the auditing code work properly? How was it tested? Are results of
success in a protecting against malicious code satisfactory?

3. It would be very interesting monitoring comparison computing intensity

of smaller JavaScript applications executes by V8 JavaScript Engine and
implementations of Mozilla Firefox or Safari.

3 Assessment
The JavaScript code is widely spread on world wide web, hence it is good cause
to be engaged in this theme. In other words it is important to investigate
all its shortcomings and try to solve them. But there are many positives of
JavaScript. It is good to pay interest on them and continue in their developing.
JavaScript code is also good and comfortable way how to convert static web-
site into dynamic website and enhance display of users web pages, but on the
other hand there are also different solutions how to reach these improvements
at the present time, which are not so hazardous. The methods and techniques
introduced in previous article are not revolutionary and are used several years.
However these techniques were used at first in interpreter of JavaScript of web
browser. Very often these techniques are not implemented in interpreters of the
others dynamic script languages maybe therefore that it is very hard to develop
high-quality garbage collector.

References
[1] David Flanagan. JavaScript: The Definitive Guide. O’Reilly & Associates,
Inc., Sebastopol, CA, USA, 2006.
[2] Oystein Hallaraker and Giovanni Vigna. Detecting Malicious JavaScript
Code in Mozilla. In ICECCS ’05: Proceedings of the 10th IEEE International
Conference on Engineering of Complex Computer Systems, pages 85–94,
Washington, DC, USA, 2005. IEEE Computer Society.
[3] Oystein Hallaraker and Giovanni Vigna. V8 JavaScript Engine,
http://code.google.com/intl/cs-cz/apis/v8/terms.html. 2008.
[4] Hallaraker, Oystein and Vigna, Giovanni. V8: JavaScript in-
side Google Chrome : Serial Do hlubin implementaci JavaScriptu,
http://zdrojak.root.cz/clanky/v8-javascript-uvnitr-google-chrome, 2009.
[5] Dongseok Jang and Kwang-Moo Choe. Points-to analysis for JavaScript. In
SAC ’09: Proceedings of the 2009 ACM symposium on Applied Computing,
pages 1930–1937, New York, NY, USA, 2009. ACM.

[6] P. Thiemann. Towards a type system for analyzing JavaScript programs.

European Symposium On programing, pages 408–422, 2005.

4 Apendix
Work division and workload

4
• Article research: By Fernando Galindo (33.3%), Dušan Pilný (33.3%)
and Michal Janku (33.3%)

• Introduction: By Fernando Galindo (33.3%), Dušan Pilný (33.3%) and

Michal Janku (33.3%)
• Summary 1: Made by Fernando Galindo. Edited by Fernando Galindo.
• Summary 2: Made by Dušan Pilný. Edited by Dušan Pilný.

• Summary 3: Made by Michal Janku. Editen by Michal Janku.

• Assesment: By Fernando Galindo (33.3%), Dušan Pilný (33.3%) and
Michal Janku (33.3%)