Transcript HTML Filtering Proxy Framework Project Participants: Yunduan Bao

HTML Filtering Proxy
Framework
Project Participants:
Yunduan Bao
Xing Fang
Prakarn Unachak
CSE870 Advanced Software Engineering, Spring 2001
Instructor: Dr. B. Cheng
Overview
Our work will focus on frameworks for HTML
filtering proxies.
We use Muffin, a collection of filtering proxies
written by Mark Boyns
(http://muffin.doit.org).
Muffin has already provided some degree of
whitebox framework for filters, we will
develop a framework over that to be simpler
to our selected filters, all three of them HTML
filtering proxies.
HTML Filtering Proxy
HTML filtering proxy will deleted or
modified incoming HTML web pages as
specified.
Image
Filtering
Proxy
HTML Filtering Proxy(cont.)
Why do we need HTML filtering proxies.

Performance.
 Remove resource consuming contents.

Security.
 Remove security threat contents.

Content censoring.
 Remove inappropriate contents.

Peace of mind.
 Remove annoying contents.
HTML Filtering Proxy(cont.)
How HTML filtering in Muffin works:

Scanning HTML token by token,
remove/modified unwanted set of tokens.
…</title><script>…</script></head>…
Filter
…</title></head>…
The First Iteration
The framework is construct over AWT
framework and Muffin framework. It contains
three abstract classes (Abstract Factory):



FilterFactory: for filter coordinator.
AbstractFrame: for filter’s setting windows.
RequestReplyFilter: for filtering methods.
Having classes implementing interface in
framework can provide “default methods” for
application filter classes.
Graybox: no longer need to define/override
methods that are thought to be common.
The First Iteration:UML
The Second Iteration
There is only one structural change
from the first iteration.



Class RequestReplyFilter Has been changed
to RRCFilter , which also implements
interface ContentFilter from Muffin
framework.
There are no changes in the other two
classes.
Still graybox.
The Second Iteration:UML
The Third Iteration
Only minor changes. (relocation of
common codes from applications) in
class FilterFactory.
We have tried to make our framework
blackbox, but did not succeed.


We have to add new application by inheritance.
Some methods or each filter (such as creating a
configuration window or the filtering process) are
too different to be combined together.
The Third Iteration:UML
CookieMonster
Monitor all HTTP request and reply for
cookie. If found, will take out cookie
header to disable cookie.
CookieMonster(cont.)
To convert CookieMonster to the first
iteration of the framework, we have
made the following change:


All classes in CookieMonster now inherit
from classes in our framework.
Some of the attributes and methods that
are thought to be common among filters
has been relocated to the superclasses in
our framework.
CookieMonster(cont.)
UML of applying CookieMonster to the
first iteration of the framework.
CookieMonster(cont.)
Applying CookieMonster to the second
iteration of the framework.

There are no changes for CookieMonster in
this level except that class
CookieMonsterFilter now inherits from
superclass RRCFilter instead of
RequestReplyFilter.
CookieMonster(cont.)
UML of applying CookieMonster to the
second iteration of the framework.
CookieMonster(cont.)
There are a few changes in class
CookieMonster to apply CookieMonster
to the third iteration of our framework.
Decaf
Remove Java/JavaScript in HTML by
removing Java/JavaScript tag and their
contents.
The changes we have made to Decaf
are similar to what we have done to
CookieMonster(relocate attributes and
methods that are common among two
filters to Framework).
Decaf(cont.)
UML of applying CookieMonster to the
second iteration of the framework.
Decaf(cont.)
In the third iteration, some of methods
in class DecafFilter have been moved to
superclass RRCFilter.
AnimationKiller
Detect animation image (GIF89) and
perform the following action:

Modify animation loops.
 OR

Replace image by broken image.
AnimationKiller(cont.)
Like the first two applications, attributes
that are common and methods that
have common implementation are
relocated to the superclasses.
Discussion
This system is tightly integrated, we
cannot make any significant change.
What have we learn from developing
frameworks.



Good framework can reduce program
development/extension greatly.
However, develop a good framework can
be very challenging and time consuming.
The key is to know “what to do” and “on
what”.