HTML Filtering Proxy Framework

1
HTML Filtering Proxy Framework

• Project Participants
• Yunduan Bao
• Xing Fang
• Prakarn Unachak
• CSE870 Advanced Software Engineering, Spring 2001
• Instructor Dr. B. Cheng

2
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.

3
HTML Filtering Proxy

• HTML filtering proxy will deleted or modified
  incoming HTML web pages as specified.

Image Filtering Proxy
4
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.

5
HTML Filtering Proxy(cont.)

• How HTML filtering in Muffin works
• Scanning HTML token by token, remove/modified
  unwanted set of tokens.

lt/titlegtltscriptgtlt/scriptgtlt/headgt
Filter
lt/titlegtlt/headgt
6
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 filters 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.

7
The First IterationUML
8
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.

9
The Second IterationUML
10
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.

11
The Third IterationUML
12
CookieMonster

• Monitor all HTTP request and reply for cookie. If
  found, will take out cookie header to disable
  cookie.

13
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.

14
CookieMonster(cont.)

• UML of applying CookieMonster to the first
  iteration of the framework.

15
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.

16
CookieMonster(cont.)

• UML of applying CookieMonster to the second
  iteration of the framework.

17
CookieMonster(cont.)

• There are a few changes in class CookieMonster to
  apply CookieMonster to the third iteration of our
  framework.

18
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).

19
Decaf(cont.)

• UML of applying CookieMonster to the second
  iteration of the framework.

20
Decaf(cont.)

• In the third iteration, some of methods in class
  DecafFilter have been moved to superclass
  RRCFilter.

21
AnimationKiller

• Detect animation image (GIF89) and perform the
  following action
• Modify animation loops.
• OR
• Replace image by broken image.

22
AnimationKiller(cont.)

• Like the first two applications, attributes that
  are common and methods that have common
  implementation are relocated to the superclasses.

23
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.