Professional Documents
Culture Documents
3. Additions to Joshua Project Photo / Data Gathering Mobile App (by Joshua Project)
Add graphics and several ministry and ethnographic survey questions to the Android Unreached
People of the Day mobile app which was developed at the 2016 Code-A-Thon. If possible, begin iOS
development of the same app
(Languages/Platforms: Android Studio / java / iOS)
Notes: There are two projects here one, to write an iOS version of the existing Android app, and
two, to extend the functionality of the Android app. You'll be able to select which you prefer when
registering your team/project preferences.
Score: 8.3/10
4. Evenki children's Bible story app (by (1) Pioneers (2) IBT)
Be part of reaching a people group in Siberia that don't know Jesus and God's redemptive story.
Develop an Android app transforming a heavy book into something portable for nomads. Make Bible
stories available in text and audio for the Evenki, an unreached people with an endangered language.
(Languages/Platforms: Android app. )
Notes: A language learning app for the Evenki people, as a pre-evangelistic tool, was completed at
last year's Code-a-Thon. There are now a few hundred users of that app among the Evenki people (a
small unreached people group in Siberia). This app is separate from that, but for the same people
group.
Not available for the week of March 20-24.
Score: 8.8/10
11. Distributed Praise & Worship for a Virtual Community (by LightSys)
Oftentimes today, communities of believers are working together across a distance. However, there
are many aspects of "doing church" together that don't work as well across a distance. This is a
brainstorming project to find ways that believers can worship together in song, across a distance.
(Languages/Platforms: Brainstorming project; perhaps some Java.)
Notes: this is a newly added project.
Score: Unscored (newly added)
Communications Security Research
From SBCaT
Contents
1 Submitter Information
2 Project Proposal
2.1 Communications Security Research
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Greg Beeley
Timezone: US-Mountain
Organization: LightSys
Website: LightSys.org
Location: Colorado Springs, CO
Email: greg.beeley@lightsys.org
Skype: gbeeley
Phone: 4045309797
Other Contact: Google Hangouts - gregbeeley
Submitted On: 11 Jan 2017 18:02
Project Proposal
Communications Security Research
This project is a proof-of-concept to demonstrate the dangers of focusing on encryption while ignoring the
metadata problem.
If multiple teams are interested in this project, we may combine them together, as this project may be suitable for a
larger team collaborating on a diversity of ideas.
1. Project team members will be provided with anonymized metadata for all of the WiFi and network activities at
Code-a-Thon. IP addresses will be anonymized, but in a way that is consistent from one packet to another. Packet
contents will not be provided, but accurate information about packet length and timestamp of transmission or
reception will be provided. This will be real-world data from Code-a-Thon.
2. Project team members will then use any tips and techniques at their disposal to mine the provided data for
patterns, with the goal of grouping the client-side IP addresses, though anonymized, into related groups, which
likely correspond to Code-a-Thon project teams and perhaps to the universities that participants came from. For
example, it may be found that IP's Aardvark, Bear, Eagle, and Hound have correlations in activity, so Aardvark-
Bear-Eagle-Hound is a subgroup.
3. As the Code-a-Thon week goes on, the project team should produce a diagram (electronically or on a
whiteboard) of relationships between the anonymized IP's. LightSys may additionally "plant" secret relationships
between certain Code-a-Thon participants, in terms of communication with each other, that may be able to be
discovered and charted.
4. Project team members will be encouraged to propose ideas that help reduce the possibility of the type of
subgroup analysis and correlation that can be possible from data mining.
5. The "Easy" version of this project (where anonymized destination IP's and ports were also provided) was done at
Code-a-Thon 2016, with success. This year's version is the "Challenging" version. Participants working on the
"Challenging Version" will be provided regularly with CSV files containing the following information:
anonymized internal IP, packet length, packet timestamp, and packet direction.
6. Information that will NOT be provided: packet contents, web addresses, actual IP's, source ports, protocols,
actual users associated with the IP's, and destination information.
7. At the end of the week, the discovered data will be compared with real information to see how well the team(s)
did.
This, of course, is a data mining project. Unlike the easy version of this project (done last year - where anonymized
destination IP's were provided), in this project there is very little in correlatable data in the source data file itself. In
order for correlation to scale well to massive data sets, correlatable data must somehow be generated, so there is at
a minimum one extra step involved in this version of the project.
The team working on the easy version last year made exclusive use of the anonymized source IP's (Dog, Cat,
Alligator, etc.), and anonymized destination IP's (created using a simplistic keyed hash function). They wrote a
correlation program which then mapped correlations between individual source IP's. That process (while it
certainly can be further improved) was successful, giving at least a 70% accuracy rate in clustering people into the
Code-a-Thon teams they were a part of, more than enough to duly impress the Code-a-Thon audience.
This harder version omits the destination IP's, leaving just anonymized internal IP, timestamp, direction (ingressing
or egressing), and size. This simulates users on VPN or Tor connections.
The trick is to generate the correlatable data from the raw data set, which will involve building a secondary list of
anonymized internal IP's, correlation keys (which may simply be a 32-bit hash value), correlation key derivation
method, and frequency of occurrence. We encourage the participants to spend time researching and brainstorming
this, but here are a few possibilities that come to mind for methods (note that correlation keys may be a hashed
integer, or the raw pre-hashed data if variable-length keys are used):
1. Packet sizes and directions. This of course is overly simplistic, but hash(concat(size, direction)) may generate a
useful key.
2. Curve fitting analysis. In this case, the packet sizes and timestamps are conceptually plotted on a graph, and
polynomial (or other) curve fitting done to match the graph. This needs to be done over small intervals, and the
constant x-offset needs to be tracked separately rather than integrated into the polynomial. The x-offset and
coefficients/parameters are then quantized (and maybe 0th power eliminated) and then hashed to generate the
correlation key.
3. Size-Interval analysis. Here, the packet size and the time interval since the previous packet (or, possibly, the
previous packet going the same direction) are quantized and hashed to create a correlation key.
4. Response Interval analysis. As a more specific case of the above, after a period of relative quiet (maybe a second
or two at least), the interval is measured between a packet sent and a packet received (vice versa might not be as
meaningful as internet latency wouldn't be measured). This can give an indication of the latency between the client
and server, and this latency, possibly combined with the packet sizes, could be hashed to give a correlation key.
Once a collection of correlatable keys is compiled, normal correlations can be analyzed. The trick here is that there
will be a lot of noise to filter out - random-ish data that doesn't have strong meaning. If some kind of feedback loop
can be established, Bayesian analysis may help weed out measures that aren't specific enough for clustering the
internal IP's.
Before creating correlation keys, there are several bits of analysis that can be done to attempt to classify a packet as
a certain type based on its size and other packets near in time.
1. Bare TCP ACK packets are the smallest, and are regularly sent in response to other packets.
2. Shell connections (SSH) involve a lot of small packets in rapid succession as users type and receive echoes
back.
3. Voice connections have a rapid series of small packets that often vary in size based on whether or not a person is
talking (silence suppression = smaller packets). Note that the pattern introduced by the silence suppression can
potentially be used to match up conversations.
4. A download or web transfer will involve a series of maximal-sized packets (1536 or thereabouts) bytes,
followed by a smaller packet to end the transfer.
5. Text chats will involve small packets for the "I'm typing" indication, and small-to-moderate packets for the
content of a chat message. Like voice conversations, this low-latency communication creates a matchable pattern.
6. TCP connections involve a connection set-up, with a SYN packet sent out, a SYN-ACK response, and then an
ACK going back out.
7. The precise size of TCP ACK packets could be used to help fingerprint the operating system, based on IP
options in the IP packet header. It could also help discern whether the user is using a VPN within a VPN.
We encourage participants in this project to become very familiar with packet traces and patterns, especially on
both ends of a communication.
DanDennison: 02/05 I think this is a 7. It's an interesting systems problem, but feels more like a demonstration to
the students present rather than having lasting value beyond the CodeAThon. Maybe if there is a commitment to
presenting the data at ICCM or EMDC framed in the context of "Look what our students did in a week" or some
such, to emphasize how "easy" it was to determine what was going on by an adversary, I would be more excited.
Also, this project assumes a fair bit of working statistics knowledge for the "Challenging" version. I would steer
the math oriented students to this, and the pure systems students away from it to get good results.
GregBeeley: 02/05 @Dan yes we're planning on presenting this information at ICCM 2017. The main goal of the
project is a proof of concept to get missions people thinking about countermeasures.
Tumbler: 02/06 I think I agree with Dan on the 7. This sounds like a really fun and doable project. However, while
I can understand why this could be useful for ICCM, it's still is kind of hard to make the supporters understand
why hacking Code-A-Thon was a service. :)
Contents
1 Submitter Information
2 Project Proposal
2.1 Improve Language Guessing Game
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: James Thomas
Timezone: +11
Organization: Global Recordings Network
Website: https://globalrecordings.net
Location: Sydney, Australia
Email: jamesthomas@globalrecordings.net
Skype: james5.thomas1
Phone: +61428209103
Other Contact:
Submitted On: 11 Jan 2017 22:10
Project Proposal
Improve Language Guessing Game
This game aims to provide a fun and engaging way to raise awareness of the number of spoken languages in the
world.
GRN would like the 2017 code-a-thon team to implement the following improvements:
- reward badges
- landscape orientation
(2) the world's major languages (speaker populations above 50 million or so),
(4) guess the language played from any one of GRN's 5,000+ language samples,
Modes 5, 6, 7, and 8 can be combined allowing the user to progress to each stage while a single audio sample is played.
The app is currently installed on 15 active devices. The full extent of the impact of this app is unknown. It is
unknown whether the app will be used for real ministry purposes within one year.
Submitter Agreed To / Can Help With
The students will not have to sign a Non-Disclosure Agreement for any technologies: Y
The students will not have to purchase any software to work on this project: Y
A small attribution may be added in the 'About' part of the project that indicates that the project was written
at Code-a-Thon: Y
Concise instructions will be available for students to set up the development environment on their computer:
Y
I, or another staff member, will be readily available in-person or on-line to answer students' questions during
the week of the Code-a-Thon: Y
I believe that this project can be completed by a team of 3 students over a period of 4 days: Y
I am willing to reduce the scope of this project, if need be, to ensure its success: Y
This project will be used by people for real ministry purposes within the next year:
The work done by the student volunteers is not intended for me or my organization for commercial gain (this
is to avoid violating labor laws): Y
This project is open-source:
We have a source code repository that the students will have access to, e.g., Git, SVN, CVS, Hg, Bzr: Y
A Virtual Machine image containing the entire development platform for the project will be made available:
I am willing to travel out to Colorado Springs, CO, to be a part of Code-a-Thon (amazing if you can, but not
at all required):
I am willing to be available to fully test what the students have written, daily during the week of Code-a-
Thon: Y
We will provide test data for the students to use (an NDA is allowable if the data is 'live' data from your
ministry): Y
Tumbler: 02/06 I'm curious what kind of badges they are looking for. Simple things like, "You beat all the modes!"
wouldn't be too hard, but setting up all the tracking for complicated badges could be a bit of a challenge.
DanDennison: 02/05 Ranking 8 There is a lot of scope proposed here, so I think it will be critical to narrow down
early on what the goals are. To this end, the submitter should prioritize the list to help drive the students toward the
greatest impact features. For instance, depending on how the UI is written, it might be a lot of work to get
landscape working properly. Overall this sounds like a great idea and it might make sense to put DuoLingo hooks
for languages that have a match.
Tumbler: 02/06 I'll give it a 9. It seems doable to me given that a lot of the basics of the app has already been
written, but then again I was never good at hitting the turtle so Dan might be right. :) It's a good opportunity to
learn android without having to go through the hassle of starting from scratch.
Contents
1 Submitter Information
2 Project Proposal
2.1 Additions to Joshua Project Photo / Data Gathering Mobile App
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Dan Scribner
Timezone: Mountain
Organization: Joshua Project
Website: www.joshuaproject.net
Location: Colorado Springs
Email: dan@joshuaproject.net
Skype: dscribner321
Phone: 719.886.4000
Other Contact:
Submitted On: 12 Jan 2017 14:38
Project Proposal
Additions to Joshua Project Photo / Data Gathering Mobile App
Add graphics and several ministry and ethnographic survey questions to the Android Unreached People of the Day
mobile app which was developed at the 2016 Code-A-Thon. If possible, begin iOS development of the same app
Additions to Joshua Project Photo / Data Gathering Mobile App developed at the 2016 Code-A-Thon.
Add graphics of various people groups to increase visual appeal
Add several survey questions to the Android mobile app. Survey questions include:
[Checkbox] Outsiders
4. [Checkbox] A church planting movement (numerous reproducing churches) is occurring within this group
We have Charis Bible College and others waiting to use the app
16-30 hours
2-4 hours to get familiar with the code
8-16 hours for "graphics of people groups", most time will likely be spent choosing where/how to
display them, not with actual coding
1 hour per new question (probably less)
4 hours test
iOS is harder to estimate, as I don't recall what all is in the current project. I would think 32-40 hours would get a
decent prototype, and upload it to Apple for TestFlight testing, so current progress can be showcased.
Teh C. 2/6 Those look like different apps. I can't find any references to the app being described here (although it
sounds like it already exists...).
DanDennison 02/05. Rank 7 The scope outside of the iOS changes seems very do-able, although it is going to be
very useful to consider who the users are.
Tumbler 02/06. 6. It seems to me that maybe about half of this project is "Adding graphics." Unless you have a
dedicated graphics guy there, I'm not sure most of the coders could get quite what they had in mind. Not to say
there aren't any coders that can do graphics, I just think it's usually better left to artists. Aside from that, adding a
couple of radio buttons and check boxes seems very doable. That portion would be great for one of the less
experienced teams.
GregBeeley 02/06 @Tumbler - we do have people coming who are strong in graphic/web design (we're looking
forward to them being at Code-a-Thon!)
Contents
1 Submitter Information
2 Project Proposal
2.1 Evenki children's Bible story app
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Paul Kube
Timezone: Yakutsk UTC +9
Organization: (1) Pioneers (2) IBT
Website: (1) https://ibtrussia.org/en (2) pioneers.org
Location: IBT- Moscow. Pioneers- Orlando, Australia, others.
Email: kube.siberia@gmail.com
Skype: pashlik
Phone: +61390149466 (via skype)
Other Contact: +79140622970 (mobile in Russia)
Submitted On: 16 Jan 2017 19:56
Project Proposal
Evenki children's Bible story app
Be part of reaching a people group in Siberia that dont know Jesus and Gods redemptive story. Develop an
Android app transforming a heavy book into something portable for nomads. Make Bible stories available in text
and audio for the Evenki, an unreached people with an endangered language.
Would you like to be part of reaching a people group in Siberia that knows very little about Jesus and Gods
redemptive story throughout the Bible?
The Evenki people group are one of 40 unreached people groups in Siberia. They have a religious world view call
Shamanism, living in fear of evil spirits. They dont know who Jesus is and that he is more powerful than the evil
spirits and can set them free.
Evenki people are traditionally nomadic reindeer herders. There are still many nomads today, although more live in
villages scattered throughout the Siberian taiga forest. Their language is endangered, which means it could die out
within a generation. It is therefore vitally important to get Gods word in to peoples hands and ears as quickly
as possible, even before a complete Bible translation project could be completed.
Institue for Bible Translation in Moscow (IBT) have translated 250 Bible stories from the Old and New Testaments
into Evenki. It is very hard to distribute the books though as the villages are scattered over large distances and in
isolated parts of Siberia.
The project needed is to develop an app, which I have mapped out already (and have experience working on a
previous app with previous code-a-thon teams). The app will make the text and a picture for the 250 stories
available from a contents list. Each of the stories will scroll up and down. The audio for each story will be stored
on a server (likely an IBT server), which can be listened to online, or audio for individual stories could be made
available offline by checking a check box in the contents. Russian text and audio will also be included in the app.
No matter the amount of Evenki language that the individual knows, they will be able to follow the story in either
Evenki or Russian, or any combination of the two to make it easier to understand.
Communicating Gods Word and the Gospel to people in their heart language is the most powerful means of
getting the message across. Through a sad and complicated course of historical events, Evenki do not often have
access to Gods word in their heart language. Their heart language is Evenki, even if they dont speak it very
well. This project has the potential to affirm Evenki in their identity as being created by God and gives them the
opportunity to discover his eternal love and salvation for them. This is a unique opportunity to impact an
unreached people group in a very hard to reach location.
________________________________________________
As I mentioned above, I have been working to map out what the app will look like. I have thought about many of
the finer detailed features it will need. I am able to do this well now having helped develop a previous app called
Learn Evenki developed by previous code-a-thon teams. This project should be technically a lot simpler than
the previous project, the biggest difference being the ability to retrieve audio from an external server.
I am happy to work with the team throughout the week as the app is developed and coded. I would like to meet the
team once before the project begins on skype. Then each day, usually chat for 15-30 minutes to help iron out
questions and bugs as the app is developed.
The priority is to develop the app for Android. Most Evenki people have Android devices these days. Some have
Apple devices, but not as many. If a second team wanted to develop the app for iOS that could still have far
reaching benefits. Once code has been developed for Android (or iOS), then the concept could easily be
transferrable for other languages in Siberia, Russia and Central Asia, in all of the countries where IBT does Bible
translation.
During the process of developing the app, a prototype can be released as an .apk file that I can download to my
Samsung tablet and then test for bugs. Light Sys has a Samsung tablet too, so it can be used for testing bugs also. If
students have other Android devices, it is always beneficial to test on as many varied devices as possible.
___________________________________________________
My name is Paul and my wife is Melody. We work in Siberia with a mission called Pioneers. We have been here
for ten years now. We are specifically working to disciple and reach the Evenki people group. We are also qualified
as linguists. We have recently been invited to partner with IBT on some of their projects including Bible
translation. This app has the potential to be of great assistance in our efforts to spread the gospel amongst the
Evenki people. We anticipate the opportunity to work together with you on a very valuable project.
Kurt Symanzik, Rank 10. It would be good to plan/design this from the start to handle multiple languages so that it
could be used for other people groups easily as well without requiring any change to the app itself in order to be
used for another language.
Tom Francis 02/02/2017. 10. This seems pretty simple, and largely just a front-end for a website. I'd probably
recommend doing it as such, and wrapping it with cordova or similar. EXCEPTION: There's some missing detail
above, and if one of those details is that text should automatically scroll and be synchronized to the audio, I'd
probably recommend a native app instead. There might be some projects for javascript to do that, but I suspect
they'd be more difficult to use.
DanDennison 02/05 Rank 5 -- I'm on the fence here. There are many bible story apps out there, such as Bible App
for Kids from YouVersion. Has any attempt been made to get in touch with them to do a localization? I assume
security is also an issue, but likewise, have any attempts been made to contact ? If not, I think some more detail in
the writeup about prior art would be helpful before starting something new. If you end up having to build from
scratch, I strongly recommend Tom's approach.
Tumbler 02/06 9. I agree with Tim. This could take more than one week to finish, but has a lot of potential.
Nothing too difficult if it's just pictures and text, but it might take a week to build it from scratch and then another
to make it run nicely.
This page was last modified on 7 February 2017, at 13:51.
Security Audit add-on for Firefox or Chrome
From SBCaT
Your edit was saved.
Contents
1 Submitter Information
2 Project Proposal
2.1 Security Audit add-on for Firefox or Chrome
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Greg Beeley
Timezone: US-Mountain
Organization: LightSys
Website: LightSys.org
Location: Colorado Springs, CO
Email: Greg.Beeley@LightSys.org
Skype: gbeeley
Phone: 4045039797
Other Contact: Hangouts: gregbeeley@gmail.com
Submitted On: 18 Jan 2017 13:38
Project Proposal
Security Audit add-on for Firefox or Chrome
Many organizations struggle with security risks created by users installing risky add-ons to browsers. This is
especially true in bring-your-own-device environments or work-from-home environments. This project creates a
browser add-on to audit the browser's security.
0. On installation, asking the user for a URL to load a configuration file from.
1. Scanning the browser's configuration to determine if any risky configuration options are set.
2. Scanning the browser's extensions/add-ons list, and comparing that with a configurable whitelist.
3. Determining how long it has been since the browser was updated.
4. Making a decision based on the above of whether the browser passes or fails the security audit.
5. When the browser goes to a URL, the hostname is compared (via salted hashing) with a list of hashes for
"secured areas". If a hash matches, and the browser is "failing" the audit, the request is blocked with an error page
that lists the reasons for the failure.
6. When the browser goes to a secured URL, an extra HTTP header, "X-Audit: passed
f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2" (with a sha-256 hash* of the audit
add-on's configuration) is included, so the site being accessed can assess whether or not to continue allowing the
connection and sign-in.
7. When the user tries to install an add-on/extensions that's not on the whitelist, or tries to make non-compliant
configuration changes, the user is (configurably) blocked or warned that the change or add-on's presence will
prevent access to some important websites.
8. When the user goes to a secured URL that is specifically marked for update-checking, the add-on will
automatically check for a configuration update at a specific pathname, and import the update if it exists.
Generating the configuration hash is tricky. This must only include options for this add-on, not other options
for the browser and not options that are being monitored by this add-on. The salted hashes should not be
included, but everything else
should, in a way that results in a consistent result regardless of the *order* of the configuration options. This will
likely require sorting in advance of hashing.
The add-on's configuration will be stored in the browser's configuration options list. However, the configuration
file (aspects 0 and 8) will contain options that will then be imported into the browser's configuration. If the
configuration file contains secured URL locations, those will be passed through a salted hash before being
imported.
This add-on won't provide perfect security. Someone could write a malicious add-on that impersonates this one,
and the web server could never know. The user's machine may also have security issues outside of the browser
itself. But this add-on should provide a significant improvement in security for the target audience of bring-your-
own-device users, and ordinary anti-malware software could enforce other computer/device security options.
Phasing: We don't expect this add-on to be 100% complete during Code-a-Thon. However, a start would allow this
to be a proof of concept, and would also allow participants and the review team to examine any pre-existing
software that could serve this function and/or serve as a (if open source) starting point for this add-on. Even
completion of the first phase would help get this project off the ground.
Deliverables would include complete source code to the add-on, documentation, and ensuring LightSys has
sufficient copyright rights to the code so that LightSys can continue to use and develop the project.
For performance, the browser and server can pre-hash the configuration and use that hash as the key to HMAC
(HMAC internally hashes the key anyhow when the key is longer than the hash's blocksize). That saves a bit of
CPU time in not having to re-hash the entire config every time a request is issued and validated.
If the server chooses to, it can maintain a list of used salts and reject X-Audit headers re-using an already-used salt.
We could consider a counter here or a s/key or RKE style OTP system for generating salt (so the server could
prevent replay without maintaining a huge list), but that would require the browser to maintain state (and to do so
for each secured URL), something that would have to be carefully considered based on what happens when the
user re-installs the browser or logs in using a second device. I say this is a second go-around consideration.
GregBeeley 02/07: As I've thought about this some more, I think the counter idea is a good one, and the counter
and failed/passed should be included with the salt in the "message" for the HMAC computation. However, the
counter is a "phase two" thing here. If participants are really ambitious and want to know more about this option,
we can discuss it after project selection.
Tom Francis 02/02/2017. 9. My biggest concern is if the usefulness of the add-on will outlive its ability to do its
job. Chrome, e.g. has been restricting what add-ons canedit
Your dowas
about
other add-ons;
saved. I expect it won't be long before
add-ons cannot enumerate other add-ons. I would suggest the X-Audit header _always_ be sent to the "secured"
URLs, not just when everything is OK. That should prevent another add-on from masquerading as this one (so
long as this one is actually installed), since the server would receive the header twice, once indicating failure (from
this add-on), and once indicating success (from the fake). The server could then choose to just deny access. I'd also
recommend a random salt that is prefixed to the value, and truncate the hash (so someone would have to inspect
the add-on to determine it's not just a hash). That's a good deal more work for the server, but it allows future
expansion of using different configurations for different servers, and forces any masquerading to be done at the
browser level, and not by a man-in-the-middle, since the MiTM couldn't have access to the actual configuration. A
simplified version of the add-on which doesn't have "secured" URLs and doesn't send the special header could also
be generically useful, as I haven't found any generic add-on blacklists outside of some AV programs (which have
been heavily criticized for blocking the good stuff and letting the malware go unchecked).
GregBeeley 02/03/2017: Good thoughts, Tom, on the salt and on always emitting the X-Audit header. I had
assumed the browser would not emit the same header twice, but I did not test that. :) Verifying the salt/hash
shouldn't be a compute problem for the server (I wasn't considering an iterative hash here to try to further conceal
the config; that would be quite expensive to apply to every request).
DanDennison 02/05 Rank 10 I think this is a great idea. I too have similar concerns about the longer-term
usefulness of this, but it is a start. I think it should be an Extension so that it can change its icon to indicate all is
not well and cite the reason for it when clicked on. Strongly suggest recommending to the users to store client certs
in TPMs or Yubikeys. The phased development idea also warms the heart. I would package this for deployment
with many things left for the enterprise to customize, e.g. the secured URL list, the name of the special header, (if
possible in Chrome) the desired header order to use when hitting secured sites, and (most importantly) the ability
to pin certificates for the configuration server and for the secured sites!!
Contents
1 Submitter Information
2 Project Proposal
2.1 Church Planting Needs On-line Interactive Map
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Larry Kraft
Timezone: GMT
Organization: OC International
Website: www.ocresearch.info
Location: Colorado Springs
Email: larrysteph@worksmail.net
Skype: larrykraft
Phone: +44-7910-302-877
Other Contact: +1-410-929-2840 (google voice which sometimes gets through to me in England)
Submitted On: 20 Jan 2017 13:42
Project Proposal
Church Planting Needs On-line Interactive Map
The Global Church Planting Network has data about the number of new churches needed in each country,
population to church ratio in each country which indicates relative church planting need, number of evangelicals,
etc. We would like an interactive map to display this information.
Languages/Tools: I was once told SCG would be best for this, but really don't have the expertise to know for
sure. What was used in the above examples would be a better guide.
Can Dev on Mac: Y
Can Dev on Linux: Y
Can Dev on Windows: Y
Security Classification: SEC3 - Public (There are just a couple of days in the weeks I checked when I will be
traveling, but should be around most of the time. I will do my best to have someone else available on those
days.
Greg, Since I am a researcher and not a programmer, I may need your help to better formulate the project.
Thanks!)
The overall goal is an interactive map of the world which will display a bar graph and explanation of key data
relative to church planting need when the mouse is passed over or clicked in a country and some global totals of
data when the mouse is off the map. The map should be zoomable so smaller countries can be seen and clicked.
This needs to be hosted on the gcpn.info web site so people interested in global church planting can access it to use
in guiding their prioritization of the sending of church planters around the world.
IN October 2016, Nicholas Pierce worked on this project at the London Hackathon - Code for the Kingdom. He
didn't finish the project, but has made the code available to whomever would like to continue. We would be happy
to see it carried forward or something new created. Here is his description of what was accomplished with some
links to the code developed and an sample site:
"Myself and another guy created a simple site called "Map This". The site lets you upload a CSV of information
ordered by country, or other geographical area, and generates you a nice little map and an information area with all
the stats.
I took the dataset you gave me and carved out the yellow columns and uploaded it to the site. You can see the
results at this link: http://mapthis.tjvr.org/doc/kbqods. If you mouse over the countries you'll get the various
statistics shown on the right and when you click on one of the statistics the map will be coloured based on that stat.
You can create your own maps if you like, by going to http://mapthis.tjvr.org/create. I've attached the dataset I used
to generate the map above, and another CSV with population vs. English county that will generate you a nice map.
The Hackathon had a particular challenge for data visualisation, which we won!
The site is really just a prototype at the moment, and is being hosted by the other guy I worked with at the
weekend, so it's a neat toy, but not properly usable yet. While neither of us have time to work on this much more,
the code is available at https://github.com/pixafera/mapvis, should anyone else be interested in improving what
we've started."
The goal is to have something that can be hosted on the GCPN web site where people can be challenged to better
deploy mission/church planting resources toward completing the Great Commission in all countries of the world. I
liked the idea of being able to upload a CSV to update the data when new information comes available. There are
other strategic questions being considered which such a system could be used for, such as the deployment of
resources for poverty reduction, the number of refugees from different countries and their relative levels of need,
etc.
Submitter Agreed To / Can Help With
The students will not have to sign a Non-Disclosure Agreement for any technologies: Y
The students will not have to purchase any software to work on this project: Y
A small attribution may be added in the 'About' part of the project that indicates that the project was written
at Code-a-Thon: Y
Concise instructions will be available for students to set up the development environment on their computer:
Y
I, or another staff member, will be readily available in-person or on-line to answer students' questions during
the week of the Code-a-Thon: Y
I believe that this project can be completed by a team of 3 students over a period of 4 days: Y
I am willing to reduce the scope of this project, if need be, to ensure its success: Y
This project will be used by people for real ministry purposes within the next year: Y
The work done by the student volunteers is not intended for me or my organization for commercial gain (this
is to avoid violating labor laws): Y
This project is open-source: Y
We have a source code repository that the students will have access to, e.g., Git, SVN, CVS, Hg, Bzr: Y
A Virtual Machine image containing the entire development platform for the project will be made available:
I am willing to travel out to Colorado Springs, CO, to be a part of Code-a-Thon (amazing if you can, but not
at all required):
I am willing to be available to fully test what the students have written, daily during the week of Code-a-
Thon: Y
We will provide test data for the students to use (an NDA is allowable if the data is 'live' data from your
ministry):
Tom Francis 02/02/2017 Without speaking to security aspects, the python code of the current demo is a little hard
to follow, but perhaps that's partly because I always find python hard to follow. :) It would seem easier to use
something like Google's Maps API (check out the "Combining Data" example at
https://developers.google.com/maps/documentation/javascript/combining-data), but I'm not sure Google's terms of
service are compatible with the goals of this project. There are some alternatives that use OpenStreetMaps, but
documentation is sparse, and some of them either have expensive licensing or heavy backend requirements. I like
the idea, but extending the mapthis project for things like zoom would mostly benefit the makers of that project.
However, it seems that project does handle most of the requirements already.
TimYoung: 02/03/2017 -- I talked to Bill Dickson. His thoughts were that this, as stated, is most likely just a little
bit of text on their website and their data uploaded to one of a few different mapping sites. But Bill is pretty sure
that what they actually need is a lot more. Bill's suggestion is that it not be done as a code-a-thon, but rather that
we pass this off to him and have Bill do it as a LightSys consultant. The other thing we could do would be to bring
Bill in as a Code-a-thon reviewer and have him interface with Larry on this (they know each other), and see where
it goes from there.
Tumbler 02/06 -- I'm curious why "We will provide test data for the students to use" isn't checked. I feel that if the
student's are going to take on this project they will need access to the data.
Tumbler 02/06: 7. This seems like a really neat project that has good use and could be a lot of fun. I do think it's a
bit large for a Code-A-Thon and that quite a bit of coding would be involved. But I think that it could still be a
great effort between two or three weeks.
Contents
1 Submitter Information
2 Project Proposal
2.1 NAME in Europe Prayer App
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Tanner Smyrl
Timezone: Central European Time
Organization: IMB
Website: www.imb.org
Location: Richmond, VA
Email: tanner@pobox.com
Skype: tannerandaudrey
Phone: +32476935599
Other Contact: 13232755704 - Jabber
Submitted On: 23 Jan 2017 10:39
Project Proposal
NAME in Europe Prayer App
In searching for more modern, secure ways to send out prayer requests and updates, our team in Brussels would
like to have an app that our supporters can use to receive requests as often as they like. It must be secure, as we
work with Muslim immigrants and refugees.
Languages/Tools:
Can Dev on Mac:
Can Dev on Linux:
Can Dev on Windows:
Security Classification: SEC1 - LightSys Only (I believe that it would be possible to discuss this project
publicly, but only in a very general manner. Our names, place of service, etc. could not be on the internet. I
could speak more about this
directly to someone who might be working on the project. )
Our team is church planting among North African/Middle Eastern people in Brussels, Belgium. We know that
prayer is the basis of our work and that great things can happen when God's people are fervently praying. We
usually send out a .pdf newsletter via email to about 650 prayer supporters on a monthly basis, and to about 170 on
a weekly basis. We have been doing this for the past 8 years, and this method seems very outdated to us. We know
that people are busy and don't always have the time to read a newsletter or even want to take the time to have to
click open a .pdf file in an email. We also want to add a lot of young people to our prayer support list, and need a
way to get prayer requests to them in a modern, relevant manner.
But we cannot use social media tools like Facebook, Twitter, or Instagram, because we have to communicate with
our supporters in a very secure manner, since we work with Muslims. So, we had the idea of developing an app
that we could use to send out prayer requests and updates. It would need to be something that can only be
downloaded by receiving an invitation from us, or we would need another way to control who sees the content that
we release through the app. We also had the idea that the app users could determine themselves how often they
want to receive our notifications so that those who want more requests can get them, and those who do not will not
be bombarded with requests, thus becoming "desensitized" to our requests. We want the ability to send photos and
video through the app as well.
While we want to start small with our group of prayer supporters at first, we would like to eventually expand this
app and provide it to our other teams that are working with Muslims throughout Europe.
Our team can only do the basics in working with computers. We do not know code or even how apps work. We
would need to be treated like 5th graders...although 5th graders might know more than us!! In fact, I don't even
know how to answer all the questions that follow in this proposal!
Thank you for submitting the prayer app project for Code-a-Thon!
You mentioned it needs to be "secure". Security and risk management are very broad terms, so
we need a little more information to understand your needs better.
What would be the consequences of the prayer app content (photos, prayer needs,
newsletter PDF's, etc.) falling into the wrong hands?
Would the users of the prayer app seek to keep their association with you and with the
IMB a secret? And, if so, from whom? (government, grass roots opposition, criminal
elements, etc.)
You mentioned needing an app, but you didn't mention what types of devices your target
audience is using. Would this be primarily used by iPhone users, by Android users, by tablet
users, or by laptop users?
How do you envision distributing the app to your users? The best software integrity is provided
by distributing the app through the normal play stores (Apple app store, Google play), but
obviously you wouldn't want anything in the app at that point which points to missions work.
We do have ideas, though, for how to make that work and make it fairly easy.
They don't *see* IMB/missions association as a problem for the supporters. They're working in Belgium and
most of their supporters are in the U.S. with some scattered elsewhere as well. So the communication
channel itself doesn't pass through high-risk areas.
Their main security concern is that if the newsletters fall into the wrong grass-roots hands, it could ruin their
opportunities among local peoples they're trying to reach.
Devices would include Android and iOS. The submitter has an Android device.
They're not opposed to paying an annual fee for a more capable substrate account (G Drive or Dropbox).
The #1 concern here is alerting people to pray for requests. Direct emails and emails via MailChimp have
not worked out well.
I asked them that, if they still needed to be careful about prayer letter content (such as pixelating faces where
needed and not using real names), due to mobile device security concerns, would they still be interested in
an app. They said definitely "yes".
One thought here is using G Drive / Dropbox as a substrate, using GPG-encrypted files or whatnot, and have a "file
manager" type app that makes it ridiculously easy to see a list of prayer needs/letters/etc and gives the user a
notification when a new one shows up. The app could be a decent, and free/ad-free, "file manager" all by itself.
The app will need a secure server to pass data to / from. This server must be maintained if it is going to be
secure. They consider themselves at the 5th grade level for tech. Basically, an outsourced partner may need
to be in the loop.
None of the security concerns are addressed, except to tell us that security needs to be built in. Unless we
have a security guy who is current with security in that part of the world, I would not want to be the person
to roll out such a project.
GregBeeley 02-02-2017: My thought on this app is that a private server based solution may not even provide the
security they need. I would recommend an approach that piggybacks off of Google Drive or Dropbox or whatnot,
perhaps using similar approaches to what the secure chat app did back in 2015 -- Message-Passing via Dropbox,
Google Drive, ownCloud, etc.. If it is done that way, then mobile apps might be all that would be needed. An
intermediary server could be used if we needed to enforce higher latencies and/or size differentials, but that could
just be done as a "phase two" for this. If done without a dedicated server, instead piggybacking off of existing
infrastructures, I would consider a prototype of this requested app to be a laudable goal for a Code-a-Thon project.
Dan Dennison 02-05 Rank 1: I think S/MIME or encrypted Dropbox/Google Drive may be far easier to deploy for
them. This is likely a consulting opportunity than a software opportunity. An app would only draw more attention.
GregBeeley 02/06: I am still uncertain on the score on this at present. Meeting this need is important -- say an
8/10. Whether a custom app would improve on both communication and security beyond an email or a messaging
service (like Hangouts or Whatsapp or Skype or whatnot) is an unknown. Just a Dropbox or Google Drive alone
would not meet the need at all, and S/MIME just adds kludgyness to the existing mechanism (email) that they're
using but concerned about whether it is effectively reaching people. Since association risk is not a concern for this
missionary, an app drawing attention wouldn't be a problem in this case, esp. if the app has a significant user base
other than this missionary's community. The big issue is whether it is really the best way to go.
Teh C. 2/6 it's not clear to me what their threat model is. Are they worried about messages being intercepted in
transit? Stolen from the servers? Stolen from the device? Their response about "newsletters fall[ing] into the wrong
grass-roots hands" makes me think of social engineering attacks, and I don't know how you solve that technically...
Contents
1 Submitter Information
2 Project Proposal
2.1 Unreached People of the Day Website Redesign
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Dan Scribner
Timezone: Mountain
Organization: Joshua Project
Website: www.joshuaproject.net
Location: Colorado Springs
Email: dan@joshuaproject.net
Skype: dscribner321
Phone: 719.886.4000
Other Contact:
Submitted On: 23 Jan 2017 15:45
Project Proposal
Unreached People of the Day Website Redesign
The current Unreached People of the Day website (www.unreachedoftheday.org) is not responsive and does not
work properly on mobile devices. This project would be to replicate the functionality of present site into a modern
responsive site.
Either working from scratch or using a provided html / php template build a one page or multi-page responsive site
that has the same functionality as the original site.
3. Uses section
a. By mobile app
b. By email
e. By RSS
Joshua Project owns a license to a template that would provide a good start on the HTML, CSS and PHP. The
template is called Unify and is demo-ed here:
http://wrapbootstrap.com/preview/WB0412697
Something like the any of the following might be good starting points:
https://htmlstream.com/preview/unify-v1.9.7/One-Pages/Business/index.html
https://htmlstream.com/preview/unify-v1.9.7/One-Pages/Construction/index.html
https://htmlstream.com/preview/unify-v1.9.7/One-Pages/Lawyer/index.html
Submitter Agreed To / Can Help With
The students will not have to sign a Non-Disclosure Agreement for any technologies: Y
The students will not have to purchase any software to work on this project: Y
A small attribution may be added in the 'About' part of the project that indicates that the project was written
at Code-a-Thon: Y
Concise instructions will be available for students to set up the development environment on their computer:
Y
I, or another staff member, will be readily available in-person or on-line to answer students' questions during
the week of the Code-a-Thon: Y
I believe that this project can be completed by a team of 3 students over a period of 4 days: Y
I am willing to reduce the scope of this project, if need be, to ensure its success: Y
This project will be used by people for real ministry purposes within the next year: Y
The work done by the student volunteers is not intended for me or my organization for commercial gain (this
is to avoid violating labor laws): Y
This project is open-source: Y
We have a source code repository that the students will have access to, e.g., Git, SVN, CVS, Hg, Bzr: Y
A Virtual Machine image containing the entire development platform for the project will be made available:
I am willing to travel out to Colorado Springs, CO, to be a part of Code-a-Thon (amazing if you can, but not
at all required): Y
I am willing to be available to fully test what the students have written, daily during the week of Code-a-
Thon: Y
We will provide test data for the students to use (an NDA is allowable if the data is 'live' data from your
ministry): Y
DanDennison: 02/05 -- Need more data. This is the classical, my site is slow problem, and sometimes these things
can be as easy as add a caching layer or do a systems analysis of their infra. I suggest, if we want to go ahead, to
aim this at the more systems-oriented folks in the Code-A-Thon and start from there. It's likely not a rewrite
everything situation.
GregBeeley: 02/05 -- @Dan - by Responsive I don't think they're not talking about speed - they're talking about
changing the view layout based on whether the device is a phone, tablet, or laptop.
Recommendation Level (0=worst, 10=best) and Thoughts
Kurt Symanzik, rank 10: I rank this high because it is making an existing, and obviously useful, website even
better. Writing responsive websites are a valuable knowledge/skill that student programmers would benefit from
being exposed to. For several years now the emphasis has been on mobile first development and this project aligns
well with that idea. Naturally, this project is a better fit for the students that have a bent toward website design.
Contents
1 Submitter Information
2 Project Proposal
2.1 Security Policy Prover
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Greg Beeley
Timezone: US-Mountain
Organization: LightSys
Website: LightSys.org
Location: Colorado Springs, CO, USA
Email: Greg.Beeley@LightSys.org
Skype: gbeeley
Phone: 4045309797
Other Contact: Hangouts: gregbeeley@gmail.com
Submitted On: 25 Jan 2017 16:34
Project Proposal
Security Policy Prover
The Centrallix application platform that underlies the Kardia missions administrative system has an in-
development declarative security policy system for controlling access to objects. This project is for a program to
demonstrate that the policy doesn't have certain types of security holes.
Languages/Tools: C or C++
Can Dev on Mac: Y
Can Dev on Linux: Y
Can Dev on Windows: Y
Security Classification: SEC3 - Public
Can Be Used In Promo Materials: Y
Security holes are often caused by security misconfigurations. LightSys has a missions software system called
Kardia, which runs on top of a browser-based application platform/framework called Centrallix. LightSys is
encouraging users of the Kardia software to write add-on modules to the system and potentially add other
customizations, but we would like a way for clients to have some confidence that their work is done properly and
does not compromise the security of their data.
This project will be a command-line application, written in C or C++ under Linux, to take as input a set of security
policy files (*.pol), loading them into memory via a provided parsing library. The program will then either prompt
the user for a truth statement or take the truth statement as a command line parameter, and will determine whether
or not the policy guarantees the statement to be true for all current and/or potential objects in the collection
managed by the Centrallix application platform.
Security policy files consist of a set of rules for data access, controlling seven different types of access: Observe,
Read, Write, Create, Delete, Exec, and Noexec. The rules control which "subjects" (users, or users acting in a
particular role) can do which types of access on "objects" (files, database rows, database fields, components,
applications, and so forth). A common "test" for a security policy to pass is whether the policy allows users to
"execute" their own files, in other words whether a user can run their own custom program. A user running their
own program is a common method of exploiting weaknesses in a system, so security hardening often specifically
addresses that particular issue. In this case, then, the security policy prover would be asked if it is possible for a
particular user (or group of users) to end up with an object that is both writable and executable by their user
account.
This project, taken as a whole, is much larger in scope than Code-a-Thon would permit. So this project is broken
down into phases to allow completion of a useful program during Code-a-Thon.
Aspect 1: Creation of the utility to load the security policy files, with all file inclusions, and to print out the policy
on-screen. A library, usable from C or C++, will be provided to parse the policy files into in-memory data
structures.
Aspect 2: Ability to connect to the running Centrallix server, and using JSON-REST, retrieve lists of objects in a
"collection". The Centrallix platform organizes data (including database data) into "files" and "directories", using a
filesystem type metaphor for access to all data. This maps easily into JSON-REST. This will allow the policy
prover to obtain a current list of objects.
Aspect 3: Checking the security policy files to answer the pre-defined question of what objects a specified user
(subject) has a specified type of access to (Write, Read, etc.)
Aspect 4: Checking the security policy files to answer the pre-defined question of whether there are any current
objects that a user can have both Write and Exec access to.
Aspect 5: Checking the security policy to answer the pre-defined question of whether it is possible for the user to
use any current objects, or create objects, or modify or delete objects, in order to Exec an object that is or was
under the user's Write or Create control.
Aspect 6: Checking the security policy to answer a user-supplied question, such as "UserX and Write" or "UserY
and Read and /apps/kardia/*" or similar.
DanDennison: 02/05 Rank 8 -- This seems to be a black-box policy evaluation tool. It might also be useful to hook
into the security libraries directly and spec a white-box version as well that can evaluate the policies at startup or
refresh, and throw errors if the test-cases fail. In any case, the length of the project suggests that students might not
find it rewarding to only do a piece of a larger system. Our ultimate goal should be motivating students to get into
missions technology, and jumping into the weeds might not do that. Still overall, this isn't a bad idea, and a student
with a strong compilers background might find it fun :)
Contents
1 Submitter Information
2 Project Proposal
2.1 Kardia Website Redesign
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Greg Beeley
Timezone: US-Mountain
Organization: LightSys
Website: www.LightSys.org
Location: Colorado/USA
Email: greg.beeley@lightsys.org
Skype: gbeeley
Phone: 4045309797
Other Contact: Hangouts: gregbeeley@gmail.com
Submitted On: 07 Feb 2017 12:54
Project Proposal
Kardia Website Redesign
Kardia is a software suite for missionary sending offices, and includes modules for finance, donor, CRM, mailings,
and more. The website for Kardia however is quite outdated. This project is primarily a web and graphics design
project to bring a fresh design to the Kardia website.
The Kardia website is presently hosted at http://kardia.sourceforge.net. We will be obtaining a domain for this
website and hosting it on our own systems.
Currently, there are just seven pages, with a mild amount of PHP functionality. The site is mostly just HTML and
CSS.
As we move towards a Kardia 1.0 "Aspen" release this year, we'd like to refresh and update the website to be more
modern looking. We can provide some images and graphics to get the team started.
Technologies: We do not want to use a content management system like Wordpress or Drupal, but instead simple
HTML, CSS, as well as coding in PHP and JavaScript where useful. For images, all newly created image artwork
other than photographs should be in SVG format. This format allows the page to continue to look nice when it is
scaled (mobile devices, or for accessibility reasons).
The website should have some basic responsive functionality, i.e. dynamically adapting to different display
resolutions and pixel densities, for example looking nice on a PC/laptop, table, or phone.
Participants will need to know about how to code in PHP securely, though not much PHP will be required for this
project. We will provide a quick reference sheet on this topic.
Participants will need graphics design / web design skills on their team.
Contents
1 Submitter Information
2 Project Proposal
2.1 Distributed Praise & Worship for a Virtual Community
3 Submitter Agreed To / Can Help With
4 Estimated Coder-Hours and Capabilities Needed (by design reviewers)
5 Additional Business Requirements (by design reviewers)
6 Design Discussion (by design reviewers)
7 Recommendation Level (0=worst, 10=best) and Thoughts
Submitter Information
Name: Greg Beeley
Timezone: US-Mountain
Organization: LightSys
Website: www.LightSys.org
Location: USA/Colorado
Email: greg.beeley@lightsys.org
Skype: gbeeley
Phone: 4045309797
Other Contact: Hangouts: gregbeeley@gmail.com
Submitted On: 07 Feb 2017 13:16
Project Proposal
Distributed Praise & Worship for a Virtual Community
Oftentimes today, communities of believers are working together across a distance. However, there are many
aspects of "doing church" together that don't work as well across a distance. This is a brainstorming project to find
ways that believers can worship together in song, across a distance.
However, one thing notably difficult to do across a distance is to worship together in song. To get an idea of this
challenge, call a friend on Skype or Hangouts and try to sing a song together. You'll find that, due to the latency of
the connection, staying in sync in a song is very difficult, and oftentimes the "starkness" of audio across a
computer just doesn't have the same feel as sitting in a small group of people and singing together - sometimes you
can hear each other a little TOO well! This challenge is even greater when instruments are involved at more than
one location.
Latency is impossible to eliminate - fundamentally, the speed of sound and the speed of light itself become a
problems. When singing in person, physical distance in a room impacts singing -- sound travels at roughly 1 foot
per millisecond, so even a mere 40-50 foot distance will create an audible delay that causes problems trying to stay
together (round trip latency 80-100 ms). Online, delays are introduced by the speed of light (controlling how fast a
signal can propagate across a wire or fiber optic link) and by delays introduced by network routers. Typical internet
communication roundtrip latencies range from 80-120 ms domestically, and much higher internationally, as high as
300 ms.
Worshiping God with songs is a huge part of being a part of the body of Christ, is frequently mentioned in
Scripture, and even has an entire book of the Bible dedicated to it.
If participants wish to engage in coding to try out their ideas, they are welcome to use an open-source conferencing
software system like Apache OpenMeetings, which is written in Java and will allow for customizations. However,
OpenMeetings is a huge project and this probably requires a fair bit of work to set up the development
environment, so the participants would need to do this in advance of Code-a-Thon.
Participants are welcome to bring musical instruments to Code-a-Thon to experience first-hand how latency affects
playing together across a virtual connection.
We have some ideas about this, and we'd be glad to share those with whatever team is interested in picking this up.
But we also want to hear the creative ideas that the project team can brainstorm.