[Ssc-dev] Authentication, Authorization and Architecture

[Harlo Holmes]

also re: authentication/authorization, what did we decide about something
like Mozilla persona?
On Mar 8, 2013 11:56 AM, "Harlo Holmes" <harlo.holmes at gmail.com> wrote:

> 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/6769446c/attachment.html>