NNSquad - Network Neutrality Squad
[ NNSquad ] "Tripwires" to detect Web page tampering, etc.
[ From IP ]
[ This technology was brought to my attention sometime back and is
indeed interesting. There are a number of complex related
issues, and it's perhaps unclear at this stage to what extent a
javascript-requiring detection system would be most applicable
vs., for example, end-to-end encryption (i.e. detection vs.
prevention of tampering, especially if ISPs assert that their
page modifications are completely legal).
-- Lauren Weinstein
NNSquad Moderator ]
------- Forwarded Message
From: David Farber <dave@farber.net>
To: "ip" <ip@v2.listbox.com>
Subject: [IP] Stanford -- Building a Safer Web: Web Tripwires and a New Browser
Date: Fri, 7 Mar 2008 09:24:13 -0500
Begin forwarded message:
From: allison@stanford.edu
Date: March 7, 2008 12:39:35 AM EST
To: dave@farber.net
Subject: [EE CS Colloq] Building a Safer Web: Web Tripwires and a New
Browser * 4:15PM, Wed March 12, 2008 in Gates B03
Reply-To: ee380@shasta.stanford.edu
Stanford EE Computer Systems Colloquium
4:15PM, Wednesday, March 12, 2008
HP Auditorium, Gates Computer Science Building B01
http://ee380.stanford.edu
Topic: Building a Safer Web: Web Tripwires and a New Browser
Architecture
Speaker: Charles Reis
University of Washington
About the talk:
Web content has shifted from simple documents to active programs,
but web protocols and browsers have not evolved adequately to
support them. As a result, safety problems in web sites and web
browsers now regularly make headlines, from browser exploits to
ISPs that modify web pages. In this talk, I will discuss my
research into improving the security and reliability of web
content and browsers.
For most of this talk, I will focus on one particular problem:
the ability for intermediaries to modify web content in-flight.
Our recent measurement study shows that many clients now receive
web pages that have been altered before reaching the browser. The
changes range from injected advertisements to popup blocking code
to malware, often affecting the user's privacy and security. Some
of these changes introduce bugs and even vulnerabilities into the
pages they modify. Most sites are unwilling to switch to SSL for
reasons of cost and performance, so I will show how web servers
can use "web tripwires" to detect in-flight page changes with
inexpensive JavaScript code.
After this, I will talk more broadly about my research on web
browser security, focusing on the deficiencies of today's web as
an application platform. Starting from my prior work on
BrowserShield, I will show how we need a safer architecture for
running programs within the browser. Like an operating system,
this new architecture will need effective mechanisms to define,
isolate, and enforce policies on these web programs.
Slides:
There is no downloadable version of the slides for this talk
available at this time.
About the speaker:
Charles Reis is a PhD student in the Department of Computer
Science & Engineering at the University of Washington, studying
with Steve Gribble and Hank Levy. His current research focuses on
improving the security and reliability of web content and web
browsers. In the past, he has also worked on models of wireless
interference with David Wetherall. Charles received a B.A. and an
M.S. in Computer Science from Rice University, where he worked
with Corky Cartwright and Peter Druschel. At Rice, Charles was
the second lead developer for DrJava, a widely used educational
programming environment.
ABOUT THE COLLOQUIUM:
See the Colloquium website, http://ee380.stanford.edu, for scheduled
speakers, FAQ, and additional information. Stanford and SCPD students
can enroll in EE380 for one unit of credit. Anyone is welcome to
attend;
talks are webcast live and archived for on-demand viewing over the web.
MAILING LIST INFORMATION:
This announcement is sent to multiple mailing lists. If you are signed
up on our private EE380 list you can remove yourself using the widget
at the upper left hand corner of the Colloquium web page. Other lists
have other management protocols.