[swb-public] README: Welcome & Initial Thoughts

Edward Bowles edward.bowles at riseup.net
Sun Jan 1 17:52:50 UTC 2017


> Anyway. Comment 1: trust.
> Josh makes a great point, this list will be surveiled by interested parties who do not have the same goals as this list. I would take this further and posit that the list / project will or has already been infiltrated by those parties.

Almost certainly, or at the very least we can't know for certain is *hasn't*, so we have to assume that it has.

> How do we as a group obtain /maintain and assure to *customers* that the people involved are trustworthy and have aligned objectives to those seeking assistance. I have seen groups 'crash and burn' as josh puts it on this aspect alone. This is especially true in the hacking scene where people either welcome or fear /despise the Intel services depending on the individual viewpoint.

I think this can be done by making sure the public face of the group is reputable, and relying on something of a web of trust from there - if nex says they're good, we can trust them! For things that are more sensitive, we probably have to make sure that the client is happy with whoever has been put on the job.  What makes them 'happy' will depend on the client, and...

> Who will undertake vetting of those people involved to provide those assurances and how, especially where typical vetting organisations, government, military, may be considered the 'opposition' and thus government vetted people may be seen as less trustworthy by nature of their affiliation?

...also what the SwB comrade is happy with divulging. There's going to have to be a pretty big amount of matchmaking between individuals trusted sufficiently to do the work, people with appropriate skillsets, and jobs that are willing to accept the person. We can't know in advance what level of assurance the group in need is happy with.

> Comment 2:safety
> Given the stakes involved, participants in this project could be individually, or collectively targetted both electronically and through other means. Maybe others on the list could highlight any physical threats to individuals that may exist as I'm no expert. How do we go about ensuring the safety of participants from state or other actors seeking to undo the group efforts? What legal support do we have, or can we put in place to protect volunteers from specific targetting?

I think the groups wanting to target us don't need to worry too much about legal protections, inasmuch as they will be either authorised to conduct the surveillance, interdiction, whatever, or they won't care about the law because they're criminals. Ultimately we need to practice what we preach and maintain good security hygiene.

> Comment 3: agreed objectives / politics.
> I suspect we've all expressed interest and willingness for different reasons, but with a generally agreed view that we would like to support freedom of speech and expression, support NGOs, the press and others in the face of growing intolerance. How do we go about defining who to support and who not to support, however? As an example I suspect everyone would support a request from MSF for help, however would that extend to other groups? What would happen if breitbart sought help from the group? Or maybe The Canary (left wing organisation)? What would happen if the White helmets sought help, or a Palestinian organisation? How do we protect the group against fracture along political and ethical lines? Who makes these decisions and what happens if the group finds itself on the "wrong side of history"?

No-one should ever be forced into doing something they don't want to do. People can express whatever views they want. All actions have consequences, including finding the pool of people willing to help you for free significantly diminished! If a group asks for help, and nobody qualified wants to help them, so be it. I suspect we'll be okay in terms of matching people to organisations/clients.

> I have no answers to these, but thought I'd open my thoughts for debate.

Not meant to be answers either, just my $0.02.

- eab
>> On 31 December 2016 19:06:01 GMT+00:00, Josh More <jmore at starmind.org> wrote:
>> If I might make a suggestion as to technologies and structure ...
>> I have seen several groups crash and burn because technology decisions were made too early in their development.  The choice of a technology both enables and restricts options, and some technologies will be more naturally suited to certain types of projects than others.
>> For example, I am currently doing a project in which I compare TAILS to "Security in a Box" by Tactical Tech / Frontline Defenders.  This is a project involving deep analysis and is fundamentally different from another project I've been doing which involves end-to-end anonymization bootstrapping documentation.  If done by a group, the former would benefit from a wiki-like notes-taking system coupled with a version control system.  The latter, however, would benefit from a group-writing solution, like Google Docs.
>> Since a documentation project is intended to be public in the end, there is little risk from using a cloud-based technology, and the efficiency advantages of such a technology could make the difference between success and failure.  However, other projects, like network assessment / training / on site consulting / pentesting / etc are private in nature and there may be significant ramifications to using such a public infrastructure.
>> I would suggest that the core group not focus so much on technology at this stage, but more on a way to safely toss "projects" out to the group, classified by criticality, estimated work effort, skillset and skill levels required, and overall risk level.  Then have recommended technical platform recommendations for these different project types.  As working groups form around specific projects, they can use more targeted technologies to choose an appropriate balance of both security and efficiency as deemed necessary for the group.
>> Such a system should also have a way to secure propose projects to the core group as the very existence of some projects could be a red flag in of themselves.
>> -Josh More
>>> On Fri, Dec 30, 2016 at 5:55 PM, Nex <lists at nex.sx> wrote:
>>> Hello everyone,
>>> Firstly, thanks to all those who subscribed to this list, and expressed
>>> interests in the project and volunteering your time. It is truly
>>> wonderful to see so much engagement.
>>> There is a lot to discuss and even more to figure out. SWB is intended
>>> to be as much of an open community as possible, and we welcome everybody
>>> to engage on this list and start discussing about what we can do
>>> collectively and how to properly organize the resources we are aggregating.
>>> The first step is to clarify the existing structure. At this moment SWB
>>> consists of a handful of people who have been working to bootstrap the
>>> project and that currently form the "core" group. This group is
>>> currently discussing the best strategies to both leverage the
>>> overwhelming number of offers of volunteering, as well as identifying
>>> the best ways forward to process incoming assistance requests. In the
>>> weeks to come, I hope we'll enrich the website, start providing some
>>> resources, and elaborate our objectives and strategies.
>>> As you can imagine, the work this community can undertake can require
>>> various levels of trust. For example, we need to make sure that a
>>> penetration test, or a forensic analysis, is performed by people that
>>> not only are competent but that can be trusted to not cause damage or
>>> otherwise abuse those we are trying to assist.
>>> Other activities instead, which are equally important, are more
>>> accessible to this broader community as they not entail the handling of
>>> private data or access to private systems of our "clients".
>>> Some examples of such activities could be:
>>> - The creation of software projects. For example an utility that
>>> monitors (and blocks?) access to webcam and microphone on a Windows
>>> computer, in order to prevent them from being abused in case of a
>>> compromise.
>>> - Perform spontaneous research to identify vulnerabilities in software
>>> commonly used in civil society space (e.g. messaging apps, CMS).
>>> - Perform spontaneous threat research to identify
>>> phishing/spearphishing/malware attacks that are seemingly targeting
>>> individuals or organizations working in civil society.
>>> - Creation and maintenance of a regular or irregular newsletter for NGOs
>>> to consume news and alerts on relevant security issues (e.g. new
>>> vulnerabilities in critical software, new attacks that are targeting
>>> civil society, etc.).
>>> - Creation of security guides and tutorials, or any other type of public
>>> content that is relevant to our objectives.
>>> - Answering generic technology and security questions from NGOs and
>>> members of civil society (for example on a dedicated public Discourse
>>> instance).
>>> ... and more.
>>> These are the types of projects and ideas that I invite you all to start
>>> thinking about and discuss further on this list.
>>> I imagine many of you aren't necessarily familiar with what kind of
>>> security issues do NGOs and civil society members face. This is actually
>>> one of the most critical problems we face, as these organizations aren't
>>> normally equipped to recognize attacks and security issues alone, due to
>>> a lack of adequate staff or technology.
>>> A good starting point is this list of reports I have compiled:
>>> https://github.com/botherder/targetedthreats/wiki/Reports
>>> I expect the next few months to be a period of stabilization, at the end
>>> of which we'll have a better idea of how many people and what time of
>>> resources and expertise we have aggregated.
>>> After that there will necessarily be a period to raise awareness and
>>> making people outside of our community know that we exist and are
>>> available. It will be critical to interface to existing human rights and
>>> digital rights organizations in order to establish relationships and
>>> cooperation.
>>> We are starting something from scratch, and that is never easy. It might
>>> take time to get it right, and we shouldn't be impatient.
>>> In the meantime, I look forward to the many conversations, and hopefully
>>> to the success of this initiative.
>>> All the best,
>>> /nex
>>> _______________________________________________
>>> swb-public mailing list
>>> swb-public at lists.securitywithoutborders.org
>>> https://lists.securitywithoutborders.org/mailman/listinfo/swb-public
>> swb-public mailing list
>> swb-public at lists.securitywithoutborders.org
>> https://lists.securitywithoutborders.org/mailman/listinfo/swb-public
> _______________________________________________
> swb-public mailing list
> swb-public at lists.securitywithoutborders.org
> https://lists.securitywithoutborders.org/mailman/listinfo/swb-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.securitywithoutborders.org/pipermail/swb-public/attachments/20170101/7ca43469/attachment-0001.html>

More information about the swb-public mailing list