[Ssc-dev] SSCXfer 0.0.1 build

[Andrew Senior]

Sounds great Nathan. Will it be a distinct intent? Or built into ssc, or
just a separate app?
On Dec 11, 2011 11:28 AM, "Nathan of Guardian" <nathan at guardianproject.info>
wrote:

>
> Happy weekend everyone - we bought our first giant Christmas tree here
> in Brooklyn, and Eliza is sure excited to start decorating it. However,
> before those shenanigans begin, I thought I would push out my progress
> from last night.
>
> SSCXfer is my reduction of the Vidiom.mobi (http://vidiom.mobi/) app to
> be a focused, clean secure video uploader for YouTube and the
> self-hostable videobin.org software. The SSCXfer featureset is part of
> the agreed upon SOW for this phase of the SSC project.
>
> Vidiom is pretty fantastic, but is a bit too kitchen sink, and also
> included features like FTP and Facebook upload which I don't feel
> comfortable putting a "secure" stamp on. The YouTube upload code comes
> from the very interesting "YouTube Direct" project's Android client:
> http://code.google.com/p/ytd-android/ (Bryan/Sam - we should talk with
> Steve at YouTube about YouTube Direct).
>
> The basic user story for SSCXfer is:
>
> "Alice has sensitive video evidence of a human rights crime recorded on
> her smartphone and wants to upload it to YouTube, but is in a country
> where YouTube is often blocked, and always monitored."
>
> a more complex one is:
>
> "Bob is a trained human rights defender working in a restrictive region,
> using his smartphone to interview victims about their experiences, and
> he needs to safely offload the videos from his phone to a secure private
> site as soon as possible, without raising any flags in the internet
> monitor systems."
>
> In this case "secure" and "safe", mean it will 1) use HTTPS as
> available, 2) store any local data in SQLCipher, and 3) support upload
> over proxy servers, specifically Orbot's built-in SOCKS or HTTP proxy
> without requiring root. In addition, the uploader must support low-bw,
> high latency connections, and support resumeable uploads. Finally, since
> videobin.org can be self-hosted, it is possible that a server could be
> run by WITNESS or any organization on a Tor hidden service .onion
> address, or at least on their own, https site.
>
> At this point, I've implemented support for Orbot/Tor working by
> enabling HTTP proxying support in all the HTTP connection code, and it
> is working quite well for both uploads to YouTube and the default
> Videobin.org site instance. Resume and retry seem to work, but I have
> not done extensive testing. I think the most extreme test scenario is
> uploading over Tor over EDGE network, and then going up and down into
> the subway. We'll see how we do in that case.
>
> The existing UI model works well enough - it is a list of all video
> files found on the device, and an indicator of whether it has been
> uploaded or not, and if so, what the remote URL is. This URL can then be
> SMS'd, emailed, etc... and will also include the hash of the video for
> remote verification on download.
>
> APK Build:
>
> https://github.com/guardianproject/sscxfer/sscxfer-0.0.1-20111211.apk/qr_code
>
> code in master branch up here:
> https://github.com/guardianproject/sscxfer
>
> that's all for today!
>
> +n
> _______________________________________________
> Ssc-dev mailing list
>
> Post: Ssc-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>
> To Unsubscribe
>        Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>        Or visit:
> https://lists.mayfirst.org/mailman/options/ssc-dev/andrew.senior%40gmail.com
>
> You are subscribed as: andrew.senior at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20111211/84d8f3ec/attachment.htm>