KeePassX is a program for storing your passwords in a convenient and very secure way. Here is a excerpt from their webpage (with slight modifications):
KeePassX saves information such as user names, passwords, urls, attachments, and comments in one single database. The entries are sorted in groups. KeePassX also offers a little utility for secure password generation. The complete database is always encrypted either with AES (alias Rijndael) or Twofish encryption algorithm using a 256 bit key.
The official site can be found at http://www.keepassx.org/, where you can download KeePassX for use with Linux, Mac, and Windows.
This is an introductory tutorial in order to get you started.
1. Start the program. When you open your new database choose a master password (see Figure 1). THIS IS THE SINGLE MOST IMPORTANT PASSWORD YOU WILL HAVE: if you lose this password, you will lose access to all of your passwords. Also, the strength of this password will determine how safe your password database is. (See below for more on password strength.)
An aside: If you have a safe place to store your master password, you can write it down and store it there. But make sure no one else can get access to this password, since if they do they can access all of your passwords. (I myself have one memorable password that is very long and I do not write it down.)
After you enter your master password, you will be asked to confirm this password.
Although also having a key file is more secure, I will not cover this in depth in the tutorial. Basically, the idea is that you have a file saved on the drive of your choice—e.g., on a usb stick—and only when that file is also present can you open the database.
2) Once you have set your master password, you will see an empty database. In order to begin populating your database with entries, you can click the “Add New Entry” symbol (see Figure 2).
3) You will now be presented with the New Entry box (see Figure 3). Fill out the necessary information. (NB In this example, I have clicked on the eye symbol next to the password box in order to show the password in normal text. If you do not click on the eye symbol, your password will appear as a string of asterisks, i.e., *******.)
In your new entry you can save the following, all of which will be safely encrypted:
- Username and password
- Url for the website
- The expiration date of the password
Note that I have used a randomly generated password. Since all of my passwords are stored in a database, I only need to remember one password to have access to the database, from where I can copy and paste the random passwords. In order to generate a random password, click in the “Gen.” box (next to the “Repeat” text box in Figure 3, under “Password”). You will be presented with the password generator parameters (see Figure 4). Once you have set the parameters, click on “Generate.”
When you have finished with (i) your randomly generated password (Figure 4) or (ii) your New Entry (Figure 3), click “OK” in the lower right corner. This new entry will now be stored in the respective group (here the group is “Internet”; see Figure 5).
In order to use KeePassX in your every day life—that is, to copy and paste the username, password, url, etc. from your entry—you can either right click on the entry or use keyboard shortcuts when the entry is highlighted.
- For example, when using a Mac I click on the entry I want and use “command key + u” to open the url in my preferred browser.
- The I use “command key + b” to copy the username. I paste it in the “log in” box using “command + v.”
- Then I use “command key + c” to copy the password, which I paste into the password box using “command + v.”
- Note that for security reasons, in my preferences I have set the clipboard to be cleared after 20 seconds.
4) If you are like me and have many passwords for many different things, you will want to have different groups and subgroups.
In order to do this, click on the “Groups” dropdown from the panel and select “Add New Group” (see Figure 6).
When you click on “Add New Group,” you will see the following entry box (Figure 7).
Provide a title and select an icon for visual aid in keeping your groups organized. When you click OK, you will now see your group in the database (see Figure 8).
You can add new entries to your group by following steps 2 — 3.
Once you are done, save your database. The file extension will be kdb. Now you can rest assured that your usernames, passwords, attachments, etc. are saved in an encrypted database which only can be accessed using a master password (or a master password with a key file, if you have chosen this option). But remember, your database will only be as safe as your master password, and if you forget this master password, you will lose access to all of your passwords.
A note on passwords:
- Choose a long password THAT YOU WILL REMEMBER. The best password is one that is easy for you to remember but very difficult for someone else to guess.
- DO NOT USE A WORD FROM THE DICTIONARY. It is easy to use a computer to run through the entries in a dictionary.
- DO NOT REUSE A PASSWORD: that is, make each password unique. Why? Recall when the LinkedIn website was cracked in Spring 2012. If the password used for that website is one used for many different sites, the data on all of those other websites is now compromised. Do not risk it. KeePassX will make it easier to keep those many passwords unique.
- Check out this calculator to see how long it would take to crack your password using ‘brute force’ search (that is, trying all possible combinations). Note that this calculator does not tell you how good your password is. For instance, the password “password” may take a 6.91 years at 1,000 attempts per second, it will not take very long to guess as it is one of the most common passwords.
You never, ever want to leave a password on your computer in plain text. For example, anyone can boot the computer from a live CD or USB drive and copy the entire contents of your hard drive—whatever is not encrypted, the perpetrators have access to. This is the biggest advantage of an encrypted database. No one can access it without that master password. Also, you can carry your passwords around on a USB stick if you want and rest assured that even if the pen drive is stolen or lost, your passwords are safe—well, as safe as that master password is good.
Below is a short list of the various projects with a focus on federated, decentralized networks. Much more comprehensive lists exist: see, for example, the excellent lists by the Free Software Foundation Europe (FSFE) at https://wiki.fsfe.org/CloudComputing and the FreedomBoxFoundation at http://wiki.debian.org/FreedomBox/LeavingTheCloud. This here is but a small sample of the projects I find intriguing. I will add to this list as I learn more about other projects.
Although each project provides a service which has a centralized counterpart (mentioned in parentheses), the various projects are not really meant to be compared. The Yacy website says it well:
“YaCy’s selling point (if you will) is not that it delivers better results faster than Bing or Google — it currently doesn’t do that. It’s the fact that it’s a distributed, peer-to-peer system. With YaCy, there is no central server that can fail. There is no central instance that can decide to show some results and not others, or how to rank the results.”
Thus, at the moment the unique selling point is not the ends, but the means to the ends: these services are decentralized, and allow for the user to be freed from the walls currently enclosing much of the web. Of course, the more that people use these services will only help improve the ends and make the products even more competitive (especially for projects like Yacy, which benefit greatly by more users feeding the network).
Unfortunately, most are not easy to install or use (except Yacy, which has a wonderful 2-minute installer) … yet! I hope with enough interest the developers will also facilitate installation and general use for the less techsavvy among us.
Until then, take a look, donate, let your friends know, and most of all give them a try.
— Yacy (pronounced “ya see”) (Google/Bind/DuckDuckGo) http://yacy.net/
YaCy is a peer-to-peer, decentralized web crawler and search engine. It does not require a central server, and cannot be censored. Users are presumably anonymous, as there is no central hub where searches can be stored. Searches can include not only text formats but also video, image, audio, etc.
— GNU Telephony / GNU SIP Witch / GNU Free Call (Skype) http://www.gnutelephony.org/
Peer-to-peer VoIP which aims to make communication secure and private through cryptography.
— MediaGoblin (Flickr, Youtube, Picassa) http://www.mediagoblin.org/
Mediagoblin is a decentralized web platform for media (images, audio, video, etc).
— FreedomBox https://freedomboxfoundation.org/
The FreedomBox is a larger project than just one service. One day they envision every home having its own plug-in server, running a variety of decentralized programs. From the website: “The centralized systems of surveillance and control underlying current social networking tools have a firm grip on millions of people around the world. Even with the best software and the best hardware, shifting how people communicate is a large task and will take time. The Foundation was started because the longer that we do nothing, that harder it becomes.” On this topic, I would like to add a like to a wonderful speech by Eben Moglen on freedom for the web: http://www.softwarefreedom.org/events/2010/isoc-ny/FreedomInTheCloud-transcript.html
Finally, I close with a quote from the linguist and intellectual Noam Chomsky, talking about his idea of a “federated, decentralized system of free associations” (this was from the 1960s/1970s and he was discussing politics and human nature, but it seems fitting to the decentralized web as well):
“If it is correct, as I believe it is, that a fundamental element of human nature is the need for creative work, for creative inquiry [...] without the arbitrary limiting effects of coercive institutions, then of course it will follow that a decent society should maximize the possibilities for this fundamental human characteristic to be realized. Now a federated, decentralized system of free associations, incorporating economic as well as social institutions [...], seems to me is the appropriate form of social organization for an advanced technological society in which human beings do not have to be forced into a position of tools, of cogs in the machine.”
In Pistos-Diaspora (currently at diasp0ra.ca only), you can personalize the color of podmates in your stream through a customized CSS. (This post owes its thanks to firstname.lastname@example.org.)
Note that this works in FireFox and should work in Chrome. If there are browsers for which this doesn’t work, please let me know in the comments.
Simply put, Cascading Style Sheets (or CSS) allow the user to locally change certain aspects of the formatting on a website. In this tutorial, you will learn how to customize CSS to make Pistos-Diaspora podmates appear in green when you hover over the stream.
2. Copy the entire text (i.e., make sure to scroll to the right) under the section “changing the display-color of podmates” (see Figure 1).
3. Click on your handle on the upper-right hand side of your Diaspora home page and select “Settings” from the dropdown menu.
4. Scroll down until you see “Custom CSS” and paste the text into the text box (see Figure 2). Don’t forget to update!
Now, when you hover over your stream, podmates will appear in green instead of orange.
You can go here http://www.htmlcolortable.com/ to see what other colors are available. I have yet to try changing it from the default green myself, but I will provide a how-to as soon as time permits.
Pistos-Diaspora is a fork of the Diaspora Alpha software. Pistos has garnered a lot of support not only for the development of many features not found in the main branch (such as chat, groups, etc), but also for the active involvement in the larger Diaspora community.
To see a list of pods running Pistos Diaspora, please follow this link: https://github.com/Pistos/diaspora/wiki/List-of-Pods-Running-This-Code.
“Diaspora and Me” — A reprint of Pistos’s address to the larger Diaspora community (Pistos Diaspora)Posted: 10 March 2012
(This was publicly posted on 9 March 2012 by email@example.com. I have reprinted it here in its entirety for posterity’s sake. To see the original post and the comments, click here: https://diasp0ra.ca/posts/218102.)
Hi. I just want to write here about everything I think and feel about Diaspora — or, at least, the more important thoughts and feelings. If I hadn’t made any friends on Diaspora, and nobody knew me, and I didn’t know anyone else, I probably wouldn’t bother with this. So, one of the reasons I’m writing this up is to serve as a collection of answers to what I anticipate will be some questions that will be frequently asked of me. Indeed, some of these things have already been asked of me, but I’ve been dodging the questions. Another reason for me writing this is that I’ve kept some things to my self, and I just want to get them off my chest. There is a burden I wish to unload. Although there is emotion in these words, I’ve still aimed to say only that which is worthwhile. I also want to get this out there to serve as a little bit of documented history. What I have in mind here is that saying “Those who cannot remember the past…” I don’t want what happened to me to happen to others.
tl;dr : I wish #diasporainc and I could work together. The future of the Diaspora project and me could be bright, or it could be bleak. I can’t tell which it will be.
Like many others, I heard about Diaspora in 2010 when they published their video, announced their project, and started collecting funds to work on it. I didn’t do anything with or about Diaspora other than wait for my invitation request to be processed. Even after eventually being granted an account on joindiaspora.com, I did not seriously begin working with the code until October 2011.
Things went well. I contributed increasingly larger code patches, and they were getting accepted. The project team and I had discussions on github about my submissions, and we worked together to make any necessary changes to get my code merged into the main line of development.
But then, a trend started where some of my submissions would not get accepted. Sometimes, it would just be due to delay (i.e. it wasn’t outright rejection). But often, I simply would be left in the dark as to why my work was not getting merged. The primary example of this is Post Preview.
At the time, I was just a user of joindiaspora.com, and I had to wait for them to deploy before being able to make use of whatever features or fixes I coded. Well, that didn’t last long. I soon put up my own pod, so I could push things to production as soon as I thought they were ready. This also gave me much more freedom to experiment with things. That is, in my own codebase, and not theirs. As I’ve said several times (elsewhere), in a multi-person, collaborative software project, I believe that it’s good for code to undergo review before being merged in. So, even though Diaspora Inc. granted me the power to push code to their repository any time I wanted, I did not exercise this privilege except for the most trivial changes, or when an external patch (or work of my own) demonstrably fixed a bug.
So, off I went, coding more things in my github fork (not to be mistaken for being a full project fork). I always worked in such a way that my patches would be mergeable back to the main line of development. I kept my fork up to date with their work.
Different Strokes for Different Folks
Over the month or two that followed, I began to see things about the way Diaspora Inc. was managing the project that I didn’t agree with, or would do differently. They may have (or have had) good reasons for doing whatever they did (and do), but, by now, I no longer have much desire to determine what those reasons are. They have the right, of course, to run their ship however they want. But I will just enumerate some of the differences they and I have, because people have asked, and will probably continue to ask.
Pod Neutrality: I believe any primary, popular or main fork of the Diaspora codebase should not have pod-specific code in it. Even as I write this, many things in Diaspora Inc.’s codebase have to do with joindiaspora.com specifically. In contrast, I believe that the main trunk of development should be utterly pod-neutral, and any pod-specific code should reside in a separate branch, or should be added on in production by way of a modular interface. Otherwise, other podmins have to undo or remove the joindiaspora.com-specific things before deploying to production. I don’t believe any pod, not even JD, deserves to have any kind of elevated status in the codebase. In my fork, all diasp0ra.ca-specific code (landing page, footer links, privacy info page, etc.) is NOT in the main line of development.
Stable Branch: I believe that some branch (or series of tags) in the code needs to be kept as stable and production-ready as possible. It could be the master branch, but it doesn’t have to be.
Megapods vs. Micropods: I believe that improving single-pod scalability is not as important right now as other things that deserve developer attention. Primarily this is because the “classic” code (November 2011) ran acceptably on small- and medium-sized pods. It only ran into problems at much larger scales (hundreds of everyday-active users). Instead of working at scaling user count, I think the focus should be at scaling pod count. That means two things: Easy, secure and comprehensive account migration; and easy pod installation, upgrade and maintenance.
Money-driven: While the members of Diaspora Inc. are free to pursue their living how they like, I myself don’t need Diaspora to make money, so I work on Diaspora without seeking remuneration. This allows me to be free to set project priorities as I think they should be, and not be subject to the influence of the bottom line, any board of directors, or needing to keep a company afloat or alive.
Communication: The most critical difference between Diaspora Inc. and I has to do with communication. I believe that they do not communicate enough. Please note that I did not say they do not communicate at all. I’m saying that I think they do not communicate enough. Communicating with them is like having a phone conversation with someone who responds only to every fifth sentence of yours. Or writing to someone who only responds to one in ten emails. Or dating someone that stands you up every fourth date, and doesn’t return your phone messages. In short: It doesn’t work.
In contrast, here’s how I run my projects: I keep my IRC (chat) client open 24/7/365 in a support channel. This lets me see every support request, and I respond if I happen to be around when people ask questions. All my projects are on github, and I respond to comments, private messages and pull requests there. With respect to Diaspora in particular, I follow relevant hashtags and comment on posts that are asking questions, reporting bugs, or making suggestions. If I am particularly busy, and don’t have time to provide an in-depth answer to something, I almost always respond anyway, with a short answer, or an apology that I’m busy, and that I’ll get back to the person. I make use of issue trackers, wikis and websites to disseminate information. I make use of rubydoc sites to provide code-level documentation. If certain questions come up frequently, I take the time to write up answers, and publish them in a FAQ. I give communication a higher priority than coding. Yet, I still manage to code.
Some might point out that there’s a difference in size between Diaspora and my projects. This is true. But that doesn’t excuse bad communication. As your project scales up, so will the ease with which you can recruit people to help, and that includes helping with communication, whether by way of documentation, helping people in the support channels, or doing general public relations work. Good documentation also can relieve the need to directly communicate with people too often.
The Rift Begins
I tried for quite some time to maintain merge compatibility with Diaspora Inc.’s code. Around the beginning of December 2011, though, their main development branch became too unstable by my standards. At that time, I still wanted to stay compatible, so my attitude was that I hoped that their master branch would stabilize soon, so I could continue merging their work in. Unfortunately, that basically never happened.
In early January 2012, they released a major change to the code. This caused such severe divergence between their codebase and mine (and others) that it was practically unfeasible to merge work in either direction. For any of the work I had done up to that point to have had any chance of getting merged in, I would have had to rewrite it against their new codebase tip. It was a very discouraging turn of events. There were two things they could have done that would have made things better, but they did neither.
First, they could have temporarily closed the door on pull requests and then dealt with all the outstanding pull requests prior to embarking on the major change they implemented. Instead, basically all outstanding pull requests (not just mine) were rendered unusable. All the person-hours that went into them were garbaged. This upset a number of developers, not just me.
Second, they could have communicated their intent with the codebase before starting any work. That way, people would at least have known that they should not try to branch anything off the existing master tip, to avoid wasting time and effort on something that would need to be redone when Diaspora Inc. was finished.
With all these differences of opinion, the major code divergence, and a really feeble level of communication, it became clear that I could no longer try to work with Diaspora Inc. I had to fork my codebase — these factors made me. I didn’t want to fork. I knew very well that having significantly divergent codebases would make future merges difficult or impossible. Later work in one fork would have to be rewritten to be used in the other fork. Despite these realities, I went ahead, because it was either fork or stop working on Diaspora altogether.
In late February 2012, Diaspora Inc. made plans to change federation and the inter-pod protocol. In all likelihood, any codebases using the old protocol would become incompatible, and, therefore, any pods running those codebases would be cut off from the network of pods running the #diasporainc code. This also means the Friendica network would be unable to communicate with Diaspora (until and unless they made all necessary charges). There are rumours that documentation of the changes will be released, but I have my doubts. Work has already begun on the new protocol, with zero documentation shown or discussion had about it (in public).
I have had mixed feelings about Diaspora for some weeks now (it is early March 2012 as I write this). I only bothered to continue working separately on Diaspora because I assumed pods running my code would continue to remain compatible with the greater Diasporanet. It never occurred to me that there would actually be changes that would cut off our pods. With the advent of these latest events, the continued lives of my fork and pods running it are in serious jeopardy. I suppose it hinges on how easy they make it to implement the new protocol (in other codebases, and in third-party networks like Friendica).
But how long can my divergent codebase stay alive? It hasn’t happened yet, but one day they’re going to come up with a killer feature that will be difficult or impossible to code into my fork. That would be the beginning of the end.
On a technical level, I would only work off their codebase again if it were consistently stable, and it had basically all the features that regressed since December 2011. It’s March 2012, and they still haven’t done that (comment Like and working line breaks, anyone?).
But, more importantly, on a personal level, I don’t want to work with them because of how they are. Not how they are as coders (technical), nor as acquaintances (social), but as colleagues (professional). Sean Tilley embodies the final hope I have in Diaspora Inc. because he actually communicates. And I don’t just mean with me. I see him talking with many others, and there’s probably even more he does that I don’t see. Please thank Sean the next time you run into him. The single most important thing Diaspora Inc. has done in 2012 is hire Sean, because, in doing so, they are addressing the issue(s!) of communication.
I intend to continue working on Diaspora and serving the Diaspora community for as long as my efforts bear fruit in the Diasporaverse. However, if the actions of #diasporainc begin choking my fork, that is not a battle I can win alone. We shall see what the future holds, my friends.
#diaspora #diasporapistos #diasp0raca #pistos #dev #devs #podmin #podmins #opensource
Here are answers to some specific questions asked by people on this post.
What makes you work so hard to develop and administrate this site?
I believe in some of the ideals that the Diaspora project espoused at its inception. Non-commerciality, privacy, decentralization, open source, and more. I want to be a part of the change I want to see in the world. I’m (usually) not one to stand idly by when something can be done, needs to be done. I also get satisfaction from coding things that people ask for and want. It’s gratifying to make something easier for people, or cooler, or take less time, or be less frustrating.
Do you see the pistoscode as a fork, or just a temporary state while the code is waiting to be pulled into the main codebase?
It used to be a temporary state, but by now, it’s pretty much a full-on fork. The only things missing might be a different name, marketing, and a competitive spirit. I’m confident that the code I’ve written up to this point will never enter #diasporainc’s codebase, for at least two reasons: Our codebases are too divergent right now; I haven’t written it to their specifications (e.g. with respect to testing). I have always been willing to write to their standards (technical obstacle), but I am not willing to work with them for as long as they continue to behave the way they do (social obstacle).
Where would you like to see Diaspora and you go, moving forward?
I would like not to have a fork (and, in fact, not to have to administer a pod). I would like to see #diasporainc make all necessary communication-related improvements, stabilize their code, and repair all regressions that occurred since the beginning of 2012. That would be a good start. I would like to work together with them, because they understand a lot more of the code than I do. It would be very helpful to get their assistance in understanding certain parts of it. Plus, more people rowing in the same direction is better than fewer.
However, I don’t consider there to be any realistic chance of these things happening or changing.
Does forking have to be a bad thing?
Forking a project is generally done out of necessity. A concession. A choice of an ill to avoid a greater ill.
Is it possible to organize the code so that there is the vanilla version (the core dev’s version) and then augmented versions such as the pistoscode? (So people can pick and choose what they want to use for their pod installations – kind of like Drupal?)
It is definitely possible to have a baseline, pod-neutral codebase, and then a modular and/or configurable system that allows podmins to choose features. But that’s not how #diasporainc wants it to be (as I’ve mentioned above). It isn’t even about forks or not. Even if there were no forks, this is still a principle worth adhering to.
How do you find the various representations of the core devs as has been posted on the stream?
Naturally, it’s not possible for me to have seen everything, but I will say this: I still give each of them the benefit of the doubt as far as outright greed or malice goes. I think people should not pass conjecture off as fact, and we should also try not to phrase ourselves such that there’s risk that speculation would be mistaken for certain knowledge.
What bridges do you think are important to maintain in the community? How would you like to see that happen?
There are two important lines of communication that should be kept healthy and vibrant: that between a project and its users, and that between a project and its contributors. How could that happen? That’s for #diasporainc to answer. I walk the talk with my own fork and pod. Refer to what I said above about communication.
What is your vision for a decentralized, privacy sensitive social network? (i.e. the software)
I actually have never taken the time to formulate a high-level vision for Diaspora. Up to now, I’ve just wanted to dialogue with the users, and work on some of the things they ask for, or the things that I myself want to see in Diaspora (as a fellow user).
For starters, I think, if anything, I would want a social network that had built-in immunity from commercial interests, even if only to a certain extent. No data mining, no tracking, no ads. Not influenced by greed, and resistant to any central control. I would want a social network to run on software that was free (liberated), so that it could be freely shared and improved by the global village. Going beyond that, I would love to see the social network run on non-commercial infrastructure. I don’t know how that could work right now, but imagine if your social network ran on, say, a wireless grid of easily-affordable machines, strewn all across your neighbourhood, your city, your country, with no involvement of any ISP, cable company, phone company, server company, government — none of those things. Nothing but hoi polloi, the people, the masses, doing their thing, by themselves, for themselves.
What is your vision for the social aspects of the D* community? (i.e., the community of coders and users as a whole)
With strong communication, so much is possible. Almost everything follows from that. Stifle that, and you are planting seeds in the desert. Every effort becomes undermined; stunted and crippled to be less than what it could have been.
What do you foresee in the near future for diasp0ra.ca, relating to federating with the main pod, etc, in light of their changes? What do you plan to do about federation?
If they make it easy enough, I will adjust the code to be able to communicate with the greater Diasporanet. If it’s too hard, we’ll have to assess how viable the smaller network will be, whether it would be worth keeping alive. I have no inclination to reverse engineer anything, or to decipher uncommented source code.
Will you be throwing away the baby with the bathwater and removing the old protocols entirely? More generally, will pistos-diaspora in the medium-long term federate only with Diaspora Mainline, or with everything else too?
I hadn’t considered maintaining backward compatibility. If it’s not too much effort, or if there is significant demand, I will, but we’ll have to see. I’m not that interested in doing much work as far as external network compatibility goes, in the interest of limiting scope (workload).
Do you have any plans to continuing to develop the API so we can fix it?
I like what people have been doing with the API so far, and the API is actually one of the easier things to work with in the code, so I think the API will enjoy a lot of attention within my fork.
Would you continue working on diaspora-pistos if the jd team decides to pursue mega-pods and database-level federation instead of old-fashioned pod to pod federation?
If things change on #diasporainc’s side, and people still want the “classic” Diaspora that my fork offers, then I would continue to work on it, and support podmins, and dialogue with users, and so forth. So, I would leave it up to the people to decide.
Do you think of asking publically for help in development? i cant imagine how far diasp0raca could go if you had some help…
If I did that, I think that would cross a line: I would first have to decide whether I want to directly compete with #diasporainc. I am not willing to take that step right now. Of course I welcome any help, but right now, I will not openly advertise for help, nor approach known contributors to ask for any committed, regular help.
Would you accept donations? Where can I donate some money for you to start some funding like geraspora?
I do have interest in accepting financial assistance to help with the server costs. Unfortunately, I have not found any payment system which is available for Canadian recipients and which suitably protects my information and identity. As such, donating is only an option for Canadian donors who can send Interac Email Transfers (a fast, safe, anonymous payment system which is only available via major Canadian banks).
Opportunity Knocks blog post: Discussing Diaspora’s Future.
“I have seen lots of discussion about the future of !Diaspora lately. Here is my first attempt to really weigh in. We need to distinguish between several things that are all called Diaspora. First of all, there is Diaspora the project (DProj), the Diaspora core development team (DCore), Diaspora the corporation (DStar), and DStar’s Diaspora pod, JoinDiaspora.com (JD). There are also several independently-operated pods, such as Diasp.org (DiaspO) and Diasp.eu (DiaspE).
First of all, DProj, can really benefit from more contributors. Sadly, I cannot help. I messed around with Ruby for a while, realized that its soup of special characters with special meanings was not going to ever match my brain (like Perl, which has the same problem), and put it down quickly.”
You may not have realized this, but sending an email is not that different from sending a postcard—with the right know-how, anyone could intercept, read, or change it.
Signing an email with a digital signature means that the recipient can verify that no one has changed anything in the email in transit. Better still, encrypting an email means that no one can read it except the sender and you. Signing and encrypting email is not hard to do.
In order to sign, verify, and encrypt/decrypt mail, you can use GPGTools for mac, which works together with your desktop email client (like Mail.app) to make signing and encrypting email very easy.
This post will explain how to set up Mac’s Mail.app to allow you to sign and encrypt your email. Note that this was done on a Mac running Snow Leopard 10.6, but should work on any Mac running 10.5 or higher.
1) Install GPGTools
Installing GPGTool is easy.
- Download the GPGTools Installer at http://www.gpgtools.org/installer/index.html
- Double click the GPGTools dmg and open the installer.
- The installer will check that the program can be installed on your operating system (see Figure 1).
- The installer will then ask you to select a destination where GPGTools should be installed. Select your hard drive.
- Now, choose what you would like to install. I went ahead and installed everything, but you can decide what you want (see Figure 2).
- Then click continue.
- Then click install.
The installer will do the rest. Now you have what you need.
2) GPGTool and Mac’s Mail.app
- If you are using mac’s mail.app, click Mail > Preferences. In the top panel of the preferences windows you should now see GPGMail. Here you can change your preferences. (I will eventually post more on what these options mean, but for now you can look at it yourself.)
3) Generating Public/Private Keys
Generating a key-pair is simple.
- Open the program GPG Keychain Access. Click on New (see Figure 3).
- Fill in your name and the email address you want to use PGP with (see Figure 4).
- Under advance options, I use the defaults, and leave an expiration date for my key—some people say an expiration date is not so important. I let my keys expire so that—should I be unable to revoke my key for whatever reason—I know my key-pair will be invalid eventually.
- The program will begin creating randomized bytes. The longer you randomize, the better (see Figure 5).
- Now it will ask for a password. Choose a good, long password THAT YOU WILL REMEMBER.
- To help you store your passwords, you can use a program like KeePassX, or write it down and store it somewhere safe. Never, ever leave it on your computer in plain text. That is asking for problems down the road. (For example, anyone can boot off a CD or USB drive and copy the entire contents of your hard drive—and then they have your password.)
The best password is one that is NOT HARD to remember but VERY hard for someone to guess.
- DO NOT USE A WORD FROM THE DICTIONARY. It is easy to use a computer to run through the entries in a dictionary.
- DO NOT REUSE A PASSWORD. Make each password unique.
Personally, I use whole sentences, sometimes mixing languages, with a few random letters and characters thrown in at places which I can remember. Then I save them in an encrypted password manager like KeePassX. Perhaps there are better ways, but I think this is not bad.
- After you type in the password and the confirmation, your password pair will be generated.
Now you have a key-pair. I suggest uploading your PUBLIC key to a key server (for example, pgp.mit.edu) so others can find you and verify your messages. (I will write a post on that soon.)
How do key-pairs work?
Remember those love stories in which two young lovers each carry 1/2 of a heart-shaped locket around their necks. When they meet again, they put the two halves together, and the perfect fit means it is their true love.
Well, the concept is similar. Your public key is 1/2 of a pair—the private key being the other half.
The private key is for you only, so keep it safe.
On the other hand, you can give anyone your public key. That way, they can check that an email is from you when you sign an email, or encrypt a message to send to you, which only you can decrypt.
Similarly, once you have your friends public key you can do the same.
Now you have everything all set. I will write more about sending and receiving signed or encrypted email soon.
===Related Posts On PillowFortress===
– How To Import From A PGP Key Server (PGP Signing and Encrypting)