faq.html

---
layout: default
---

<div class="faq">

  <section class="faq__toc">
    <h1 id="toc">Frequently Asked Questions</h1>
    <ol>
      <li><a href="#overview">About the project</a>
       </li>
      <li><a href="#relation-to-thoughtworks-and-leap">Relation to ThoughtWorks and LEAP</a>
      </li>
      <li><a href="#where-do-i-get-it">Using Pixelated</a>
      </li>
      <li><a href="#provider">Hosting Pixelated for your users and customers</a>
      </li>
      <li><a href="#how-can-i-keep-myself-safe">How much privacy does Pixelated provide?</a>
      </li>
      <li><a href="#sounds-good-how-can-i-contribute">Sounds good! How can I contribute?</a>
      </li>
      <li><a href="#technical-architecture">Technical architecture</a>
      </li>
      <li><a href="#contact-the-project">Contact the project team</a></li>
    </ol>
  </section>

  <section>
    <h1 id="overview">About the project</h1>

    <h2>What is Pixelated?</h2>

		<p>Pixelated is a software distribution. It gives organizations the means to host an email solution that provides a modern, compelling web interface as well as privacy through proven PGP encryption. With Pixelated, using encryption no longer involves complicated setup procedures or a confusing user experience.</p>

    <h2 id="What-problems-does-pixelated-address">What problems does Pixelated address?</h2>

    <p>Email communication is subject to mass dragnet surveillance. The reason dragnet surveillance exists in its current form is because it is so cheap and easy to do. In transit email is often not protected and can be read in full by anyone with access to the network, at any of the many network nodes the email passes through. The problem is made worse because many individuals and organizations currently use proprietary software as a service (SaaS) solutions like Gmail or Outlook.com, which concentrates emails in a few places. Having access to just a handful of the major email services provides plain text access to most of the email conversations in a country, readily readable and searchable.</p>
    <p>Both problems can be solved with decentralization and encryption. If we can achieve widespread use of encrypted email it will be too costly and economically unreasonable to routinely intercept the majority of email on the internet. This does not mean that a motivated adversary will have no way to intercept specifically targeted communication, but it should end mass surveillance on the scale we have to endure today.</p>
		<p>Widespread use of encryption will also show that it is absurd to assume that only people with "something to hide" use encryption, an argument that we often see today as justification for attempting to outlaw privacy preserving communication.</p>

    <h2>What are the key features of Pixelated?</h2>
    <ul>
      <li>An organization setup that requires no software to be installed by the end user</li>
      <li>Compelling web-based user interface with fast search and tagging</li>
      <li>Email encryption with maximum interoperability with existing solutions for secure email, i.e. use of GPG/PGP, SMTP/TLS, HKS</li>
      <li>Fully scripted installation of the complete solution</li>
      <li>Built on the LEAP platform (www.leap.se)</li>
      <li>Source code available on Github under AGPL license</li>
    </ul>

    <h2>In what context is Pixelated being developed? Which principles are non-negotiable?</h2>
    <ul>
      <li>We aim for mass adoption (not intended for individuals that are targeted and need special protection)</li>
      <li>We write Free and Open Source Software and make sure the code and modifications must remain open</li>
      <li>We operate as a community-driven project (not a ThoughtWorks product that has source code on Github)</li>
      <li>We deliver software that interested parties can run (not services that people can use to send and receive email)</li>
    </ul>
  </section>

  <hr>

  <section>
    <h1 id="relation-to-thoughtworks-and-leap">Relation to ThoughtWorks and LEAP</h1>

    <h2>Why is ThoughtWorks investing in Pixelated?</h2>
    <p><a href="https://www.thoughtworks.com/">ThoughtWorks</a> is a software company and a community of passionate, purpose-led individuals. ThoughtWorks helps its clients to address their toughest challenges with empowering technology and disruptive thinking, but it also seeks to revolutionize the IT industry and to create positive social change. ThoughtWorks has a history of seeding the development of genre-defining open source software, e.g. <a href="https://en.wikipedia.org/wiki/CruiseControl" target="_blank">CruiseControl</a> and <a href="https://en.wikipedia.org/wiki/Selenium_%28software%29" target="_blank">Selenium</a>, and continues to invest in open source software that has a positive impact on the world, e.g. the <a href="http://www.bahmni.org/" target="_blank">Bahmni</a> software distribution for hospitals.</p>
    <p>Like the projects listed above, Pixelated is not a ThoughtWorks product and we&#39;re not in it for the money. We hope to establish a vibrant community around a great project that can thrive on its own. We want to see Pixelated succeed simply because we think it is the right thing to do.</p>

    <h2>What is LEAP?</h2>
    <p>LEAP is a not-for-profit organisation dedicated to giving all internet users access to secure communication. For more details please refer to <a href="https://leap.se/en" target="_blank">LEAP&#39;s project homepage</a>.</p>
    <p>Pixelated is built on the LEAP platform and has counted on a lot of help from the LEAP team.</p>

  </section>

  <hr>

  <section>
    <h1 id="where-do-i-get-it">Using Pixelated</h1>

    <h2>Who should use Pixelated?</h2>
    <p>To significantly counter mass surveillance, Pixelated, along with compatible solutions and derivatives, needs mass adoption. Therefore the target user is anyone who wants to use web-based email. The target users do not have to have a special interest in privacy or mass surveillance. Pixelated should not make privacy a trade-off with convenience. Users should simply want a great web-based email solution, which Pixelated delivers while also offering seamless and effortless use of encryption. In a nutshell: Pixelated is built for those who are not focused on encryption and privacy.</p>

    <h2>Where can I sign up for a Pixelated account?</h2>
		<p>As mentioned before, the Pixelated project offers software. We hope that many organisations will install Pixelated for their own users. This could be companies and organisations providing mail services today, it can be internet service providers and hosting companies.</p>
		<p>Once Pixelated has matured enough and has stable installations we will provide a list of third party services. For now, the best bet is to download the software distribution and run it on your own server.</p>
  </section>

    <h2>Why is ThoughtWorks not running Pixelated as a service that people can sign up to and use?</h2>
    <p>ThoughtWorks sees its role as supporting the development of the product and the creation of a community around it. Running a Pixelated service does not make sense for several reasons:</p>
    <ul>
      <li>Centralisation is a problem; therefore, it would defeat the entire project's purpose to create a centralised (default) Pixelated service.</li>
      <li>ThoughtWorks, Inc. is a US-based company and subject to US jurisdiction, which includes the PATRIOT Act of 2001. ThoughtWorks would face problems similar to the problems that Lavabit faced.
			<li>Providing email services comes with other legal obligations in many other jurisdictions. This is complexity ThoughtWorks does not have the means to deal with.</li>
    </ul>
    <p>We can, however, provide support to organisations wanting to host instances of Pixelated themselves.</p>

  <hr>

  <section>
		<h1 id="provider">Hosting Pixelated for your users and customers</h1>

    <h2>Who can offer Pixelated?</h2>
    <p>We hope to see widespread deployment of Pixelated at mail providers, ISPs, and hosting providers. We believe this group is crucial to achieve widespread adoption of Pixelated.</p>
    <p>Some mail providers may consider Pixelated a central service offering for their own customers/users. We believe, however, that most are going to see Pixelated merely as a feature of their own offerings. In this scenario, the compelling user experience of Pixelated combined with its privacy features would provide a competitive advantage for companies in an industry in which players struggle to differentiate themselves from the competition. It is conceivable that there will be a “white-label” version of Pixelated allowing mail providers to customise the user experience to match their own visual identity.</p>

    <h2>Is there a market for Pixelated?</h2>
    <p>A group we are referring to as &ldquo;tech-savvy anti-surveillance-minded individuals&rdquo; are the initial market for Pixelated. We have, through structured interviews and casual conversation, understood that users who are tech-savvy without having a clear interest in mass surveillance are, at least at this stage, not excited about Pixelated. This may change once we have delivered a user experience that is appealing in its own right. There is also evidence that an interest in privacy (which can be for very different reasons than being opposed to mass surveillance) does not guarantee an interest in Pixelated. Thus, the focus for now is on those with an interest in preventing mass surveillance.</p>
    <p>The crowdfunding campaign for Mailpile has shown that there is not only demand but also a willingness to support a product in this space. In September 2013 the Mailpile team raised $167k, much more than their $100k goal, from more than 3000 individual backers. These backers are the &ldquo;tech-savvy, anti-surveillance-minded individuals&rdquo; we want to target initially, to test our ideas and to bootstrap community building. We have to be careful not to design the product too much for this small group because their needs are not fully representative of our broader target group.</p>
		<p>In the long run we believe that a lot of people will want to use Pixelated. If, and that is our hypothesis, people are faced with two email solutions, on the one hand a typical email solution as we know it today and on the other hand a web-based email solution that is at least as good as the other solutions but also provides privacy without added complexity and complications (Pixelated), they will opt for the one that can offer greater privacy. We believe that the Snowden revelations have not convinced enough people to make the compromises that are required today to use PGP, but that if there are no compromises to be made, the knowledge about mass surveillance will make people choose a privacy-preserving solution.</p>

    <h2>I am a provider and want to offer Pixelated. Who do I talk to?</h1>
    <p>Please contact us at <a href="mailto:pixelated-team@thoughtworks.com" target="_blank">pixelated-team@thoughtworks.com</a>. We can help you get started and answer your questions there.</p>
  </section>

  <hr>

  <section>
    <h1 id="how-can-i-keep-myself-safe">How much privacy does Pixelated provide?</h1>

    <p>If you&#39;re wondering about how to protect your privacy, this is the paragraph you&#39;ll find most interesting. Here, you&#39;ll find everything you want to know about what decisions we made to keep you safe and secure while using your Pixelated provider of choice, and also where the limits are.</p>

    <h2>Is this yet another NSA-proof email encryption initiative?</h2>
    <p>No. Even though Pixelated largely relies on similar technologies as other email-encryption projects, we&#39;re orchestrating them very differently, focused on ease-of-use. As we explained above, Pixelated&#39;s aim is to make pervasive dragnet surveillance economically unreasonable.</p>
    <p>If you&#39;re under targeted surveillance by an intelligence service, you will need to deploy extensive security measures to the point where you can detect and avert intrusion by so-called nation-state adversaries, i.e. very powerful organizations with vast resources and deep knowledge. At this point, using individual solutions while leaving other intrusion paths open will not protect you. In such cases, Pixelated itself will not protect you and we strongly recommend you seek council of experienced IT security experts.</p>
    <p>But: That does not mean you shouldn&#39;t be able to keep yourself safe from other kinds of malicious folks trying to get into your inbox. Read more on our threat model later.</p>

    <h2>Where and how does the crypto happen? Where is my private key stored?</h2>
    <p>We run the encryption and decryption routines on the Pixelated server. To be able to do this the keys must be available on the server. Many technical folks out there will tell you that this is bad, and in certain cases they may be right. However, in the end it all boils down to the threat model. In the next answer we explain why using a server-based approach is actually a reasonable idea in our case.</p>

    <h2>My friends say that my private key should stay on my trusted device, why do you store it on the server ?</h2>
    <p>Tools to encrypt email have been around for years, one of the most-used technologies today is PGP, which was first released in 1991. Email itself is such a central part of the Internet and has such a rich ecosystem that it is near impossible to replace with something else. (Remember Google Wave?) Despite all that, encrypted email has never taken off at a large scale because it is too difficult to use.</p>
		<p>Having been at many crypto parties we have experienced bewildered looks when users are confronted with questions about key sizes expressed in bits, when seeing prompts to move the mouse to create <i>entropy</i>, when they are asked to read out <i>key fingerprints</i> to each other to verify that they really have the right key. We have also seen countless examples of private keys being lost, of course, in many cases by users who have no idea what a <i>revocation certificate</i> is, never mind having created one. Then there is the issue of using multiple devices... All of this is so intimidating that most people chose convenience over privacy, convincing themselves that they have nothing to hide and nobody is interested in them anyway.</p>
		<p>The Pixelated team has made complex choices surrounding cryptography so you don&#39;t have to. It provides a solid setup without bothering the users. And, yes, it is correct that whoever operates the Pixelated server you use can intercept your mail if they are willing to put in some work. However, consider the alternatives: would you rather trust the people who operate the server, people who can actively choose, or would you, because you're reverting to unencrypted email, want to trust any number of parties that you can't chose and don't even know about? We feel that trusting one group of people is vastly preferrable. If you feel you can't trust anyone then your friends are right and you should keep the private keys only on devices you have complete control over and can be sure nobody can tamper with, and make backups, encrypted of course.</p>

    <h2>How much do I need to trust my Pixelated provider? Can an attacker read my mails? Is there a difference to Lavabit?</h2>
    <p>In order to answer this, let&#39;s take a step-by-step look at what happens from the time you log into Pixelated and when an email reaches the server to when you see it in your browser.</p>
    <ul>
      <li>When you create your Pixelated account for the first time, Pixelated creates an encryption key on your behalf. This encryption key itself is locked with the password you choose.</li>
      <li>When an incoming email reaches the server, it is encrypted with your key (metadata and all) and stored in the server&#39;s database</li>
      <li>When you login to Pixelated, your encryption key is unlocked with the password you supply.</li>
      <li>When you view the email, it is being decrypted on-the-fly and displayed your browser.</li>
    </ul>
    <p>So now let&#39;s think about what that does and does not protect you against:</p>
    <ul>
      <li>Your emails are encrypted at rest on the provider&#39;s server. If your provider is being hacked, the attacker can&#39;t get to the contents of your inbox.</li>
      <li>Your emails are sent encrypted, so if somebody listens to traffic on the wire, they won't see the content of your email, but they will see who the email is for, the subject, and other information about the message. (This is a flaw of the protocol, not ours. Sorry.)</li>
      <li>Your encryption happens on the server, so if an attacker manipulates the server to record everything happening on it, they could see the contents of your inbox. This attack could be conducted mostly by resourceful adversaries like intelligence services
        and other nation-states-level attackers. It is an attack on a much greater time scale, which makes it harder to pull off without being detected, and requires more funds and sophistication.</li>
    </ul>
    <p>Pixelated has similarities to Lavabit&#39;s design and also its shortcomings. In detail here, an email provider has three main adversaries:</p>
    <ul>
      <li>An administrator with access to the server.</li>
      <li>An attacker who can get access to the server.</li>
      <li>An attacker who can intercept the communication to the server.</li>
    </ul>
    <p>Pixelated shares these vulnerabilities, just like a conventional (unencrypted) email service, despite the use of cryptography. The security is anchored to the user-supplied password. And if the operator of the server or an attacker manages to modify the code for Pixelated they could gain access to the password.</p>
    <p>So there is a legitimate question: Is it this worth the trouble at all? Yes, it is, for two reasons.</p>
    <p>Reason #1: Just because something does not give you perfect security, that doesn&#39;t mean there&#39;s no value to it. Email is a distributed system. You can use your Pixelated account to exchange encrypted emails with somebody who uses other email encryption based on PGP, e.g. using Apple Mail with the GPG Suite, or Thunderbird with Enigmail. In this use case you know you don't have to trust anyone other than the operator of your Pixelated server.</p>
    <p>Reason #2: If you don&#39;t want to trust any email provider, Pixelated makes it easy to set up your own email service!</p>

    <h2>What about activists and activist organisations?</h2>
    <p>Privacy, mass surveillance, and activism are often considered together. Activists have a need for strong privacy (see <a href="https://www.tbray.org/ongoing/When/201x/2014/05/26/Privacy-Levels" target="_blank">Tim Bray&#39;s article on privacy levels</a>    for a good discussion of strong vs common privacy) but those who have been specifically targeted have needs that go far beyond what is needed to counter mass surveillance. Thus, a solution that can help an activist defend himself/herself against sustained, targeted surveillance is likely to be so involved that it would be unusable for the majority of email users. We do not think it is possible to build a solution that can be widely used as a regular email solution while also providing the features necessary to counter targeted surveillance. Having said that, we are building Pixelated in a way that should allow to derive activist-oriented products from it.</p>
  </section>

  <hr>

  <section>
    <h1 id="sounds-good-how-can-i-contribute">Sounds good! How can I contribute?</h1>

    <p>We know that it can still be a bit tough to set up your Pixelated environment and find an issue that&#39;s a good fit for your skills, and we&#39;re always looking for ways to lower the entry barrier for new contributors. If you hit any roadblock, you have good ideas, or just want to share your thoughts about onboarding etc., contact us at <a href="mailto:pixelated-team@thoughtworks.com" target="_blank">pixelated-team@thoughtworks.com</a> so we can resolve these issues for you and everyone else.
    <p>These principles shall guide you on your way to help build a strong ecosystem with active and enthusiastic contributors.<p>
    <ul>
      <li>There is no walled-off "core team". If you use or work on our code, you are welcome to the team!</li>
      <li>Community voice is achieved after some non-trivial commits, activity in the communication channels, expression of interest, and following the Code of Conduct.</li>
      <li>If you sign up for a feature, you'll become its caretaker in the sense that you'll become the go-to-person.</li>
      <li>Should you lose interest, that's ok, too. Caretaking is not an obligation, and this should encourage people to take care, even if for a short time.</li>
      <li>If you accept your role as a caretaker over a specific part of the code, you'll have the final say. Simple reason therefore is that dog food shall be eaten. An active contributor shall be heard, and if a contributor finds they are not using Pixelated in the real-world, they should reconsider their involvement with the project. Or, better yet, find out if there's a specific reason for it and bring it to the community's attention so that we can fix it for everyone else, too.</li>
    </ul>

    <h2>Where do I start?</h2>
    <h3>Non-code contributions</h3>
    <p>A frequently overlooked fact is non-code issues that need work. Examples include, but are not limited to:</p>
    <ul>
      <li>Filtering and tagging of incoming Github issues</li>
      <li>Work related to internationalization</li>
      <li>Organization of events and community management</li>
      <li>Answer usage questions, e.g. on stack overflow</li>
      <li>Add feature requests with exemplary use cases</li>
      <li>Add steps to reproduce to bug reports</li>
      <li>Close issues that qualify for closing (no activity in a while, insufficient/missing/imprecise description, etc.)</li>
    </ul>
    <p>These kind of contributions are immensely helpful to us!</p>
    <h3>Code contributions</h3>
    <p>We&#39;re constantly trying to identify issues that might be a good fit for new contributors. Please keep in mind that this is an active project and things get moved around, refactored, etc. We are aware that most contributors have (at best) only a handful of hours to spare, so there&#39;s a risk that what you worked on a couple of days ago might be a pain to merge a week or two later. Despite all of that, we&#39;re trying to spot issues that are located a bit outside of the noisy areas and self-contained and a good fit to get you into the codebase quickly.</p>
    <p>If you have a good idea or if you want to fix your pet peeve, please figure out the component in which your pet peeve is implemented, using the technical architecture sketch below. Browse that component&#39;s Github issues for related bugs.</p>
    <ul>
      <li>If you know JavaScript or HTML/CSS, you can contribute to the front-end portion of the <a href="#pixelated-user-agent" target="_self">Pixelated User-Agent</a>.</li>
      <li>If you know Python, you can contribute to the server portion of the <a href="#pixelated-user-agent" target="_self">Pixelated User-Agent</a>.</li>
      <li>If you know Puppet, you can contribute to the <a href="#pixelated-puppet-module" target="_self">Pixelated Puppet Module</a>.</li>
    </ul>
    <p>We're standing on the shoulders of giants, so apart from contributing directly, you can also contribute the <a href="#leap-platform" target="_self">LEAP project</a>, which we build upon.</p>

    <h2>Where do I submit my contribution?</h2>
    <p>Awesome! You&#39;ve finished working on your first contribution!</p>
    <p>In order to get your code into the master branch, there are only a few more step to wrap things up:</p>
    <ol>
      <li>Make sure your code conforms to our code styleguide.</li>
      <li>Make sure everything&#39;s tested.</li>
      <li>Make sure your code reads well and is documented where necessary.</li>
      <li>Make sure you&#39;ve used meaningful commit messages.</li>
      <li>Make a Pull Request.</li>
      <li>Check whether our CI server has successfully built your Pull Request.</li>
    </ol>
    <p>All systems go? Congratulations! Updated installations should now have your changes!</p>

    <h2>I think I might be able to hack together a quick-and-dirty lo-fi solution for the issue I’m working with... what do I do?</h2>
    <p>Do it the easy way first, and submit a pull request as a "work in progress" as soon as you have a quick-and-dirty solution (or even an unfinished solution) - that means you can get feedback from the other developers about whether you’re heading in the right direction sooner rather than later. Include "WIP" (work in progress) in the description of your pull request and ask for review, or feedback on anything specific.</p>



    <h2 id="code-of-conduct">Code of Conduct</h2>
    <p>This code of conduct outlines our expectations for participants within the Pixelated community, as well as steps to reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all and expect our code of conduct to be honored. Anyone who violates this code of conduct may be banned from the community.</p>
    <p>Our open source community strives to:</p>
    <ul>
      <li><strong>Be friendly and patient</strong>.</li>
      <li><strong>Be welcoming</strong>: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status,
        social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.</li>
      <li><strong>Be considerate</strong>: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions.
        Remember that we&#39;re a world-wide community, so you might not be communicating in someone else&#39;s primary language.</li>
      <li><strong>Be respectful</strong>: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal
        attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.</li>
      <li><strong>Be careful in the words that we choose</strong>: we are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren&#39;t
        acceptable.
      </li>
      <li><strong>Try to understand why we disagree</strong>: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of our
        community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is
        human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.</li>
    </ul>
    <h3>Definitions</h3>
    <p>Harassment includes, but is not limited to:</p>
    <ul>
      <li>Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neuro(a)typicality, physical appearance, body size, race, age, regional discrimination, political or religious affiliation</li>
      <li>Unwelcome comments regarding a person’s lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment</li>
      <li>Deliberate misgendering. This includes deadnaming or persistently using a pronoun that does not correctly reflect a person&#39;s gender identity. You must address people by the name they give you when not addressing them by their username or handle</li>
      <li>Physical contact and simulated physical contact (eg, textual descriptions like “hug” or “backrub”) without consent or after a request to stop</li>
      <li>Threats of violence, both physical and psychological</li>
      <li>Incitement of violence towards any individual, including encouraging a person to commit suicide or to engage in self-harm</li>
      <li>Deliberate intimidation</li>
      <li>Stalking or following</li>
      <li>Harassing photography or recording, including logging online activity for harassment purposes</li>
      <li>Sustained disruption of discussion</li>
      <li>Unwelcome sexual attention, including gratuitous or off-topic sexual images or behaviour</li>
      <li>Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy with others</li>
      <li>Continued one-on-one communication after requests to cease</li>
      <li>Deliberate “outing” of any aspect of a person’s identity without their consent except as necessary to protect others from intentional abuse</li>
      <li>Publication of non-harassing private communication</li>
    </ul>
    <p>Please keep in mind that this open source community will always prioritize safety over comfort.</p>
    <h3>Diversity Statement</h3>
    <p>We encourage everyone to participate and are committed to building a community for all. Although we will fail at times, we seek to treat everyone both as fairly and equally as possible. Whenever a participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong.</p>
    <p>Although this list cannot be exhaustive, we explicitly honor diversity in age, gender, gender identity or expression, culture, ethnicity, language, national origin, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, and technical ability. We will not tolerate discrimination based on any of the protected characteristics above, including participants with disabilities.</p>
    <h3>Reporting Issues</h3>
    <p>If you experience or witness unacceptable behavior—or have any other concerns—please report it by contacting us via <a target="_blank" href="mailto:pixelated-team@thoughtworks.com">pixelated-team@thoughtworks.com</a>. All reports will be handled with discretion. In your report please include:</p>
    <ul>
      <li>Your contact information.</li>
      <li>Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or Github discussion), please include a link.</li>
      <li>Any additional information that may be helpful.</li>
      <li>After filing a report, a representative will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. If the person who is harassing you is part of the response team, they will recuse themselves from handling your incident. If the complaint originates from a member of the response team, it will be handled by a different member of the response team. We will respect confidentiality requests for the purpose of protecting victims of abuse.
      </li>
    </ul>
    <p>This code of conduct is based on the <a target="_blank" href="https://github.com/todogroup/opencodeofconduct">Open Code of Conduct v1.0</a> from the <a target="_blank" href="http://todogroup.org/">TODOGroup</a>.</p>
  </section>

  <hr>

  <section>
    <h1 id="technical-architecture">Technical architecture</h1>

    <img src="/assets/images/pixelated-user-agent.png">

    <p>A Pixelated instance consists of these components:</p>
    <ul>
      <li>Pixelated User-Agent</li>
      <li>Soledad</li>
      <li>One/Many LEAP instance/-s</li>
    </ul>
    <p>In order to give you a rough idea how Pixelated works, let&#39;s look at how these components play together.</p>

    <h2 id="pixelated-user-agent">Pixelated User-Agent</h2>
    <p>Languages: Python, Javascript/HTML/CSS</p>
    <p><a target="_blank" href="https://github.com/pixelated/pixelated-user-agent">Repository on Github</a></p>
    <p><a target="_blank" href="https://github.com/pixelated/pixelated-user-agent/issues?q=is%3Aopen+no%3Aassignee+label%3ABeginners">Issues to work on for beginners</a></p>
    <p>The User-Agent is the user-facing piece of Pixelated. It consists of a single-page webapp (since users are most accustomed to using webmail as opposed to a locally installed email client) and provides a RESTful API. The User-Agent focuses on high-quality user experience in order to facilitate the use of email encryption. Pixelated uses an opportunistic approach to encryption: it encrypts every email that it can find public keys for. Using the Pixelated User-Agent, the email user does not have to worry about key generation or key management anymore, since it is handled automatically as far as possible. The User-Agent is the mail client of the Pixelated ecosystem. It is composed of two parts, a web interface written in JavaScript (FlightJS and some ReactJS) and a Python API that interacts with a LEAP Provider, the e-mail platform that Pixelated is built on.</p>

    <h2 id="pixelated-puppet-module">Pixelated Puppet Module</h2>
    <p><a target="_blank" href="https://github.com/pixelated/puppet-pixelated">Repository on Github</a></p>
    <p><a target="_blank" href="https://github.com/pixelated/puppet-pixelated/issues?q=is%3Aopen+is%3Aissue+label%3ABeginner">Issues to work on for beginners</a></p>
    <p>Languages: Puppet, Ruby</p>
    <p>This puppet module provides a simple way to add Pixelated to a running LEAP Platform. It sets up a multi-user instance of the <a target="_blank" href="https://github.com/pixelated/pixelated-user-agent">Pixelated User-Agent</a>.</p>

    <h2 id="leap-platform">LEAP platform</h2>
    <p><a target="_blank" href="https://github.com/leapcode/leap_platform">Repository on Github</a></p>
    <p><a target="_blank" href="https://leap.se/code/projects/platform/issues?query_id=172">Issues to work on for beginners</a></p>
    <p>In a Pixelated server-side setup, the service provider is running the Pixelated Platform, which includes a LEAP installation. LEAP ensures that all data is encrypted at rest, including your meta data, and communicates with other email providers via SMTP/TLS.</p>

    <h2>Soledad</h2>
    <p><a target="_blank" href="https://github.com/leapcode/soledad">Repository on Github</a></p>
    <p>Soledad (Synchronization of Locally Encrypted Documents Among Devices) is a server daemon and client library that allows applications to securely share a common state among devices. Any data saved to the database by the application is client-encrypted, backed up in the cloud, and synchronized among a user’s devices.</p>

    <h2>What are the underlying technical threat models?</h2>
    <p>When we designed Pixelated, we had the following attacks in mind:</p>
    <ul>
      <li>One-time attacks on the network (e.g. man-in-the-middle attacks)</li>
      <li>One-time attacks on the server (e.g. hard drive data dump)</li>
      <li>One-time attacks on the client (e.g. XSS attacks)</li>
      <li>Persistent attacks on the client (e.g. compromised computer)</li>
      <li>Persistent attacks on the server (e.g. rootkit)</li>
      <li>Advanced persistent threat on the client</li>
      <li>Advanced persistent threat on the server</li>
    </ul>
    <p><strong>Scenario 1</strong>: Pixelated user sends an email to somebody at a different mail provider. The recipient does not have a PGP key and their mail provider does not support TLS</p>
    <p>We are assuming interception without knowledge of the sender or recipient and/or uncooperative senders and recipients. Attacks marked with one or more exclamation marks are easy to carry out and are within reach of most governments as well as employes of companies providing internet services. Attacks marked “NSA” require serious effort and technical capabilities only within reach of sophisticated attackers.</p>
    <p>Pixelated user&#39;s desktop:</p>
    <ul>
      <li>Web browser handles metadata and content as clear text.</li>
      <li>User&#39;s computer must be tapped to get access to the message. [NSA]</li>
    </ul>
    <p>Transport user&#39;s desktop &lt;=&gt; Pixelated server:</p>
    <ul>
      <li>Transport is encrypted, all message data (meta data and actual content) is in the clear.</li>
      <li>Network access and man-in-the-middle attack required to get access to the message. [NSA]</li>
    </ul>
    <p>Pixelated server:</p>
    <ul>
      <li>All message data is in the clear. Message is stored in a database encrypted with sender’s key.</li>
      <li>Provider can be compelled to provide user’s key to get access to decrypt database in order to get access to the complete message. [!]</li>
    </ul>
    <p>Network Pixelated server &lt;=&gt; Recipient&#39;s mail provider:</p>
    <ul>
      <li>All message data is in the clear. Transport is not secured.</li>
      <li>Network access sufficient to get access to complete message data. [!!]</li>
    </ul>
    <p>Recipient&#39;s mail provider:</p>
    <ul>
      <li>All message data is in the clear. Message is stored without further encryption.</li>
      <li>Provider can be compelled to provide access to the complete message. [!]</li>
    </ul>
    <p><strong>Scenario 2</strong>: Like scenario 1 but the recipient’s mail provider supports TLS. This is the scenario the big mail providers (Google, Outlook, Email-made-in-Germany) advertise</p>
    <p>Pixelated user&#39;s desktop:</p>
    <ul>
      <li>Web browser handles metadata and content as clear text.</li>
      <li>Computer must be hacked to get access to the message. [NSA]</li>
    </ul>
    <p>Transport user&#39;s desktop &lt;=&gt; Pixelated server:</p>
    <ul>
      <li>Transport is encrypted, all message data is in the clear.</li>
      <li>Network access and man-in-the-middle attack required to get access to the message. [NSA]</li>
    </ul>
    <p>Pixelated server:</p>
    <ul>
      <li>All message data is in the clear. Message is stored in a database encrypted with sender’s key.</li>
      <li>Provider can be compelled to provide user’s key to get access to decrypt database in order to get access to the complete message. [!]</li>
    </ul>
    <p>Network Pixelated server &lt;=&gt; Recipient&#39;s mail provider:</p>
    <ul>
      <li>All message data is in the clear. Transport is secured with a key negotiated by the recipient’s mail provider.</li>
      <li>Network access and man-in-the-middle attack required to get access to the message. [!]</li>
    </ul>
    <p>Recipient&#39;s mail provider:</p>
    <ul>
      <li>All message data is in the clear. Message is stored without further encryption.</li>
      <li>Provider can be compelled to provide access to the complete message. [NSA]</li>
    </ul>
    <p><strong>Scenario 3</strong>: Like scenario 1 but the recipient has a PGP key. This is the base scenario for any solution using encrypted email with PGP</p>
    <p>Pixelated user&#39;s desktop:</p>
    <ul>
      <li>Web browser handles metadata and content as clear text.</li>
      <li>Computer must be hacked to get access to the message. [NSA]</li>
    </ul>
    <p>Transport user&#39;s desktop &lt;=&gt; Pixelated server:</p>
    <ul>
      <li>Transport is encrypted, all message data is in the clear.</li>
      <li>Network access and man-in-the-middle attack required to get access to the message. [NSA]</li>
    </ul>
    <p>Pixelated server:</p>
    <ul>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear.Message is stored in a database encrypted with sender’s key.</li>
      <li>Message content cannot be accessed. Provider can be compelled to provide user’s key to get access to decrypt database and get access to metadata. [!]</li>
    </ul>
    <p>Network Pixelated server &lt;=&gt; Recipient&#39;s mail provider:</p>
    <ul>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear. Transport is not secured.</li>
      <li>Message content cannot be accessed. Network access sufficient to get access to the metadata. [!!]</li>
    </ul>
    <p>Recipient&#39;s mail provider:</p>
    <ul>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear. Message is stored without further encryption.</li>
      <li>Message content cannot be accessed. Provider can be compelled to provide access to metadata. [!]</li>
    </ul>
    <p><strong>Scenario 4</strong>: Combination of scenario 2 and 3, ie. TLS and PGP. This is the safest scenario supported by Pixelated.</p>
    <p>Pixelated user&#39;s desktop:</p>
    <ul>
      <li>Web browser handles metadata and content as clear text.</li>
      <li>Computer must be hacked to get access to the message. [NSA]</li>
    </ul>
    <p>Transport user&#39;s desktop &lt;=&gt; Pixelated server:</p>
    <ul>
      <li>Transport is encrypted, all message data is in the clear.</li>
      <li>Network access and man-in-the-middle attack required to get access to the message. [NSA]</li>
    </ul>
    <p>Pixelated server:</p>
    <ul>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear. Message is stored in a database encrypted with sender’s key.</li>
      <li>Message content cannot be accessed.</li>
      <li>Provider must be compelled to provide user’s key to get access to decrypt database and get access to metadata. [!]</li>
    </ul>
    <p>Network Pixelated server &lt;=&gt; Recipient&#39;s mail provider:</p>
    <ul>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear. Transport is secured with a key negotiated by the recipient’s mail provider.</li>
      <li>Message content is encrypted with recipient’s key. Meta data is in the clear. Message is stored without further encryption. [NSA]</li>
    </ul>
    <p>Recipient&#39;s mail provider:</p>
    <ul>
      <li>Message content cannot be accessed. Man-in-the-middle attack required to get access to metadata.</li>
      <li>Message content cannot be accessed.</li>
      <li>Provider must be compelled to provide access to metadata. [!]</li>
    </ul>
  </section>

  <hr>

  <section>
    <h1 id="contact-the-project">Contact the project</h1>

    <ul>
      <li>Do you want to contact the team? Send an email to <a href="mailto:pixelated-team@thoughtworks.com" target="_blank">pixelated-team@thoughtworks.com</a></li>
    </ul>
  </section>

</div>