 |
|
| presenters |
David Reid,
Ben Laurie
|
| history |
The change of version control software being used by
the ASF resulted in an opportunity to move away from providing shell
accounts on ASF hardware to a system of certificate based access
control. To support this a CA was required and after some investigation
none available met the requirements, so a project to write a CA that met
those requirements was started. The original scope was later expanded to
include managing code signing certificates to support work on Java
projects at the ASF. The resultant CA is entirely controlled using
signed emails to fully leverage the PGP web of trust and allow control
to be fully delegated to the appropiate people at all levels.
|
| demo |
People will be invited to submit requests for
certificates to the CA while the development and methodology of the CA
is explained.
|
| future plans |
The CA should be entering testing and further development
with the ASF during Dec/Jan 2004/2005 and the code will be submitted as
a project at the ASF as soon as it reaches a degree of stability.
|
|
| presenters |
Walter Landry
|
| history |
Walter Landry started working on arch three years ago, and
was, for a brief time, the lead developer. There was a difference of
opinion which lead to the ArX fork. Since then, the entire project
has been rewritten in C++. ArX's interface has been vastly improved
and is mostly internationalized. Performance is now reasonable even
for the largest projects. There is a python interface, and ArX has
been integrated with a patch queue manager to enable centralized,
CVS-style, development.
|
| demo |
The demo will start with basic workflow and continue into
some of the more advanced topics as time allows: branching and
merging, reverting development, remote cooperation, hooks, properties,
configurations, and working with large trees.
|
| future plans |
- Cryptographic signatures
- better integration with CVS
- a true three-way merge
- better integration with merge tools
- a web interface
- graph output for ancestry
- improved configuration mechanism
- localized messages
- an "annotate" functionality
|
|
| presenters |
Cat Okita
|
| history |
First formally presented as a concept paper at Defcon 11,
implemented in C, originally with
Peter Gutman's cryptlib - subsequently switched to openssl and sqlite.
|
| demo |
General overview of mechanisms/storage. Demonstrate application
referring to aura to
determine appropriate action to take based on stored reputation data.
Demonstrate change in reputation based on audience participation.
Demonstrate how different users have different
perceptions of reputation values depending on their biases and
connections.
|
| future plans |
Provide better hooks to allow easy tweaking of reputation values
(modify values, add new
categories) either programatically or via a gui, better integration
with other applications.
|
|
| presenters |
Leonard Richardson
|
| history |
The Ultra Gleeper was conceived in 2003 and implemented starting in
mid-2004. The basic idea for a webpage recommendation engine has been
around since at least 1995, but the rise of weblogs, RSS readers, and
web services like Technorati have brought down implementation effort
and the cost of running a personal installation.
|
| demo |
I will demonstrate a browser-based interface to the Ultra Gleeper,
as well as one that works in an Web-enabled RSS aggregator. I will
show how the Ultra Gleeper finds and rates webpages. I will explain
how it eliminates the normal drudgery of recommendation engine
calibration by piggybacking on things most CodeCon attendees do
already: blogging, reading weblogs, and posting to social bookmark
applications like del.icio.us. |
| future plans |
To create a greater variety of sources of links as more online
services start allowing integration.
To further optimize the rating algorithm to support more users on a
single installation.
To distinguish "news" type webpages, which rapidly grow stale,
from webpages which retain their interest over time.
|
|
| presenters |
Hal Roberts,
Molly Krause
|
| history |
Although networks and digital technologies can now be found in schools and universities around the world, their
potential to transform education has not yet been achieved. Current tools -- email, Web searches, digital syllabi
and message boards -- are useful, but they merely project the standalone classroom model online.
Using H2O, the best of what is in each classroom can be brought to every other: one teacher.s good idea for how to
teach a topic can be shared with and built upon by another; a curious searcher can be matched with others exploring
the same idea; an interesting discussion among classmates can become a powerful discussion among and across entire
classrooms, each approaching the subject from a distinct social perspective. H2O is determined to transform
education by developing tools that enable true interaction across classrooms and by providing an online home for
their use that connects educators and learners together.
|
| demo |
For the project demo, we will walk through the three main components of the H2O system: structured discussions,
syllabus management, and syllabus sharing. The structured discussion tool solves the problems that most teachers
encounter when trying to use online discussions in their courses: it improves the thoughtfulness of the discussion by
breaking it into discrete rounds with set deadlines, usually days if not weeks in the future; it encourages the
exchange of the widest number of viewpoints by assigning each response to at least one other student for further
response; and it breaks down the isolation of the single classroom by facilitating discussion between separate
classes. The syllabus management tool allows teachers to create syllabi in a structured format, instead of merely as
a single document. This structured data allows the system to suggest associations to the teacher . other readings
that she might include in the syllabus, other teachers who are teaching the same readings that she is, and other
courses that would make good discussion partners. Lastly, all of the syllabus data is fully searchable and
importable, allowing teachers to mine the syllabi that other teachers have created on the site for resources of use
in their classes.
|
| future plans |
Educators and students at all levels can and are benefiting from the cross-institution, cross-border and
cross-subject collaboration that H2O enables. Over 5,500 people in 107 counties have already experienced the value
of H2O by connecting via its network to share discussions and resources with one another. Over the next year, we
plan to broaden H2O.s impact by reaching out to new teachers and students around the world and by promoting academic
exchanges and topic-specific communities at additional levels and disciplines of education -- primary, secondary, and
university. We will also enhance the technical underpinnings of the H2O online portal by 1) restructuring the user
interface and user experience of the platform; 2) adding new features that strengthen the human interaction on the
system; and 3) building new layers of .smart. connections and associations to guide participants through H2O.s open
educational content. We look forward to soliciting feedback on both our technical changes and organizational plans
from participants and leaders of CodeCon 4.0.
|
|
| presenters |
Victor Grey, Fen Labalme
|
| history |
2idi has created the first i-broker to support global and community
registration and use of i-names. Based on open standards (OASIS XRI,
XDI and SAML) i-brokers enable single sign-on and contact gateways
that enable i-name holders to reduce unwanted email (SPAM). I-names
are free, when obtained from a parent community. (We are currently
charging $25 for global i-names that have a 50 year life span. But
community i-names - which can be used anywhere a global i-name can be
used - are generally free. The technology is 100% decentralized and
will play nice with p2p systems. The code is FOSS (dual BSD/GPL
licensed) and designed so one can easily move their identity from one
i-broker to another. Some of the code is already on SourceForge - the
rest will be on SourceForge as soon as we can get it there.
|
| demo |
During our talk we will:
- introduce the Identity Commons and the concept of chaordic organizations
- provide some background on the 2idi i-broker technology, its origins and goals
- compare and contrast i-brokers and i-names with other identity systems
like Passport, Liberty, PingID and Sxip.
- describe our open source business model, including
- why we need multiple implementations
- how developers can integrate i-names into their projects
- how i-names help organizations/communities/companies by lowering the cost of member acquisition
- increasing the quality of their member database
- discus sour current status and future plans
During our demo we will:
- allow everyone to register a community i-name
- show a list of i-names on the community site (opt-in)
- enable people to send each other contact messages with one-time anonymous
email replies
- show how i-name single sign on integrates with Purple Wiki and other sites
- demo any other new services that we have developed by then
|
| future plans |
- I-broker negotiated data sharing that permits automatic web service
registration
- Data sharing also facilitates automatic membership database updating
- Anonymous, unique to each person or organization email addresses
- A Reputation System that tracks the "trust value" of service providers
- User-controlled permission-based marketing
- Privacy-protected, user-controlled (even spontaneous) matching services
- Event registration and event-based social networking
- Enterprise applications such as
- resume/personnel services
- airline/car rental/lodging collaborations
- health care records management
- Inter-social networking services that wont lock in their membership
- Online gaming avatars
- most importantly, '''''getting all of you involved'''''
|
|
| presenters |
Steven Hazel,
Greg Hazel
|
| history |
Incoherence was inspired by the popular conceptualization of stereo
sound mixing, and developed from that basis into a real-time audio
analysis tool. It has had a fully functional, limited release in the
form of demonstrative visualization plugins for Winamp, Windows Media
Player, iTunes, and XMMS. |
| demo |
We'll explain the basics of stereo sound and mixing, and our idea for a
"stereo field spectrum analyzer." Then we'll demo Incoherence, starting
with simple examples of how the properties of stereo sound are mapped to
the display, and moving from there through explanations of what can be
seen in early stereo recordings, up to some exploration of more modern
recordings. |
| future plans |
Future plans include a commercial release, integration with multitrack
Digital Audio Workstations, and a lot of very exciting features we don't
want to talk about just yet. |
|
| presenters |
Kevin Burton
|
| history |
FeedParser was originally the parser API behind NewsMonster and
currently
drives Rojo which indexes more than 1.1M feeds in a production ready
environment. |
| demo |
We will discuss the design criteria for FeedParser and provide code
samples for
getting up to speed fast. We will also discuss the requirements for
following
Postel's Law and building a flexible parser which is able to parse most
real-world feeds even when in a somewhat broken state.
|
|
| presenters |
Eric Rodenbeck, Michal Migurski, Tomas Apodaca |
| history |
Photos posted to flickr.com are often tagged with information that can be used to make educated guesses about their locations in the world. Mappr references this data, which is provided by flickr users, against a database of US locations, to place their images on a map.
There's a certain amount of fuzziness built into mappr. Not every photo is tagged in such a way as to allow us to accurately determine exactly where it is. We make educated guesses, based on the information available in the tags.
|
| demo |
A good example of a "fuzzy" photo would be one tagged with "ohio," but with no other location-specific tag. This photo is probably in the state of Ohio. But as it turns out, there is also an Ohio County in Kentucky, and a city named Ohio in Bureau County, Illinois. Without any other tags, we can't say one way or the other which of these is correct. So we make a best guess, based on the largest area covered by that name. In this case, the state of Ohio covers the biggest area - so we drop the photo in the center of Ohio.
However - if a photo has both "ohio" and "illinois" tags, then we can be pretty sure that it's in the city of Ohio, in the state of Illinois. And if a photo has "ohio" AND "cleveland" in its tags, then we can be amost certain that it's in the city of Cleveland, in Ohio.
It's an inexact science, to be sure - but it works, and it will get better. Our hope is that the use of mappr will encourage flickr users to provide more location-specific information with their photos, starting with state and city names. The heuristics for dealing with "Concrete, Washington" or "Duck, West Virgina" are challenging, but the project's status as a collaborative enterprise relying on a substantial base of flickr users should provide interesting opportunities for interaction and learning.
|
| future plans |
We are currently building tools to allow flickr users to use mappr to add geo-specific information to their own photos, without needing to know or have access to latitude and longitude data. |
|
| presenters |
Nikita Borisov
Ian Goldberg |
| history |
Off-the-Record (OTR) Messaging was designed because existing IM
protocols (even the ones claiming to be "secure") didn't have all of
the properties necessary to provide a truly private conversation:
encryption, authentication, deniability, and perfect forward
secrecy.
For example, gaim-encryption digitally signs every message, making
deniability impossible, while SecureIM makes no effort at all to
validate the origin of the messages.
OTR Messaging is also designed to work over _existing_ IM networks.
There's no infrastructure that needs to be maintained; it's entirely
peer-to-peer. This also has the benefit of making it work in more
restrictive environments, such as firewalled or corporate setups,
where perhaps a proprietary IM protocol is used. |
| demo |
We will demonstrate the OTR plugin for gaim, and talk about the
cryptography, security, and UI components that yield the necessary
privacy properties:
-
Encryption
-
No one else can read your instant messages.
-
Authentication
-
You are assured the correspondent is who you think it is.
-
Deniability
-
The messages you send do *not* have digital signatures that
are checkable by a third party. Anyone can forge messages
after a conversation to make them look like they came from
you; in fact, we provide a toolkit for such forgery.
However, *during* a conversation, such forgeries are
impossible and your correspondent is assured the messages he
sees are authentic and unmodified.
-
Perfect forward secrecy
-
If you lose control of your private keys, no previous
conversation is compromised.
We will contrast the OTR protocol to other IM encryption methods,
such as gaim-encryption, SecureIM, and silc. |
| future plans |
In the future, we will use the OTR Messaging Library to make OTR
plugins for other IM clients, such as Trillian, or iChat. If you
have experience writing such plugins, we could use some help in
this area! :-)
|
|
| presenters |
Dan Kaminsky
|
| history |
The first version of OzymanDNS was presented at Defcon, where
I demonstrated SSH over DNS (and with that, general purpose VPN'ing
using the dynamic forwarding discussed at Codecon in 2003) and live
streaming radio over DNS. I also discussed in some depth the potential
for bypassing firewalls using the proxying components of the protocol.
|
| demo |
"DNS is a routing, caching, globally deployed overlay network on
top of the Internet. Last year's Black Ops of DNS discussed rudimentary
mechanisms for manipulating that network to achieve low bandwidth but
insidiously firewall-penetrating connectivity anywhere and everywhere.
This year, we expand this research to show how extensive, bandwidth
amplifying routes can be deployed across the two million DNS servers out
there -- and demonstrate an aggressively loss tolerant protocol that can
extract high speed connectivity from what's usually considered to be the
lowest capacity protocol on the Internet." In other words, I'm trying
for Video over DNS. I'll also probably demonstrate in greater depth my
DNS-based solution to RSS overload.
|
| future plans |
Once the DNS infrastructure is ready for demo, backport
it to general purpose UDP, document the spec, and turn it into a NAT2NAT
framework. The lack of a really good solution for this has been a thorn
in all of our sides, and the TCP stuntage from years back turned out not
to actually be deployable like this would be.
|
|
| presenters |
Alon Salant |
| history |
Photospace has its origins in yet another homegrown digital photo
management tool that started bursting at the seams with just too many
photographs.
The goal of the project is to make a large set of digital media as
useful as possible while minimizing the effort required to add media and
meaning to the system.
Core principals:
- Use implicit meta data as much as possible with a focus on time and place
- Provide fast, powerful searching for a large media archive
- Provide an open set of services to enable easy integration with other applications
- Use filesystem-based organization and management of photo/media files
The result:
- A web application for searching, viewing, managing digital media
- Lucene-backed search engine with custom support for geospatial queries
- Hooks in to searching and serving media through SOAP-based web services, RSS, RESTful RDF, Flash Remoting
- Media file management through WebDAV, local filesystem, LAN fileshares, ftp/scp, or web application
Photospace has been inspired by Thingster, Flickr, Gmail, PhotoRDF and
discussion on the geowanking mailing list among others. |
| demo |
Photospace addresses three current topics in software development.
First is the interaction between software and real objects in time and
space. Geocoding and mapping are core elements of this topic. Second is
the semantic web and interoperating applications. Web services and RDF
are core elements of this topic. Third is finding and using implicit
meta data in large systems.
This presentation is of the Photospace software project in the context
of these topics. Examples include using Photospace-managed photography
in external applications and writing JSP, PHP, .Net or Flash clients to
Photospace services.
Presentation structure:
- Geocoding digital photography, tools and techniques
- RDF/RSS and the semantic web
- Implicit meta data in digital photography
- The core Photospace searching service
- Mapping examples and approaches to mapping
Example: Spatial search results on a Terraserver image in RDFMapper.
A search for all media within 3km of 38ｰN,122.5ｰW, China Camp State
Park, CA.
The RSS view of these search results.
These search results plotted on a Terraserver aerial photograph of China
Camp using MapBureau's RDFMapper service.
These search results plotted on a TIGER Map Server map.
|
| future plans |
- Mobile phone photography and photoblogging
- Include view counts as implicit meta data
- GPS/GPX track log integration
- Improved mapping
- Integration with Thingster, Flickr, Ofoto
- Support for audio and video
- Development and support of applications that use Photospace services
|
|
| presenters |
Hal Finney
|
| history |
RPOW was created in July, 2004, out of an effort to demonstrate
the utility of open source software combined with features of
"trusted computing" systems. The RPOW token signer runs on an
IBM 4758 coprocessor, which provides cryptographically signed
attestations (based on an IBM root key) allowing third parties
to verify what software is running on the system. This allows
real-time remote auditing of the RPOW server to confirm that it
has no back doors and that the only way to create an RPOW token
is by performing a computationally expensive calculation.
RPOW can be thought of as ecash "play money" bought and paid for
by hashcash. Although it has no monetary value it is verifiably
expensive to create because of the costliness of the hashcash.
And like ecash, it can be exchanged among users.
|
| demo |
I will first show the basic ability to create RPOW tokens from
hashcash, to pass them among users and to allow the users to
exchange the received tokens for fresh ones. Software will be
available to the audience in source code form (C language) to
enable them to connect directly to the RPOW server, generate
tokens and exchange them among themselves. This part works
already.
I will also show a sample application of the RPOW client library,
a patch to a P2P program to let people pay for file downloads
with RPOW tokens. Users who make large amounts of data available
would be rewarded by accumulating RPOW tokens which they could
then use for their own downloads. Beginners could enter the
system by generating hashcash collisions to create tokens for
initial downloads. Leechers would be limited to this relatively
slow means, encouraging people to participate more actively.
This produces a decentralized form of the "quota" used on
centralized file servers. This extension is currently under
development but should be done by the end of the year. |
|
| presenters |
Meredith L. Patterson |
| history |
"We don't sell software -- we sell oligonucleotides," is the ethic
behind SciTools. The project began as a small, free set of web
interfaces that enabled molecular biologists and geneticists to solve
basic genetic design problems. Over time, it's grown to incorporate ever
more complicated features -- including BLAST searches, RNAi and
antisense RNA design, and an interface to the EnsEMBL genomic database
-- based on researchers' needs and questions. And it's still free!
There exist other packages that provide similar functionality, but which
typically cost several hundred or thousand dollars per year, per
license. Throughout the development of SciTools, Integrated DNA
Technologies has focused on using the suite to add value to the physical
products we sell, rather than viewing software as a product in itself. |
| demo |
We will walk through a real-world molecular genetics problem --
designing a knockdown sequence for BRCA-1, a gene commonly associated
with breast cancer. The example will begin with cloning a gene, which
requires the design of PCR primers. It will then move to designing
inhibitory sequences that will decrease gene expression, and finally,
we'll design a probe to detect the level of gene expression after the
fact. At each step, we'll explain the state of the problem from a
biology perspective, then describe the computations underlying the task
at hand and demonstrate the design and analysis in real time.
|
| future plans |
SciTools' development is largely guided by its user base. As
researchers come to us with design challenges, we come up with solutions
in software, then provide them to the rest of the research community, on
the grounds that if one researcher has a problem, others will eventually
run into the same situation.
|
|
| presenters |
Mark Lentczner, Jim Kingdon |
| history |
The early ideas for Wheat were born when Mark wanted to build a
simple automated photo album web site in Perl. This led to a
templating system and ideas about objects that live on the web.
Later, the experience of writing a 12,000 line PHP application,
while possibly driving Mark batty, forced him to design some new
ways to integrate programming and the web. He started a Wiki where
a dozen or so people contributed, and then he started coding.
November 2003 saw the first prototype with a live, persistent object
system serving pages to the web. The next twelve months saw the
implementation of the full templating and rendering engines, the
language compiler and virtual machine, and implementation of a blog
written entirely in Wheat script.
|
| demo |
The first part will focus on how a typical Wheat application is put
together. We'll show the scripts and the templates, and demo the
programming process. We'll also discuss the language features of
Wheat that make it such a good fit for the web: Objects with URIs,
Message passing as REST request, Error handling w/o exceptions, and
XML integration.
The second part will dive under the hood and show how Wheat itself
is put together. We'll discuss and show the novel aspects of how
the object system and virtual machine are written and organized
including object system media and mount points, the blurring of C++
and Wheat language, and the very thin virtual machine. We'll also
discuss implementation techniques that have made the project go
smoothly: heavy use of C++ features, integrated test framework,
extreme programming methodology, and incorporation of other open
source software.
Demonstrations and slides will all be shown off a running Wheat
server, which will be accessible to the attendees.
|
| future plans |
This December we'll be implementing the next major revision of the
language which will include syntax improvements, tighter integration
with XML, and revised message semantics. Then we'll embark on
building the Wheat development environment in Wheat, a sort of Wiki
for coding web applications live. We expect to be showing both of
these in early form by CodeCon 2005.
After that, we'll be preparing for an official 1.0 release, around
Summer 2005.
|
|
|
