[Ssc-dev] Authentication, Authorization and Architecture

Harlo Holmes harlo.holmes at gmail.com
Fri Mar 8 11:56:18 EST 2013


sorry to be so silent on this thread. I have a lot of thoughts that I'd
like to add but due to travel I haven't gotten much opportunity to type.

Hans is right about modularity; this is why Barbra's api development
efforts are key. however, we are going to have to limit it to functions
that we can reuse across different builds of the product. iba-specific
stuff that is not relevant to the project's core functionality should (for
the most part) reside outside of the api.

I also believe that lee's authentication scheme is important, but we should
be certain that the solution is applicable to other builds for other
clients.

more to follow once I get to a computer...
On Mar 8, 2013 11:26 AM, "barbra" <blmack at gmail.com> wrote:

> I think you are right.
>
> However, this is a research implementation (and a great, really pretty far
> along one I feel after reviewing global leaks). So, while it won't be
> impossible to modularize all of the functionality, it is pretty tightly
> intertwined right now, and not "kit"-like at all. This whole discussion
> started with a line of thinking that if we really wanted to begin to
> support these different levels (and even just different apps submitting
> content in), and we really wanted to be more of a flexible kit/framework we
> need to refactor with an API approach.
>
> While we don't need the NSA-level security that Lee and I were discussing
> just yet (our motives were good :-) ), I do stand by the fact that an API
> really is something needed in the near-term if we want to be flexible/kit
> like. And I think it is a smart choice with big gains short-term and
> long-term, even for the work for GLSP and IBA. Though, clearly this will
> have to be for InformaCam 1.5/2.0.
>
> -barbra
>
> On Fri, Mar 8, 2013 at 11:07 AM, Hans of Guardian <
> hans at guardianproject.info> wrote:
>
>>
>> Maybe I'm sounding like a broken record, but I think that the 'framework'
>> approach would apply very well here, and give us the different consumer/pro
>> levels.  I think it will also help get InformaCam to 1.0 faster.  In a
>> quick overview, it would be a collection of frameworks something like this:
>>
>> phone side
>> * phone meta data gatherer
>> * image/video/audio redaction
>> * image/video/audio data bundler, for putting data into files
>> * camera fingerprinter
>> * trickle sync uploader
>> * OnionKit
>> * IOCipher/SQLCipher
>> * content signing/encrypting (APG, GnuPG, etc)
>>
>> server side (I don't know this side as well)
>> * trickle sync receiver
>> * meta data viewer
>> * upload verifier
>> * etc.
>>
>> Thinking like this gets to 1.0 faster because it means that we can ignore
>> lots of feature requests and use cases for now, since the needed frameworks
>> can be plugged in later.  Also if its presented as a "kit" for building
>> custom apps (e.g. IBA, GLSP, etc) rather than the one app that does
>> everything, its already close to a good 1.0.
>>
>> .hc
>>
>> On Mar 8, 2013, at 12:03 AM, Nathan of Guardian wrote:
>>
>> > Also one other thing in general that I will write more about late, but
>> > is the idea of "shipping early and often".
>> >
>> > We have released 11+ versions of Orbot, Orweb and Gibberbot, because I
>> > am very focused on shipping releases of products when they are good
>> > enough, and them improving them over time. I have a real distaste for
>> > feature creep that causes our goal line to keep moving, product
>> > complexity to increase, and complexity to increase, without ever having
>> > something in use by real people.
>> >
>> > At this point, we have been working on InformaCam proper for about a
>> > year, and we need to get a solid v1 release out there in a bad way. I
>> > intend to keep an obsessive focus on making that happen. I do intent to
>> > be aggressive about that goal, and will not apologize for it, because
>> > the sooner we get there, the better it is for us all.
>> >
>> > +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/harlo.holmes%40gmail.com
>
> You are subscribed as: harlo.holmes at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20130308/6ad7fef7/attachment.html>


More information about the Ssc-dev mailing list