Chowdr

Anonymity on an Antisocial Platform

Charles Jin, Mike Wu
May 8, 2014
Introduction
Anonymity has been a part of the backbone of the internet since its inception. By
its very nature, the internet allows only interactions via proxy, generally behind
identiable pseudonyms. The appeal of being able to create and live out multiple
identities online was and always will be an extremely important part of the social
fabric of the internet.
With the recent rise in public awareness on the extent of surveillance on the in-
ternet, this trend is only growing stronger. In particular, several applications employ
anonymity to provide psuedo-anonymous social networks. For all intents and pur-
poses, these applications operate nearly identically to Facebook, with the exception
that all posts and comments are anonymous. With this layer of anonymity built in,
these applications create a safe environment to reveal things that would normally
be too embarrassing or private to put on a social network where posts are tied to
real-life identities. Unfortunately, these applications oftentimes exploit anonymity
to divorce the user of any responsibility of their actions without further nuancing
their use of anonymity. While this generally leads to a more open environment for
communication, it also has many negative consequences, for example, allowing users
to reveal sensitive information about others without fear of repercussions on their
own lives.
This paper describes Chowdr, an anonymous application built on an antiso-
cial framework. We believe this model is much closer to a positive application of
anonymity to social circles to solve the problem of privacy in online social interac-
tions.
1
Motivation
Chowdr is composed of two main features: anonymity plus an antisocial framework.
The Case For Anonymity
The situations in life in which an anonymous forum might be helpful are many. In
fact, nearly all internet forums are anonymous in that they require only a working
email address for sign-up. However, identity is not entirely secure since people gen-
erally use similar usernames across multiple sites, and combining the information
available across multiple sites is oftentimes enough to determine a persons identity.
Thus, the primary focus of these internet forums is less on absolute anonymity, and
more on allowing people to adopt alternate personas in a community built for a
specic purpose (e.g. the many hobbyist forums that exist).
What we wanted was to build a truly anonymous social network, with the sole
purpose of allowing people to reveal things they otherwise would not be able to in a
psuedo-anonymous environment. The needs of this application go beyond the usual
anonymity of internet forums, where creating a new username is enough. Part of the
anonymity will be derived from the features of the application and the underlying
architecture. It is important to note that we still allow users to pick their own
usernames, so it is up to the users to create a truly untraceable identity; however,
the hope is that if the users sign up with anonymity as a focus, usernames will be
less likely to reveal identity.
There are many potential use cases for such a system of true anonymity. For ex-
ample, imagine someone is having issues at work, and needs to seek advice. Whether
he is thinking of quitting to start a new career, or just needs a place to vent, without
anonymity he is unable to safely divulge his true feelings. Apart from the career
implications if the boss were to nd out, it is also entirely possible he doesnt want
his close family or friends to know of his problems at work either.
In another case, perhaps someone wants to know how help a signicant other
with an eating disorder. Seeking out preliminary information from someone who has
similar rst-hand before confronting her boyfriend or seeking help from a trained
physician is quite reasonable. However, in this case, anonymity protects two parties.
While revealing that information does not harm her directly, she still has an incentive
to keep her questions a secret, lest her boyfriends reputation is hurt. In addition,
potential commenters might keep quite to protect their own identities, creating a
sort of response bias for any advice. With a truly anonymous system in place, the
advice is more likely to be "average" and thus be applicable to the original posters
2
situation.
Notice that in both potential use cases, there is also a very strong desire to keep
the information not only anonymous, but also secret from anyone who might be
able to guess an identity as well. In other words, certain use cases necessitate an
anti-social association between members who can interact with a users content. In
particular, these use cases revolve around a desire to protect ones own identity (or
a close friend) from an association with the post due to a direct association to the
contents of the post.
The Case For an Antisocial Framework
There is another kind of use case that also requires anonymity, and that is when
the desire to protect ones own identity is derived not from direct association to the
contents of the post; rather, the post is about some other gure, and anonymity is a
shield from retaliation. We considered these use cases to be malicious; for example,
cheating lovers have been outed on similar applications before, and cyber-bullying
has also been a issue commonly cited.
The main problem with these sorts of secrets is they arent directly related to the
poster. Thus, the motivation behind such posts isnt a genuine desire to seek advice
in a safe environment, but rather, a perverse incentive to watch, rather in real life or
in the ensuing comments, the aftermath of revealing such a secret.
Building anonymity on top of an antisocial network solves these issues. By only
allowing a users content to be viewable to others with at least 2 degrees of separation
to the user, posts about others will most likely no longer be relevant to outsiders.
This disincentives malicious posts for two reasons. First, no one will interact with
the post if it isnt relevant to them in some way. It is unlikely you will want to post
anything about someone whos not directly related to you socially; likewise, others
are unlikely to want to interact with content that is outside of their direct social reach
as well. Thus, with 2 degrees of separation, the incentive to create malicious content
is limited due because the content wont be able to spread without an interactions.
Second, because the spread is nonexistent, there wont be any repercussions in
real life to speak of. Thus, those hoping to use the application as a eector of change
in real life will be forced to seek other outlets. Note that the design of the application
is such that even if a user tries to create malicious content about others, the content
will not spread.
This turns the focus of the application inward. If users have no reason to create
content about others, the only incentive left for a user is create content about himself,
whether just to rant, to seek similar-minded people, or to seek advice. Thus, the
3
application becomes a safe zone for users to seek advice, rather than a no-holds-
barred environment for divulging secrets of any kind.
Being antisocial also puts the application in a unique position where connections
can be built not on the common social metrics of association or mutual friends,
but rather on similar interests and experiences. This sort of connection is much
more tting for a social network that is based entirely on anonymity - otherwise,
the anonymity is only a thin wrapper around the traditional Facebook or Myspace
model, facilitation a feature akin to anonymous chatrooms amongst friends. While
such applications can be fun and have their use cases, to build a social network truly
centered on anonymity requires a new denition of what makes two users likely to
connect.
Posts can still go viral, however, the spread will be dependent not on social
connections but actual content - a common experience or problem that many people
have experienced is more likely to gather the critical mass of interactions. The
antisocial framework of the initial post is still integral to the anonymous nature of
the network, since by the time the post goes viral, it is no longer about who created
the post, and who shared the post, but rather whether a user feels a connection.
The Case For Chowdr
Chowdr is our implementation of an anonymous network built on an antisocial frame-
work. Users sign up for Chowdr with a custom username, and then connect with their
Facebook to provide their friend list. Using this information, users in the database
are limited to seeing content from people with whom they have no mutual friends.
Users can create their own posts, as well as see a feed of posts from other users,
which they can either comment on or favorite. Future iterations will include support
for other social networks to bolster the antisocial framework, like LinkedIn. Posts
will also be ranked for potential to go viral, so that posts with more interactions will
show up in the feeds of more users. Using this model, we hope to retain the benets
of traditional social network like viral content and creating new connections among
similar users, while still providing a safe and truly anonymous environment to seek
and give support.
Related Work
There are several classes of similar applications that currently exist. In broad cat-
egories, they are: pseudo-anonymous networks like Secret and Whisper, traditional
4
social networks like Facebook, and anonymous safe spaces in the real world like
Alcoholics Anonymous.
Pseudo-anonymous Networks
There are several examples of currently existing psuedo-anonymous networks. The
two most popular are Secret and Whisper. Both operate similarly. Users sign in
via Facebook. Posts are then anonymous, and content is propagated using existing
social connections. However, as outlined in the previous section The Case For an
Antisocial Framework, the drawback for such a system is that such a system is just
as suitable for content about the user as well as the users connections, meaning
malicious posts about others are appealing.
Such systems have an inherent benet over Chowdr however, and that is that the
viral spread of content can use pre-existing connections. This means that users are
more likely to interact with content about people within their social networks, rather
than content about strangers. Because Chowdr is anti-social, however, in order to
help the spread of content, Chowdr employs a dierent model to manage the spread
of viral content.
Chowdr overcomes the problem of non-social viral content by prioritizing posts
based on pure interactions, with the theory that those posts will be consist of com-
mon experiences that are more likely to be applicable to a larger group of people.
In addition, Chowdr can be expanded to automatically tag posts with information
about the posters demographic, as well as pull keywords from posts to create a tar-
get prole for the post, in order to better target the posts audience. For example,
it is very plausible that males between the ages of 13 and 18 currently living in
Dallas are more likely to be experiencing similar issues, even if they have no mutual
friends. Thus, by targeting demographics instead of social connections, Chowdr can
still provide a relevant audience for a post without using preexisting social networks,
thus overcoming the advantage of anonymous social networks.
Social Networks
Traditional social networks like Facebook can also be considered competitors. It
would be unreasonable to expect Chowdr to replace Facebook, especially since the
data for social networks is pulled directly from preexisting networks. Chowdr is built
for an extremely specic purpose: to provide a safe haven for sensitive inquiries.
While some people do use Facebook sometimes to seek advice, traditional social
networks do not provide the protection of anonymity needed for certain kinds of
5
questions. And furthermore, even if Facebook were to implement such a system,
questions of privacy would probably dissuade users from actually using Facebook for
that purpose, since Facebook stores all the information for their own purposes.
Anonymous Support Groups
Chowdr is an online solution that seeks to emulate real-world anonymous support
groups like Alcoholics Anonymous. Thus, it is worth mentioning the benets of a
fully online system.
First, while Alcoholics Anonymous purports to be anonymous, in reality, the
anonymity is based on the goodwill of the participants. There is no guarantee that
one of the people in the group will not go home and tell his family who else is in
his group, even though he is sworn to secrecy. Chowdr is entirely anonymous - the
users identity is as safe as long as her username and posts do not reveal too much
personal information.
Second, an online system allows users to connect with people far away from the
user, meaning that less common problems will still be able to generate support. With
support groups, a user needs to depend on a certain concentration of preexisting
people with the same problem willing to come out. On Chowdr, so long as someone
has the same problem, it is likely to encourage interactions.
Third, Chowdr allows for questions without going to the level of an anonymous
support group. If someone were to truly have a drinking problem, Chowdr might be
the rst step into convincing him to join Alcoholics Anonymous. However, Chowdr
will never be able to actually supplant the support of a group of people. In addition,
a teenager with questions about puberty would denitely not be seeking support from
an anonymous group of people in person, both for the reason that it is unnecessary
due to the nature of the problem, as well as teenagers are inherently shy about such
problems and are unlikely to go seek help on such a small topic.
System Architecture
The following section describes an intellectually graspable abstraction of the Chowdr
system. It attempts to look at the fundamental organization of its parts as well as
explain several concepts important to the underlying language that Chowdr is built
on top of: Rails:
6
Rails
Ruby on Rails, or just Rails for short, is a web development framework which runs
on Ruby. Rails is full-stack, and encompasses solutions communication with a web
server, rendering pages, and gathering/storing information in a database. Rails fol-
lows several common software engineering practices, in particular the Active Record
pattern for storing data and the MVC pattern for implementing user interfaces. Rails
also ships with a custom web server called WEBrick.
Active Record
Active Record is a an architectural pattern that essentially abstracts database tables
into classes. Each object instance is then tied to a particular tuple, and updat-
ing the object will update the database. A wrapper class implements the accessor
methods for CRUD, so the underlying data is never directly touched. For example,
to nd a particular user by the userID, the rails method would include some line
User.nd_by(user_id: 3).
Model-view-controller
Rails applications follow the Model-view-controller pattern for implementing the user
interface. The MVC architecture separates domain logic i.e. data models from
presentation logic in the GUI. A typical Rails application uses the controller to
interact with browser requests and talk to the model, which pulls and pushes to the
database. After receiving updated tuple information, the controller updates the view.
Rails uses the ActiveRecord library to implement models, the ActionView library to
render views using embedded Ruby les, and the ActionController library which is
a data broker between the database interface and the presentation engine.
Figure 1: Setup of the Model-View-Controller architecture for Chowdr. The ar-
rows represent directions of communication.
More specically, models track changes in state in the database and appropri-
ately noties controllers to adapt. Views generate the output representation and a
controller sits between the view and the model, is analogous to a command center
to receiving model instructions, processing, and relaying instructions to view. This
form of software architecture is popular with web applications because it easily di-
vides application responsibility between the client and the server, partitioning tasks
7
to each of them. Chowdr partitions most of the processing onto the server, which
initially was a local computer, later moved to Heroku.
Figure 2: Typical client server interaction. This example features a similar pro-
cess to Chowdrs authentication model in terms of creating token and a callback.
A good example of the MVC structure can be demonstrated by a user adding
a new post. It starts with the feed view that displays a form for the user to ll
out. When the submit button is pushed, the corresponding controller performs error
checking on the post submission and using a create function, adds the new post to
the model which sends it to the database for a commit. If the commit is successful,
the database returns the news to the model which tells controller which then renders
the updated view to include the new post on all other relevant users feeds and in
the current users prole.
Server Setup
Chowdr was deployed both locally and to a cloud platform. Locally, the application
is run on Rails prepackaged server WEBrick with the computer as the server. The
application can then be tested from a local host, allowing us to interact with Chowdr
from the client point of view.
Chowdr is also deployed to Heroku to allow other users to access it. A Gemle
species which parts of Railss extensive library is used and the program is rebuilt on
the heroku server according to the execution command of a Procle, which for Rails
is just rails server. Heroku is an open platform that lets developers build, run and
scale applications in a robust fashion without hooks. It enforces a strict separation
of code and conguration with dependencies explicitly declared. Applications on
Heroku are thus independent and very lightweight. Scaling on Heroku is as easy as
acquiring additional dynos, which are virtual Linux environments.
REST Architecture - Representational State Transfer
Rails encourages developers to employ RESTful routes in applications. These routes
dene the URLs in which the application can perform actions (see cong/routes.rb for
examples using the resources tag, which denes a group of similar objects). REST
requests include HTTP verbs like POST, GET, PUT, and DELETE to connect
a controller action with the request, in addition to functions for rendering forms,
8
mainly used for sign-in and account creation. For example, consider the wrapped
resourcing below. This REST route provides a way to see all of the comments
belonging to the current users post, and it produces the single resource routes:
/posts, /posts/new, /posts/edit, and the multiple resource routes: /posts/comments,
/posts/comments/new, /posts/comments/:id, /posts/comments/:id/edit, /posts/comments/:id/destroy.
Figure 3: A nested resource. If the current_user is defined, this will return all
comments to the current users post.
Additional Notes
Rails also makes use of CRUD operations. A resource created can be given create,
read, update and destroy functionalities. The base controller ApplicationController
has dened methods that Chowdr edits to perform the CRUD operations.
Implementation
The following section describes the implementation for Chowdr:
Software Stack
Chowdr is built in Ruby on Rails, including the familiar HTML, CSS, and javascript.
We used a CSS extension called Sass to enable basic logic in the stylesheets, and
Jquery libraries provided prepackaged javascript functionality. The local production
database is in postgresql and the local development database began in sqlite3, but
was later moved to postrgresql with taps gem to match production. All data on
Heroku is stored in additional separate postgresql databases. External APIs include
S3/Paperclip, Facebook-API, OAuth2, and bootstrap.
Database Design:
Most of the explanations will be done using the model-view-controller setup in Rails.
All implementations follow a partial or full CRUD functionality and should be consid-
ered RESTful resources. Most relations included an index on top on the relation_id
using a B tree - intended for more ecient lookup. Additional specics can be found
in db/schema.rb le.
9
Users: All individuals who sign-up on Chowdr are added to our users relation, which
denes the individual by name, email, creation and update timestamps, a protected
password, a token for remembering previous sign-ins, an admin tag, a unique id (for
Facebook), a location, a description, cover photo inputs, and avatar photo inputs.
Cover and avatar photos are dened by le names, le sizes, update timestamps and
content types, all of which are elds required by Amazons S3.
The admin tag is a binary digit that adds functionality for certain users to
have additional read and write permissions over regular users.
The sign-in workow creates a new session instance that wraps over a user
and is able to save previous sessions instances (creates a token to remember a
previous user sign-in).
Location, description, and all photos are optional table entries. Name and
email have integrity constraints on uniqueness and format using regex. Photos
are also validated by size and le type.
The password is stored in the database with a irreversible hashing function.
During sign-in, submitted passwords are hashed and the hash index is com-
pared to the value stored in the database. If matching, then authentication is
initialized and a session is created. This is good because we do not actually
store passwords ourselves. Through data leaking or data failure, no important
information is lost. Bcrypt is used as the hashing medium, which adds salts
(additional random input in hashing) and changes over time to protect against
brute force cracking.
Each user has many posts (users are voters in terms of number of likes func-
tionality), authorizations, and Facebook_connections (our relation of users
friends and friend of friends).
Each user also has a feed: an array of posts that should show up when users
access their newsfeed. This array is edited to exclude friends in the viewables
instance for a user.
Posts: Any time a user submits a new post to our feed, it is added to our posts
database. This relation includes a unique post_id, a foreign key to its posters
user_id, a content string, a number of votes, and creation and update timestamps.
Each post has the ability to be voted on, which stores an integer that counts
user likes. These likes are tied to user_id, meaning that an individual can
only vote on a post once.
10
Includes integrity constraints on content maximum length and a matching/existing
user_id.
Comments: Each post has a option to add comments from users to it. It includes
a foreign key of post_id, a string for body of the comment, and the additional
timestamps.
Comments have integrity constraints on body length.
Optional design is to include a foreign key to users directly.
The front end for the comment and like interface was written in javascript
(JQuery): an additional div pop-ups upon click and updates the page with an
additional like or an additional comment upon submission.
Sessions (not a model): This is a semi-permanent interaction (given remember-me
option) between a client computer via web browser and the rails server. Common
session behaviors included are forgetting sessions when closed browser, persistent
sessions, and memory of previous sessions.
Sign-in creates a session and sign-out will destroy a session.
Persistent sessions are stored in the User model. A cookie (small text on h
users browser) is used for authentication.
The remember-me option generates a unique and secure token for each user
and stores it as a permanent cookie with no expiration on browser closing.
A useful function included in sessions is the variable current_user, which is
dened by the user signed in at the current state.
Authorization: After authentication, the authorizations model is used to maintain
the 3rd-party social connections. Currently, the model is limited to pulling connec-
tions from Facebook. The model also includes methods that allow us to check what
users can and cannot do, i.e. only users that have at least one authorization can see
other peoples posts. The relation contains a user_id, the Facebook unique id, an
expiration date, timestamps, and a provider string.
Makes use of a before lter to ensure that certain methods (e.g. constraint
checks like correct_user and signed_in_user) before actions are run.
11
Ensures forwarding to proper warnings and redirect pages
Facebook_Connections The Facebook connections model stores the 1st degree con-
nections of users obtained from Facebook. Friends are stored using their Facebook
Unique ID. Every time a user signs in, the users friends from Facebook are grabbed
and checked for new friends. If there are new friends, the table is updated, and
methods in the following model Viewables are called.
Viewable: The viewable model is a bit of a misnomer in that it maintains the logic
for all second-degree connections, which are actually unviewable users. The model
includes methods to generate a set of users who the current user has permissions to
see. Contains a user_id, a friend_id, and respective timestamps.
For each user, upon rst sign-in, a table is created to store unique ids of all
their friends on Facebook and friends of each of those friends.
If a user has new friends, the Facebook UID of each friends is checked against
the Authorizations model to see if the friend has a Chowdr account. If the friend
does have a Chowdr account, Viewables is updated with two new relations -
the user cant see the friends content, and neither can the friend see the users
content.
The feed within the user model is then modied to be all posts by users with a
unique id not found in the viewables relation, ensuring degrees of anonymity.
Example of User-Database Interaction:
If the user has an account already, completing Chowdrs sign-in form prompts the
start of a new session, or if the remember_me option was enabled, a previous persis-
tent session will be reloaded. If the user does not have an account, completion of the
sign-up form will start and possibly store a new session. From there, no functional-
ity is enabled (the user cannot view or submit posts/commits/likes) until Facebook
authentication is provided - it might be possible to chain the two factor authentica-
tion together for better UX. After granting Facebook access permissions to Chowdr,
the user will be redirected to their prole page (which shows all of his/her previous
posts), and will be able to customize their home page. The main functionality lies
on the feed page, where users can read all posts allowed by their viewables instance.
Posts are paginated 30 a page and no relevant posts are deleted, only pushed to later
pages. Users are then able to comment/like under an anonymous ID and are able
12
to post with their anonymous nickname. Users can interact with admin via contact
page. Additionally, upon sign-out, the session is ended or stored in cookies for later
re-entry.
Additional Notes:
Notice that if a user unfriends another one Facebook, by the current model,
the viewables table is not updated to incorporate this new information. The
viewable relation compiles a table of friends using social media that can only
grow. This is by design since unfriending someone on social media is not
congruent to unknowing them. True anonymity has to take into account
these individuals as well.
Git and Heroku were widely used in Chowdrs creation, the former for ver-
sion control and backup in case of conicting updates, and the latter for easy
deployment to a live server.
Front End: The front end of Chowdr makes use of bootstrap for some pre-made
css classes. The rest was compiled by the authors in solely html and css. The
bowl logo animation was constructed by hand from pure css and svg - using
opacity to imitation a fading eect and the bowl created from a css border.
Credits of some icons used in Chowdr go to Font Awesome and Glyphicon.
Experiences and Lessons Learned
As with most group programming assignments, modularity was important in dividing
Chowdr into concrete blocks that could be programmed separately. Given these
divisions, it was easy to later integrate them together into a nal solution. The
divisions to Chowdr composed of: front-end, logo and icon design, standard back-end
setup, setting up the 2nd degree connection network, and testing. By modularizing
the codebase, it was easier to integrate new features, test separate features, and
update each other on new progress.
It would have beneted Chowdr to have been coded under test-driven devel-
opment (TDD). Rspec and Capybara were incorporated but only after the after a
majority of the application was developed. Most of tests written checked syntax of
the html, new divs, database commits, table lengths, etc. Only after using TDD
did we realize the benet - it allowed new features to be added without having to
consider possible errors being introduced. However, because TDD requires a large
13
amount of time, Chowdr initially did without it. Its rather dicult to maintain
TDD in a fast building environment because a majority of the tests seem rather
redundant. For example, many of the examples on the rails tutorial were testing for
non-essentially (and almost irrelevant) functionality like checking if a browser tabs
description header is present or if a link is present. While these are relevant in op-
timal conditions, we learned about the feasibility of TDD given limited amounts of
time. Purely writing tests before any functional code is very time consumed; TDD
should instead focus on parallel test and code writing to optimize productivity and
healthy functionality. And when limited in time, we learned to prioritize the tests
written to large (and more easily broken parts of Chowdr, i.e. ensuring that ses-
sion creation and deletion properly edit the users relation and that no tuple in the
viewables relation should be in the table of users of posts in the feed.
Results and Limitations
One of the more important tests was looking at the scalability of Chowdr. This was
done twice, before and after the implementation of Facebooks API because the API
limits how many test users could be created.
Before incorporation of any APIs, faker and factory_girl gems were used to ll
the database with users. The gems made 10,000 users, each with 100 posts derived
from random latin phrases and each having a prole picture and a cover picture and
customized descriptive phrases and nicknames, and because no degrees of separation
could be considered here, the feed was at a maximum lengthFacebook, meaning that
all posts were viewable to all users. No errors were found with Rspec tests passing.
All functionality with liking, commenting and posting were preserved. After the in-
corporation of the Facebook API, factory_girl could not be used since even if our
database were to be populated manually, no automatically generated user would be
able to authenticate Facebook (no valid individual Facebook accounts).
Figure 4: Index of all users (1,000 generated with Factory Girl in right example.
Facebook itself did oer the manual creation of test-users, but this could not
feasibly create 10,000 accounts. We instead generated two test user accounts as
proof-of-concept for Chowdrs anonymity implementation. It was shown that given
Charles previously authenticating Chowdr on Facebook, his Chowdr post was not
viewable on Mikes Chowdr feed but present on the feeds of our two test-users.
Although this functionality theoretically should be preserved under large amounts
14
of users in the database, there will likely be a large decrease in performance speed
given that the pulling of Facebook friends and the discovery of common friends with
all other relevant users are not asynchronous.
Contribution Breakdown
Both authors contributed the writing of this paper and to the creation and ideation
of Chowdr. Initial ideas included a twitter-like social media feed that only shows
posts within a certain geographical location. Later developments from research and
personal interest added anonymity to create Chowdr.
In terms of programming, the application was broken down into frontend, back-
end and deployment, all of which involved both authors. Mike set up the landing
pages with the basic html and css, and Charles added additional styling features, i.e.
the Chowdr logo and typography. Most of informational paragraphs on the product
site were added by Charles. Regarding the backend, Mike worked on the creating the
users, posts, comments, and upvote tables and ensuring proper integrity constraints
between them, in addition to setting up images to be automatically loaded in a
external amazon S3 bucket. Charles completed workow for getting a token from
Facebook for usage with Facebooks Graph API. He also developed all the function-
ality to only show posts from users that are at least two degrees of separation from
the current user, including storing friends and the ow for updating connections.
Additionally, both Mike and Charles worked to deploy Chowdr onto heroku and
to release a live version at www.chowdr.co.
For more specics on contribution breakdown, please refer to the contributors
section on Chowdrs github repository.
Figure 5: Individual and group contribution over total time for Chowdr.
Further Work
There are numerous ideas and possible extensions that Chowdr could pursue given
the time and resources. The following section attempts to list and explain a handful
of them, with some being more important than others:
Currently, a users feed consists of posts that are ordered by reverse timestamps,
meaning that the newest post is displayed rst in sequential order. This isnt
15
very sustainable since there is no deletion of posts. At the most basic level,
there should be an additional implementation of a moving window of N posts.
Additionally, there could be a recommendation algorithm to pick what the feed
array of posts should be composed of based on dierent user interests. This
entails either a statistical number for a vector of features that dene individual
users - i.e. location, post topics using NLP, quantity and hashed identity of
unviewable friends, etc. Given that these features are plottable numerics, us-
age of a k-means function should allow us to nd the most compatible Chowdr
users. Prioritizing posts by these users can help create a more interesting UX.
Figure 6: The clustering algorithm would theoretically produce groups like
the above image based on the statistical vectors. Each user (represented
by a dot) would be recommended other users from its own cluster in order
based on k-means distance away.
Most social media sites like Facebook and Twitter entail relationships between
users, as in friending or following. Chowdr takes advantage of these relation-
ships from other social medias but its also possible for Chowdr to implement
relationships of its own. This curates interesting concepts like sharing feed
posts, or a possible forum/chat system only with a users own viewable users,
or being able to re-blog posts that a user specically likes.
Facebook captures a large portion of a users online social life, but there is
the possibility of adding additional sites like LinkedIn and Twitter to better
capture a larger percentage. These authorization models would operate much
the same way - entails the user to grant access to Chowdr through a login
redirect, letting Chowdr pull connections and add to our viewable table.
A large improvement to the current state would be adding asynchronicity to
the generation and update of viewables table. Currently, the rst sign-in re-
quires a large amount of time since to generate the feed, Chowdr looks at each
of the current pages posts user and ensures that there are no lapping connec-
tions within two degrees of the current_user. This is an expensive operation,
especially to generate. As a result, the page hangs in loading before redirecting
to the users prole. One way to solve this is to make this generation asyn-
chronous such that it runs in the background while the new page loads.
16
Figure 7: An example of an asynchronous module vs a serialized one. There
is an significant increase in efficiency.
In modern social media sites, the user experience is extremely important and
related to users time spent on the site. Currently, users are given the ability to
control two pictures, their nickname, and two descriptive taglines. Further de-
velopments should seek to add additional customization to the user front end,
perhaps providing an easy method to change the structure and viewable content
on their own prole page, i.e. like Github, a customizable default SVG prole
picture would be an attractive addition. There is also consideration in using
AngularJS such that likes and comments are updated without forced page
refresh. In addition, data transparency is also a common trend and many sites
allow users to track and at times, edit their own data (consider Fitbit, Google
Analytics, etc.). It would be interesting for Chowdr to include a visualization
of the users anonymity network (probably in the form of a graph/tree/web) in
conjunction to their Facebook/twitter/LinkedIn network and how this network
changes over time, providing some insight in the shifts in a users social life.
A heightened focus on security. Some of urls like users_path (the index path
listing all users in Chowdr - useful to admins) are open to all users to see,
which is a functionality that should not exist. Currently the url is not linkable
from the frontend but is not password or ID protected either, making it easy
for any user to access it. Given recent events with Heartbleed, there should be
a larger focus on guarding potential user information.
Conclusions
This paper describes a preliminary implementation of a anonymous social network
built on an antisocial platform. Chowdr is a proof-of-concept application, and can be
considered a good start to a more robust and more functional solution to the problem
of true anonymity on the internet and especially, social media. Several features that
could have been implemented were ignored due to time and power constraints, some
of which could have greatly improved the viability of our solution. For example,
integrating multiple sources of social media (i.e. drawing connections from LinkedIn,
Twitter, Gmail, etc.) would create a more accurate portrayal of a users internet
social circle. A recommendation system to match groups of similar users based on
statistical metadata would help make each users experience on Chowdr much more
17
relatable and personal.
Chowdr was built in Rails and heavily used the MVC architecture to create and
save users who can post, comment, and like a modied selection of posts in a feed.
It utilized the Facebook API to populate an antisocial network and was developed
with an emphasis on user experience and user customization.
By creating an antisocial network that focuses greatly on building at least two
degrees of separation between all users helps to ensure a safer place to publish posts.
Because social media is often used to share very personal opinions, current applica-
tions like Secret and Whisper fail to address the issue of anonymity, thereby discour-
aging individual users from sharing all that they would like to. This paper presented
a solution and described Chowdr, a thorough implementation of a demonstrative
subset of features necessary for such a system.
Acknowledgements
The authors would like to thank Debayan Gupta for his guidance in the creation
of this project and this paper. We would also like to thank Avi Silberschatz for
teaching many of the concepts relevant to the design of Chowdr. Finally, we would
like to thank our peers for their detailed comments and inputs regarding the mission
of Chowdr.
References
[1] Michael Hartl Ruby on Rails Revision 42. 2013: Rails Tutorial.
[2] Amazon Working with Amazon S3 Buckets 2006.
[3] Giuseppe DeCandia et. al. Dynamo: Amazons Highly Available Key-value Store
2007: SOSP.
[4] Laith Ulaby Social Networks can be More than Just a Like 2014: UX Magazine.
[5] Github Github Developer Documentation 2014: Creative Commons.
[6] Dave Gandy Font Awesome Examples and Documentation 2014: Creative Com-
mons.
[7] Dave Gandy Font Awesome Examples and Documentation 2014: Creative Com-
mons by 3.0.
18
[8] Twitter Boostrap 3.0 Documentation 2014: Creative Commons by 3.0.
[9] Felix Bachmann et. al. Software Architecture Documentation in Practice: Docu-
menting Architectural Layers 2000: Carnegie Mellon University.
[10] Je Atwood Understanding Model-View-Controller 2008: Coding Horror Blog:
Programming and Human Factors.
[11] Rails Guides Getting Started with Rails: REST 2014: Creative Commons.
[12] Heroku Developer Center Architecting Applications for Heroku 2014.
[13] Pete Hodgson Testing Asynchronous JavaScript 13: Martin Fowler Articles.
19