ponyville_trot: Six cartoon ponies in a huddle (Default)
[personal profile] frith posting in [community profile] ponyville_trot
games1

In the interest of Being Excellent and considerate of those who plan to watch this episode, all references to the content of this episode are stashed under the cut and will remain so hidden for at least a month. Someponies like to watch MLP:FIM in herds and it can be a while before they get all their ponies together. 8^) As spoilers are also likely to be in any comments: don't read if you haven't yet seen the episode unless you like being spoiled. When you're ready, drop in a comment and say what you thought of this episode!

After a month, I hope Episode Discuss posts will be so far off the top page that it'll probably take the tag to find them, so about a month after posting the cut will be removed. 8^) Sometimes I go back and drop in little extras into the posts, like comics and links to the music.

Broadcast starts at 11:30 am Eastern Daylight Savings Time, which should work out to 4:30 pm UTC, 8:30 am PST and maybe about 11:30 PM Down Under. Confused? Look at the PonyCountdown widget on the community page! At the moment there are just five hours left to go.

Written by Will and Michael Fox. This is his second episode. He also wrote The Gift of the Maud Pie.

For those of you following Twitter, you can follow writers Nick Confalone (Hearthbreakers), Mike and Will Fox (The Gift of the Maud Pie), Joanna and Kristine (Gauntlet of Fire) and Dave Polsky (Rarity Takes Manehattan). Other twits in the early morning chorus may include the likes of Meghan McCarthy, Jayson Thiessen (Supervising Director of MLP:FIM), Andrea Libman , the voice of Dragon Lord Ember Ali Milner, Big Jim (storyboard work, voice of Troubleshoes and Director of MLP:FIM), Mike Vogel and Josh Haber. The hashtag to watch should be #MLPseason6.


Review for episode 10, Applejack's Day Off, below the cut. )


Catch the show and throw in your two bits in the comments! Copy/paste your reviews into the comments, spread the wealth!

Livestreams! Have something I missed? Tell me! It could end up being the only one that works for someone. It's been a few months since a new episode has been live-streamed, so there may have been some attrition in the stream selection. I'm going to have to check through these a few times. This is the deal this morning:

I am partial to the Twilight Sparkle room on BronyState (it has a chat room I can type in). For instant replay after the show, I was going to the Brony Network last year, but while Bronystate is alive and well, the Brony Network I dunno.

AdBlock is a must or my ISP drops in *ArRRrrghghgh* adverts that block the stream for like 30 seconds during the episode! The nerve! Turning off Javascript once the stream is running might do the same thing.

Bronystate, which includes the adverts during station breaks, has several "rooms" to choose from, like, the Twilight Sparkle room. That's the cool room, because, hay, Twilight Sparkle!

The Brony Network has moved here and here, replacing BN #4 and BN #6.

You might like Otaku Ascended. The hosts are still quite chatty. I suspect they might chat during the broadcast as well, but I'm told that there might be less lag during the stream (perhaps as a result of the gabbing).

There's also: Brony TV. Last year it was still alive, kicking and champing at the bit. Wide screen, good audio. Seems to be a mirror for Justin TV.

If that's working, this should be up as well: http://mlp.quebec/live/ It looks like a mirror for Brony TV with a text-chat in French. Allez y clavarder!

Nom de dieu! Un autre stream live français içi!

and the Brony Show? Nope, dead.

Haxmega's stream is here, but it might not be streaming shows anymore. There's also a Ustream mirror here that is playing music.

Ponies Tonight. What is this? I am the only viewer every time I look. Maybe it's here? (This other one is skipping like mad.)

Equestria TV links to http://equestria.tv/r/cmc_clubhouse , or maybe it's http://equestria.tv/r/Cutie_Marked_Crusaders now. They do a re-stream after the episode, which I can't seem to be able to find.

Cinemaquestria received a C&D from Hasbro on May 19th and won't be streaming or live-streaming episodes, but they plan on discussing new episodes.

World of Equestria's Woeful Streaming channel. There's sound! There's ponies! But the video was low quality.

Something new: HasbroMLP. It's up now, streaming a past episode and it will be streaming the new episodes, but it's buffering frequently at my end.

Three Youtube streams:
MoliminousTheater,
BronyDE and
Norbert Koncz.

There is also PonySpazz's livestream, here: http://www.ustream.tv/channel/20308283 Ustream provides an embed code, but that wasn't executing. It is probably not whitelisted here. The downside is that you can only choose between 1080p, which skips on my connection, and 240 (ish) which is really blurred.

Watch Applejack's "Day" Off on DailyMotion and Youtube too (soon).

Download links for Applejack's "Day" Off: (I'll fill in the blanks later)
As seen on Discovery Family in 1080p: a href="">broadcast version
In 1080p without logos: a href="">logoless.
In 1080p, without logos and colour corrected: a href="">colourful.
They're all mkv format files.

Read all the transcripts, including that of Applejack's "Day" Off over here on the MLP wiki of transcripts.

Clear, free, logoless screengrabs from the entire episode get uploaded to the episode wiki within days of broadcast on the MLP Wikia Gallery pages, here.

The links to official channels and purchasing DVD's and episodes are now in the community sticky. A Cantonese dub of MLP:FIM season one is now being broadcast free-to-air in Hong Kong on ViuTV. Broadcast time is every Thursday and Friday at 5 PM. See http://viu.tv/epg/99
[syndicated profile] jeremiahgrossman_feed

Posted by Jeremiah Grossman

Facebook, LinkedIn, Amazon, PayPal, Yahoo, Google. We keep accounts with many of these websites. They and many others use email addresses as the first half of the classic username and password combo. They do this because email addresses are unique and double as a reasonably secure communication channel with the user. And of course we often sign-up for things online to receive information by entering our email address. All this email address sharing, while technically nothing being wrong with it, unfortunately causes several highly annoying problems. These problems can be solved, or at least made far easier to deal with, by leveraging email address aliases. An email alias is where you create one or more email addresses that all send to the same account, vaguely similar to desktop folder shortcuts.

With email address sharing / username reuse, by far the biggest problem we run into is spam. And the more we share and reuse our email addresses across systems, the bigger the spam problem becomes. Sometimes websites sell our email addresses. Other times they share them with third-partie business partners, and from time to time they get leaked in a data breach. Whatever the case, once an email address is out there, it’s out there. No taking it back and no amount of mailing list opting out will help. I know. I’ve tried.

There are other problems too. Anyone who knows your email address can easily determine what systems you’re using (i.e. “This email address is already registered.”). This issue is not only a privacy issue, but a potential security issue as it makes it easier to target your account via brute force, phishing, password recovery hacks, etc. And of course when you have several online accounts, you’re constantly notified via email, which explodes your inbox. Creating rules in your email app using strings in the subject or content body helps, but doing so isn’t easy and never comprehensive. When all these problems are tied to your email email address, there is no escape. You can’t easily kill or change your main email address because all your friends, family, and business contacts use it too.

My solution to these problems, which has been working great, is by using email address aliases based on custom domain name. For example, my personal domain is jeremiahgrossman.com. So as an example, I create a new email alias that’s just for Facebook, like fb@jeremiahgrossman.com. Or on Paypal it would be pp@jeremiahgrossman. You can technically use any email alias for this purpose, even a random one. When email is sent to these aliases they automatically forward to my main email address. I never reuse these email address aliases for any other than their intended use, and never use my main email address to register for anything if I can help it.

It does cost a few bucks to pay for domain name and email hosting, but it ain’t much these days and the value is WAY worth it. When things are set up this way, I can be reasonably sure that any email to these aliases, that is supposedly from them, is legit and not a phishing scam because no one else knows the email address / username I used. And since the particular website is only using the email address alias I gave them, inbox rules are way easier.

Then if the email address is leaked, gets spammed out, or whatever, I can just kill it off, create another, and change the account email address / username. The up front work is a little tedious, but again, worth it. And the best part, when you have your own domain name, email aliases are essentially free — I’ve about 100 now. And there is no reason you can’t use any old crap domain name either.

Good luck!

WisCon Schedule + About Me

May. 23rd, 2016 02:35 pm
brainwane: My smiling face in front of a brick wall, May 2015. (Default)
[personal profile] brainwane
I'll be at WisCon this year, arriving Thursday the 26th and leaving incredibly early on Monday the 30th (to get to PyCon). I look basically like my profile photo, with slightly longer hair; you might recognize me as @brainwane from Twitter. My pronouns are she/her. I eat mostly vegetarian but will eat fish/poultry that has at least one hippie buzzword (e.g. "organic", "free-range", etc.).

I'm speaking in three sessions:

  1. Panelist on "The Fandom Awakens" (on Star Wars): Friday, May 27, 2:30-3:45 pm, Assembly.

  2. Comedy auctioneer for the charity auction benefiting the James Tiptree, Jr. Literary Award: Saturday, May 28, 7:30pm-probably 8:30pm or 9pm, Capitol/Wisconsin room.

  3. Panelist on "SIX SEASON SERIES BASED ON THE THREE-PART TRILOGY BASED ON THE SINGLE BOOK OF THE NOT ANOTHER F*CKING RACE PANEL" (comedy game show focusing on people of color): Sunday, May 29, 4:00-5:15pm, Wisconsin room.



Also, I will probably drop by the Clothing Swap portion of the Gathering on Friday afternoon to find pieces that suit me and to bask in other people wearing my donated stuff; I would like to drop in on the vid party on Saturday night; I would like to drop in on the Hamilton singalong; I have a Dessert Salon ticket and intend on attending the Guest of Honor and Tiptree Award speeches on Sunday evening.

I am easily lured into talking about Hamilton, Zen Cho, Star Trek, the Marvel Cinematic Universe, the Mahabharata, Hinduism, and other interests in my profile.

Please ask before hugging; sometimes I'd rather not.

I am often bad with names, and will remember 5 minutes into our conversation that we had an awesome deep conversation one year prior. I apologize in advance. Also, I will probably be a little less intensively social this year, because I am trying to actually sleep enough and thus get to PyCon reasonably well-rested, and because client work for my consulting business may come up; I'll probably be trying to sleep every night from about 11pm to 7am, and aiming to take some alone time on top of that. So if you and I have multiple chances to see each other in person at other times of year, I may choose to make time for other people instead; apologies.

The fact that I am, in a sense, succeeding Ellen Klages in serving as the Tiptree auctioneer is quite a responsibility and I hope to discharge it well. So if you came to the Tiptree auction and raucously laughed at my japes I would welcome your chortles.
[syndicated profile] sumana_feed
Conversation the last night of OSCON, reconstructed from memory:
"So, Neil Young --"
"The singer-songwriter?"
"Yeah."
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"











picture of Sumana in front of a steam train in Melbourne, AustraliaIn honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.

My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.

These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.

I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.

I shall carry with me several memories of this OSCON, such as:

  • Breaking the no-electronics rule of the quiet room/relaxation lounge (since I was the only one using it) to finish revising my talk and blog about good code review
  • Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
  • Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
  • Being the only person in the pool at the Software Freedom Conservancy party (foolish choice on my part; it was pretty cold)
  • Meditating on a loved one during an exercise in Cate Huston's talk on technical interviewing, and feeling the lovingkindness throughout the whole room
  • Listening to an enthralling performance by rapper Sammus
  • Discussing pull request workflow, Contributor Licensing Agreements, the engagement funnel, the future of OpenHatch and of Apache Zookeeper, the failings of Google Summer of Code, whether GitHub should allow no-license repositories, how Facebook/Amazon/Google's idiosyncrasies come out in their open source work, performing femininity in the workplace, productivity and routines, effectively signalling to one's employees that they should not work on weekends, what maintainership is, JavaScript and data binding, and BLESS
  • Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
  • Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
  • Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!

But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.

He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.

Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."














Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.

[syndicated profile] sumana_feed
"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.

Introduction

me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.

Housekeeping

Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]

Contempt

My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.

Right?

This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.

Syntax

Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then Back-button right on out of there, for fear that they'd broken something, or that they were about to break something.

And what's worse, when we started introducing the what-you-see-is-what-you-get editor, the Visual Editor, some of the experienced editors pushed back with the argument that the syntax was a gatekeeping measure, that the ability to master this syntax was a really good proxy for whether someone was going to be a good writer and contributor in general. This is pretty nonsensical and has not been borne out as far as I can tell.

So, what is essential here? what is not?

With wikis, it's essential that everyone can edit an article -- that is part of the freedom of free culture. MediaWiki is meant to make it easy to edit. By default, when you set up a new MediaWiki installation, every user can edit every article. We aren't going to add a bunch of different permission and access control layers so that there are fifteen layers of privileges to determine who can edit what page. There's other wiki engines that'll do that, that have different core values, but it's inherent to MediaWiki that we default to freedom.

And that everyone can see every article's history, because that transparency makes everyone a more informed consumer. And there's more, I'm sure. But using the syntax is inessential. It's incidental complexity.

And I would argue that the most essential aspect of the command line is that people are empowered to control their machines and use them the way they want. It's a tool. And it's important that all users have the command line on GNU/Linux available, so they can chain together operations and learn to do development work, if they want, and because there are people who find it a much more accessible experience. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. (Hashtag #unusablefreedom .) So, making new users learn the command line in order to use open source software is an inessential weirdness. Having alternatives available, like the rich desktop environments that GNOME and KDE have made and Ubuntu helped make available, is great. As long as all the GUIs are also accessible to screenreaders.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

Religion

Now another story, and it's actually about a rare failure by one of my favorite conferences. PyCon North America is a yearly community conference about Python. In scheduling PyCon 2014 and 2015, the organizers accidentally scheduled it over Passover, both times. And this means that a nontrivial number of observant Jews couldn't come.

And beyond that, consider how many of our conferences happen over Fridays, Saturdays, and Sundays. If going to a weekly Muslim, Jewish, or Christian religious service is important to somebody, then a weekend conference schedule is going to really crimp their style.

(Now, this is important to balance against the fact that some people can't miss that much work in order to attend a conference. Maybe the best approach is to be aware of who seems to be consistently catered to, what demographics aren't having any trouble showing up, and try to change it up a bit so you have some events, some communication channels, and so on that cater to the people you haven't had as much success in reaching. You can see an example of how I'm doing that in this talk -- I'm using written questions instead of oral Q&A, because it's a way to make some people comfortable who usually don't get to ask questions. And instead of using slides, I suggested we have the live captions, to help people who usually have trouble following a spoken talk.)

I'm not here to try to persuade anyone to join or leave any religion -- I'm a Hindu myself and I'm really grateful that we do not do that here, that in my nearly 20 years in the free software movement no one has tried to convert me. I'm glad our spaces are secular. That is essential to us being open for everyone. But in our aggressive ignorance of religion, and sometimes when we stand by and let anti-religion comments stand without challenging them, we sometimes cause snags for people who want to engage with us.

Sometimes this is in missing opportunities, like partnering with churches, temples, and mosques. Hey, they have communities full of people with free time who are interested in making the world a better place! A lot of them care about privacy from government surveillance, for very good reason! And they have free venues for meetings!

But, again, it's essential to respect people's personal autonomy and freedom. There are people in our communities who have been hurt by religion, been traumatized by religion, who currently face discrimination from religious communities. So of course we have to be mindful of that. So, for instance, if someone in your community isn't going to feel comfortable in a religious space then there's no reason to try to persuade them to do that bit of outreach.

In any case, I'd say that it's an inessential weirdness for us to stand by and allow anti-religious comments in our public spaces. One person who ran an online technical forum mentioned that, in its "off-topic" section, sometimes people said things that were casually sexist or Islamophobic. He said,

"I just kind of rolled my eyes and ignored them. About three years in to running the forum, I incidentally discovered that we had a few closeted women and Muslims in our membership. Suddenly those jokes that were white noise before made me acutely ashamed and I had to update the rules and enforcement to stop those posts going forward. If you had asked me the year before what I thought the community's most serious issues were in expanding and increasing engagement, a 'casual hostility to certain demographics' wasn't even on my radar." -- Matt, Crooked Timber comment thread

More things I wish I could have talked about

I wanted to go into these in depth, so there are topics I mentioned in my abstract that I do think contain inessential weirdnesses but that I don't have time to discuss in depth in this time slot, like open source communication norms, and how our community acts regarding pop music, patriotism, small talk, professional sports, and the primacy of in-person conferences, and the user interface of Git specifically, and assumptions about bandwidth & personal computer quality. I'm happy to discuss any of those during the Q&A or afterwards. This is an incomplete list of examples.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

Takeaways

me in conversation in speaker's lounge - photo by O'Reilly MediaSo what does this imply for open source software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.

1. Look for code smells

These are some really rough heuristics to try to find snags that other people are hitting.

Take the same approach that a Software Reliability Engineer would take, and say, any time a user gets hassled or tripped up, that's a symptom of a problem that needs fixing. You treat every downtime, every pager call, as a bug report.

Look out for any advice your project is giving newcomers that has the word "just" in it. I think Greg Wilson calls this the passive-dismissive adverb.

Watch out for any place in your workflow where newcomers have to deal with simultaneous newness on multiple dimensions. Mako Hill has observed that Wikipedia was founded at the same time as a lot of other innovative free knowledge projects, but Wikipedia's the one that thrived and that's still around, because yeah, it was super weird and disorienting and innovative on the workflow level, but the thing it was aiming at, an encyclopedia, that was a vision all the participants understood. ["Almost Wikipedia: What eight early online collaborative encyclopedia projects reveal about the mechanisms of collective action."] You can only innovate on so many levels at the same time. This goes back to that woodworking example at the beginning. People will have a hard time learning a new language while they're also learning to do an entirely new kind of thing.

If you make an application you want people to use, use the Simply Secure guides on doing qualitative UX (user experience) research, such as seeing how users are using your product/application.

And another possibility -- I know this is a wacky idea -- but you can ask. You can reach out to individual people who attended one event and drifted away, and ask them what you could fix to be less unappealing. That doesn't always scale, it's artisanal data, but still, it'll give you some thoughts to work off of.

And having those thoughts, a list of some things to look at, helps with the next step.

2. Realistically assess yourself & your goals

Once you have an inventory of some things about your community that are putting off newcomers, you have some choices to make. What are you really committed to keeping in absolutely all your activities, and what do you think you could stand to tone down when you're trying to talk to newbies?

Discerning essential from inessential means being honest about what your real values are.

So, what are your goals? What are your values? You care about the Four Freedoms and about treating everyone with respect; beyond that, what are you particularly attached to? Who are you trying to reach out to, & what are the gaps between your culture & theirs? I haven't even gone into international, inter-language, and other differences you might want to traverse, but I can recommend classism.org to get some representative thoughts.

"Observe the cultural norms of people you'd like to work with, watch for signs of discomfort, and study what conveys respect and disrespect in their subculture." -- Leondar-Wright

This isn't about completely changing the entire core of your work. If you have a strong cultural practice and you're committed to it, own it but be nonjudgmental -- say "if you want [other approach] consider [other project]".

Acknowledge that different people want different things. And acknowledge that when you negotiate that with people who are different from you, that will probably require conversations, not just writing FAQs that live forever. [See this explanation of the success of the English Wikipedia's "Teahouse" for more on this.]

3. Find easy ways to build bridges

Sometimes you're going to find easy wins, which is great! There are easy add-ons you can do that overcome a barrier.

Some old-school people like Mailman mailing lists. Some new contributors really like web forums. If you upgrade to Mailman 3, you get one thing that acts like both, so everyone's happy!

If you have an IRC channel, you can do what OpenHatch did and have an automated welcome bot. It greets new people and gives them a couple tips, including the names of a few people they could reach out to for help who have been active recently. If you have a Slack, you can make a bot with the Howdy.ai botkit framework to do something similar.

You can use pre-existing playbooks to run events like SpinachCon, so that new folks don't have to learn git or the command line to make their first contribution.

But usually those kinds of easy wins are not the whole story. If you are serious about building coalitions with people who are not like you, you will probably want to:

4. Build and maintain differentiated but connected spaces

Your project can support both experts-only spaces (where jargon and in-group practices are welcome, like really concise speech and Douglas Adams jokes) and mixed-experience spaces (where hospitality is emphasized and legitimate peripheral participation opportunities are available for learning). [Also see Mark Guzdial's and Greg Wilson's posts on this.]

These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment. For you, a tidepool might be a community that publicizes beginner-friendly events, where Windows users who prefer GUIs to command lines are welcome, where new people can make relationships through small talk, where there's an occasional installfest at a church.

This means that you would have to learn to be comfortable explaining, nonjudgmentally, that there are high-jargon spaces and low-jargon spaces, and helping steer conversations to where they ought to be.

These newcomer-friendly events and online spaces probably ought to have agreed-upon rules. Example: the Recurse Center rules (manual) to help everyone feel comfortable saying "I don't understand." And it's probably a good idea to regularly revisit and revise those rules to see if they've lost touch with any of the essential values and weirdnesses that the community needs to preserve.

And this isn't meant to suggest that we should condescend to newer contributors -- just listen to them, and do what it takes to support and encourage them in their open source software journey. Everybody's got something to learn from us and everybody's got something to teach us. So while teaching new learners, yeah, we should err on the side of clarity and listening, and call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.

5. Acknowledge the costs

"Don't expect you can remain exactly as you are and be a bridge person" -- Leondar-Wright

Engineering is a game of tradeoffs. And yeah, there's a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let's acknowledge that different spaces are genuinely, irreconcilably different.

Whenever you try out a kind of funnel or ladder that you hope will get you new users, new participants, new collaborators, not all of those people are going to work out. And every one of them who drops out is going to feel like a failure of the new plan. Like, "we spent all this time on making a GUI and negotiating with the local mosque to host a meetup and actually making smalltalk with people, and it's still a grind!" You're going to have demoralizing moments and it's going to feel even harder because you're trying something new that you're not good at yet. Which is where the learning happens.

Leondar-Wright says: "Figure out which of your weirdnesses are essential to you, and drop the inessential ones when you're doing cross-class outreach or coalition building. Be thoughtful about who your group sends to be the emissary to a culturally different group." So, that means that some of the people in your community who are not very good at adapting to other people's cultures should not be doing this work. And if they're trying to do this work and they're not good at it, they need to hear that, and that's a hard conversation to have.

Another cost is the cost of the weirdnesses you decide to keep.

If you decide to hold onto a weirdness, then acknowledge that in your outreach, you'll need to pay the cost of making new people comfortable with it. Develop good explanations and metaphors and help people understand why you've made the choices you've made.

Figure out what needs teaching in a standalone class. For instance: the nonprofit Software Carpentry teaches researchers and scientists of all kinds -- physicists, biologists, sociologists, anybody who has to manage and sort through data to do research -- they teach them basic research computing skills, like version control, the Unix command line, and better programming skills. And the Software Carpentry folks have created these workshops and boot camps, sort of as a coping mechanism for the weirdnesses of Git and the command line.

As a community, it looks like we are sort of doing this with Git by creating learning materials, and by making some workarounds. Look at the GitHub web UI as sort of a costly, unfree mitigation of the horribleness of Git's command-line UI. As with wikis: it's essential, with Git, that everyone can suggest improvements, everyone has access to the whole history, it's possible to search for specific changes or classes of changes. But learning to use the command line and the syntax is just not as essential as a first step.

Conclusion

So here's the tiny plug, which is that, through my firm, Changeset Consulting, I can help you with this -- with contributor outreach and with auditing and assessing and improving your current intake and onboarding process. But no matter whether you hire somebody or ask for volunteer help or do all this work yourself, this is going to be tough, but necessary work, for us to build a mass movement.

As Betsy Leondar-Wright says:

None of this is easy. It's one thing to briefly change ourselves for a job interview or for dinner with the in-laws, but it's painful to have to change ourselves in our own activist groups. But as civil rights activist and Sweet Honey in the Rock founder Bernice Johnson Reagan said about coalitions, "If you're comfortable, you ain't doing no coalescing."

I am asking you to stay safe and loved but to try installing discomfort. Everyone deserves safety. Safety is what makes it possible for us to function. But maybe we could take turns being uncomfortable, so the same people don't always have to be uncomfortable all the time. If you are recruiting for new Google Summer of Code interns, or you're on a newbies-friendly mailing list, and you see a barrier to entry, check whether you're acting like those old-school Wikipedians who thought the Visual Editor was keeping out the riffraff. Ask yourself: "Is this essential to our values, or is it more like adding another way in would make us uncomfortable?"

Just give it a spin. As the Open Source and Feelings Diversity Statement says:

"Sometimes we will need to step out of our comfort zones to make everyone feel welcome. We recognize that privilege is real and that the privileged have more bandwidth to be uncomfortable and help make our space more welcoming."

Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, Darius Kazemi, Brendan Adkins, Nick Murphy, Roan Kattouw, Meredith Patterson, Andromeda Yelton, and Kaitlin Thaney for their comments on drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.

Question & Answer

And I'm now ready to answer your written questions. [I received one question.]

Q: Does jargon exist for matters that cannot be understood with preexisting vocabulary?
A: I think the word there is jargon. I think that it's useful to remember that there are -- jargon isn't just about synonyms. It isn't just, you know, we say "quit" or "exit" where somebody else says "end." Jargon isn't just about different words for the same thing. Often one function of jargon is an encapsulated compressed thought that does have dependencies. You can think of trying to reach newbies as a dependency management exercise. How many new concepts and skills are you making them install in order to get to the point where they can do something useful and collaborate with you? And so, I could, you know, if you want some metaphors, I think that's a reasonable one to talk to other coders with. The chunk of thought that this questioner asks about, ideas that cannot be easily expressed or understood with the person's preexisting vocabulary until they learn new words and thoughts, I think "jargon" is a reasonable thing to start there.

Additional note: Thank you to White Coat Captioning for working with O'Reilly Media to provide CART services for this session. I've checked the transcript they provided and improved this post to reflect the question-and-answer session, as well as places where I said something better live than I had scripted for myself to say, and I've included in this post parts of the speech that I did not have time to deliver during my OSCON slot.

This talk is a revision of an earlier talk I delivered at LibrePlanet 2016; in particular, I cut the "small talk" section due to ableism concerns, and may someday expand that chunk of thought into another talk or essay.

The Story of a Season

May. 22nd, 2016 01:51 am
[syndicated profile] pixiepalace_feed

Posted by Rosepixie

I have no idea why I have another Christmas story today, but I guess it simply works out that way sometimes!

My second favorite Christmas story is Charles Dickens’s A Christmas Carol. It’s been retold probably thousands of times in hundreds of ways, so chances are you know the story already. If you don’t know it, please look it up. My favorite version (and one of the most accurate movie versions, interestingly enough) is A Muppet Christmas Carol, but there are tons of great versions out there. Even My Little Pony: Friendship is Magic recently did a good adaptation of the story.

The reason that I love this particular tale is that it’s all about the power of stories. The tool that the ghosts use to show Scrooge that Christmas is worthwhile is stories – about his own past and where his issues with the holiday came from, about the value it has for the people around him, and about what may happen in the future if he continues to miss the values that the holiday celebrates. Stories are powerful things and they make a big impression on Scrooge, as they do on the reader or watcher as well. They show us the world in new ways and ourselves in old ways we may have forgotten. Stories show our hopes, dreams, and fears. Stories let us grow and change. And those are the things that holiday celebrations with loved ones are all about.

[syndicated profile] sumana_feed
"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.

Introduction

me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.

Housekeeping

Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]

Contempt

My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.

Right?

This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.

Syntax

Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then

ponyville_trot: Six cartoon ponies in a huddle (Default)
[personal profile] frith posting in [community profile] ponyville_trot
rarity1

In the interest of Being Excellent and considerate of those who plan to watch this episode, all references to the content of this episode are stashed under the cut and will remain so hidden for at least a month. Someponies like to watch MLP:FIM in herds and it can be a while before they get all their ponies together. 8^) As spoilers are also likely to be in any comments: don't read if you haven't yet seen the episode unless you like being spoiled. When you're ready, drop in a comment and say what you thought of this episode!

After a month, I hope Episode Discuss posts will be so far off the top page that it'll probably take the tag to find them, so about a month after posting the cut will be removed. 8^) Sometimes I go back and drop in little extras into the posts, like comics and links to the music.

Broadcast starts at 11:30 am Eastern Daylight Savings Time, which should work out to 4:30 pm UTC, 8:30 am PST and maybe about 11:30 PM Down Under. Confused? Look at the PonyCountdown widget on the community page! At the moment there is less than an hour left to go.

Written by Nick Confalone. This is his fourth episode so far, he also wrote No Second Prances, Hearthbreakers, and the yak episode, Party Pooped.

For those of you following Twitter, you can follow writers Nick Confalone (Hearthbreakers), Mike and Will Fox (The Gift of the Maud Pie), Joanna and Kristine (Gauntlet of Fire) and Dave Polsky (Rarity Takes Manehattan). Other twits in the early morning chorus may include the likes of Meghan McCarthy, Jayson Thiessen (Supervising Director of MLP:FIM), Andrea Libman , the voice of Dragon Lord Ember Ali Milner, Big Jim (storyboard work, voice of Troubleshoes and Director of MLP:FIM), Mike Vogel and Josh Haber. The hashtag to watch should be #MLPseason6.


Review for episode 9, The Saddle Row Review, below the cut. )


Catch the show and throw in your two bits in the comments! Copy/paste your reviews into the comments, spread the wealth!

Watch The Saddle Row Review on DailyMotion, here and/or ye olde Youtube, here.


Download links for The Saddle Row Review: (I'll fill in the blanks later)
As seen on Discovery Family in 1080p: broadcast version (mp4).
In 1080p without logos: logoless.
In 1080p, without logos and colour corrected: colourful.
They're all mkv format files except for the broadcast version.

Read all the transcripts, including that of The Saddle Row Review over here on the MLP wiki of transcripts.

Clear, free, logoless screengrabs from the entire episode get uploaded to the episode wiki within days of broadcast on the MLP Wikia Gallery pages, here.

The links to official channels and purchasing DVD's and episodes are now in the community sticky. A Cantonese dub of MLP:FIM season one is now being broadcast free-to-air in Hong Kong on ViuTV. Broadcast time is every Thursday and Friday at 5 PM. See http://viu.tv/epg/99

Santa’s Love of Cheese

May. 20th, 2016 03:57 pm
[syndicated profile] pixiepalace_feed

Posted by Rosepixie

Today I want to share perhaps my favorite television commercial. The ad was part of a great campaign advertising cheese and was part of a series of ads all ending in either the tagline “Behold the Power of Cheese” or “Ahh, the Power of Cheese”. It’s from sometime in the late 1980s or early 1990s and was shown again during the holiday season for several years after that.

Besides being adorable, I love this ad because it tells a complete story in such a spare and simple way. There is very little dialogue and most of the ad spends time building excitement for what’s in the living room, which the little girl has seen already, but the audience doesn’t see until her parents show up. And then the dialogue at the end is only two lines long, but it tells us exactly what happens and leads perfectly to the tagline, “Ahh, the Power of Cheese”.

This isn’t the sharpest video, but it’s the best one I can find for this ad. If you know of a better video of it online that I can link to, let me know and I’ll update the post with it.

[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Jasper van Woudenberg, CTO North America, Riscure

Jasper has been doing white boxing for a long time - hacking assembly in a video game to get passwords for higher levels as a kid :-)

It's important to protect the keys. Is it possible to do it with just software? White-box cryptography -> secure software crypto in an untrusted environment. This is used today in Pay TV DRMs, mobile payments... How to apply this to software environments?

Protection against key extracton in the white-box security model. A technique that allows merging a key into a given crypto algorithm: described for the first time in 2002 by S. Chow, et al. Available for DES and AES. Lookup tables are used for applying mathematical transforms to data. A known weakness is cloning/lifting.

Once you start applying these, you will have a huge amount of lookup tables. Attaks for all academic WBC proposals focus on key extractions, types of transformations assumed known and concrete transformation and key unknown.  In real life, we do not know much about the design. 

You can do an attack on DES using fault injection. There is a challenge online for you to try yourself at whiteboxcrypto.com . 

Then we got a demo of the tool retrieving a DES key by using the fault injection.

Have been able to break all that they've tried with fewer than a 100 faults, except  one that uses output encoding.

If you can perform measurement of the crypto target, you have a good chance of getting the key.

For side channel attacks, no detailed knowledge is required. the only protection is a secret random input/output encoding.

to protect against side channel attacks: must prevent statistical dependence between intermediates and key. Typical countermeasures based on randomness difficult in white-box scenario. 

Make sure you obfuscate control-flow and data, add anti-analysis and anti-tamper countermeasures. 
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Matt Landrock, CEO, Cryptomathic

 What can we expect from embedded systems?  Internet of Things.... Things: PCs, Phones, Smartmeters,dishwashers, cars, apps.

 Often want to validate code running on the "thing" and enable the thing to carry out basic cryptographic functions.  Understanding that "things" in the IoT can mean pretty much anything security-wise (from high-end to low-end).  if security adds too much inconvenience or cost, it will be skipped or skimped.

HSMs are under-utilized in the IoT space. Crypto APIs tend to be complicated, auditing individual projects is expensive and key management is often over-looked.   

If we think about crypto as a service, then we only have one place to deploy the HSMs, and can get it right. In one deployment, the customer went from securing 3 applications with HSMs to over 180 with this model.

Need to make sure that all applications that need cryptography can receive service, but at the same time only provide service to legitimate users

Cryptomathic has built a crypto service gateway (CSG).  CSG shares HSMs between applications, helping us get away from silos.  this improves utilization of very expensive resources. In this configuration, HSMs can be added and removed, while the service still stays up.

CSG has a crypto firewall that only allows specified commands and by approved card holders, as defined by the security team. The product also focuses on making audit easy. It's in one place and easy to read.

They have created a Crypto query language (CQL), like "DO CODESIGN FROM Dev WITH DATA 01234".  This makes it easier for developers to use, encouraging them to use cryptography.

It is possible here to give crypto keys an expiry.  The CSG provides all key management and handles key usage policy.

Use key labels, so they ar eeasy to find using CQL. They are implicit. 


Overall, there are many more devices coming online and the easier we can make it for developers to do security, the more likely it is to happen.
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Apostol Vassilev, Research Lead–STVM, Computer Security Division, NIST

Crypto is going smaller and light weight, lightweight protocols, apis, etc.

In modern cryptography, the algorithms are known. Key generation and management govern the strength of the keys. If this isn't right, the keys are not actually strong.

In 2013, researchers could find keys from a smart card, due to use of low-quality hardware RNG, which was stuck in a short cycle.  Why was this design used? Didn't want to pay for a higher quality piece of hardware or licensing of patents.

Look at the famous "Mining your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", which found that 0.75% of TLS certificates share keys, due to insufficient entropy during key generation.

One of the problems is that there is a lot of demand for entropy when a system boots... when the least amount of entropy is available.

Estimating randomness is hard. Take a well-known irrational number, e.g. Pi, and test the output bit sequence for randomness - it will be reported as random (NIST has verified this is true).

Check out the presentation by Viktor Fischer, Univ Lyon, UJM-Saint-Etienne, Laboratoire, Hubert Curien: NIST DRBG Workshop 2016.

He noted that using the statistical test approach of SP 800-90B makes it hard to automte the estimation of entropy. But automation is critically important for the new CMVP!

The solutions - an entropy service!  NOT a key generation service (would you trust the government on this!?). Not similar to the NIST beacon.

Entropy as a Service (EaaS).   Followed by cool pictures :-)

Key generation still happens locally. You have to be careful how you mix data from a remote entropy server.

While analyzing Linux, they discovered the process scheduling algorithm was collecting 128 bits of entropy every few seconds. Why? Who knows.

EaaS needs to worry about standard attacks on web service and protocol, like message replay, man in the middle an dns poisoning.  But, other attack vectors - like dishonest EaaS instances. You will need to rely on multiple servers.

EaaS servers themselves will have to protect against malicious clients, too.

Project page: http://csrc.nist.gov/projects/eaas





[personal profile] mjg59
Github recently introduced the option to squash commits on merge, and even before then several projects requested that contributors squash their commits after review but before merge. This is a terrible idea that makes it more difficult for people to contribute to projects.

I'm spending today working on reworking some code to integrate with a new feature that was just integrated into Kubernetes. The PR in question was absolutely fine, but just before it was merged the entire commit history was squashed down to a single commit at the request of the reviewer. This single commit contains type declarations, the functionality itself, the integration of that functionality into the scheduler, the client code and a large pile of autogenerated code.

I've got some familiarity with Kubernetes, but even then this commit is difficult for me to read. It doesn't tell a story. I can't see its growth. Looking at a single hunk of this diff doesn't tell me whether it's infrastructural or part of the integration. Given time I can (and have) figured it out, but it's an unnecessary waste of effort that could have gone towards something else. For someone who's less used to working on large projects, it'd be even worse. I'm paid to deal with this. For someone who isn't, the probability that they'll give up and do something else entirely is even greater.

I don't want to pick on Kubernetes here - the fact that this Github feature exists makes it clear that a lot of people feel that this kind of merge is a good idea. And there are certainly cases where squashing commits makes sense. Commits that add broken code and which are immediately followed by a series of "Make this work" commits also impair readability and distract from the narrative that your RCS history should present, and Github present this feature as a way to get rid of them. But that ends up being a false dichotomy. A history that looks like "Commit", "Revert Commit", "Revert Revert Commit", "Fix broken revert", "Revert fix broken revert" is a bad history, as is a history that looks like "Add 20,000 line feature A", "Add 20,000 line feature B".

When you're crafting commits for merge, think about your commit history as a textbook. Start with the building blocks of your feature and make them one commit. Build your functionality on top of them in another. Tie that functionality into the core project and make another commit. Add client support. Add docs. Include your tests. Allow someone to follow the growth of your feature over time, with each commit being a chapter of that story. And never, ever, put autogenerated code in the same commit as an actual functional change.

People can't contribute to your project unless they can understand your code. Writing clear, well commented code is a big part of that. But so is showing the evolution of your features in an understandable way. Make sure your RCS history shows that, otherwise people will go and find another project that doesn't make them feel frustrated.

(Edit to add: Sarah Sharp wrote on the same topic a couple of years ago)
beable: (gonzo journalism)
[personal profile] beable
So My friend S and I had the following conversation by SMS at lunch
today:

S: I just got catcalled? Praised?? LOL
S: On my bike, waiting for a turn signal, and I hear "hey girl", I turned my head before I heard the rest. Saw the person in the car pull up next to me with a big grin and thumbs up and realized the rest of it was "way to use your hand signal" hahaha

Me: Praised sounds like an oversell.
Me: Actually that sounds humourous enough to be less creepy.

S: Well apparently my hand signals are noteworthy.

Me: Hey girl, you breath oxygen like a pro.

S: Lmfao

Me: Hey girl, you're mitochondria is really working it
Me: Hey girl, entropy ain't got nothing on you!
Me: I think I should start marketing my mad skillz to pick up artists

S: I can tell this is gonna be a meme

Me: We need art! Get me the best photo shoppers in ALL the land!

S: So long as I can be in your marketing video. LOL
S: We could do it with the great masterpieces ... Birth of Venus

Me: Lol does the birth of Venus breathe?

S: Hmm, good point, I don't think so. I'll have to think on this project awhile.

Me: Hey Girl, you keep being your hydrated self and visiting that portapotty!
Me: #IKnowSexy

S: I'm gonna choke on my lunch.
S: Hey girl, you pressed that elevator button like a pro.
S: Hey sexy, I love how you showed up for work today.
S: Hey sugar, way to go dipping that fry in that ketchup

Me: I think we need to stick with Hey Girl
Me: It's classic for a reason

S: Hey girl, the way you flinch when I call you girl makes my heart soar
S: Hey girl, your ability to spot a classic meme is on fleek

Me: I am so not cool[1]

S: Hey girl keep being your awesome not-cool self

At this point we diverged a little into talking about where each of us was having lunch (not included because of identifying information), and in the course of that, S speculated that the reason the 3 guys one table over had so far managed to refrain from commenting on how awesome her mitochondria was because they were clearly members of the clergy.

Me: Girl, they don't know what they're missing.
Me: You gave the bestest mitochondria
Me: Have. Damn autocorrect.

S: I literally in the literalest sense am lmfao in this restaurant
S: Gave works even better it sounds naughty

Me: lol. We are so awesome we need to sell this awesome.
Me: T-shirts

S: Hey girl if only you were a boy

Me: Jewellery
Me: Thong underwear[2]
Me: Thong sandals

S: Stawp. Stawp or they're going to kick my ass out.

Me: I'm laughing so hard I can't breathe
Me: Postage Stamps?

S: Well you can trademark sayings and them sell all that stuff on redbubble
S: Maybe not postage stamps
S: But miniskirts yes

Me: Postage stamp sized skirts

S: I can add these sayings to the banana skirt!
S: Ok I'm stepping away from this phone now

Me: Ok seriously if I remove identifying info can I post this to my blog?


1: I'm not, because I blinked at the word fleek
2: This got lost in the visual transcript because scrolled to overzelously in my phone


Alternatively, our SMS Conversation in a series of screenshots )
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

 Richard Wang, FIPS Laboratory Manager, Gossamer Security Solutions, Tony Apted, CCTL Technical Director, Leidos

Entropy is a measure of the disorder, randomeness or uncertainty in a closed system.  Entropy underpins cryptography, and if it's bad, things can go wrong.  Entropy sources should have a noise source, post processing and conditioning.

There is a new component in the latest draft of SP 800-90B that is discussing post processing.  there are regular health tests, so any problems can be caught quickly.

There are 3 approved methods for post-processing: Von Neumann's method, Linear filtering method, Length of runs method.

The labs have to justify how they arrived at their entropy estimates. There should be a detailed logical diagram to illustrate all of the components, sources and mechanisms that constitute an entropy source. Also do statistical analysis.

When examining ISO 19790, their clauses on entropy seemed to line up with FIPS 140-2 IG's - so if you meet CMVP requirements, you should be ready for ISO 19790 (for entropy assesment).

Common Criteria has it's own entropy requirements in the protection profiles. The Network Device PP, released in 2010, defined an extensive requirement for RNG and entropy. You have to have a hardware based noise source, minimum 128 bits of entropy and 256 bits of equivalent strength.

The update in 2012 allowed software and/or hardware entropy sources. It was derived from SP 800-90B, so very similar requirements.

Entropy documentation has to be reviewed and approved before the evaluation can formally commence.

Some vendors are having trouble documenting thrid party sources, especially hardware.  Lots of misuse of Intel's RDRAND.








[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Allen Roginsky, CMVP NIST

There are power-up tests and conditional tests. Power-up includes integrity test, approved algorithm test, critical functions tests.  Conditional are things like generating key pairs, a bypass test.

Implementations have become more robust, and integrity tests no longer take just a second or so - may be minutes.

Imagine a smartcard used to enter a building.  If it is too slow, it may take 5-10 seconds... then the next person... the next. Quite a traffic jam

We don't want to drop the tests altogether, so what do we do?  What are other industries doing?

Supposed the software/firmware image is represented as a bit-string. The module beraks the string into n substrings; n is no greater than 1024. the length, k bits, of each of the first (n-1) substrings is the same; the length of the last substring is no greater than k.  Then, maybe you can just look at some of the strings.

A bloom filter optimization can significantly improve the efficiency of this method.

You could use a deterministic approach. You would have to keep track of the location where you ended, and hope that location doesn't get corrupted.

CMUF is working on an update to Implementation Guidance on doing integrity check from random sampling.

Vendors do not want to perform each algorithm's known answer test, not just delay until first use of algorithm. Why are we doing this test in the first place?  Something to think about.

Another option offered by a questioner: maybe replace with on demand testing? Is a good option.
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Denis Gauthier, Oracle

OpenSSL provides entropy for the non FIPS case, but not for the FIPS case.

BYOE - Bring your own entropy, if you're running in FIPS mode.

OpenSSL gets its entropy from /dev/urandom, /dev/random, /dev/srandom, but since /dev/urandom doesn't block, that's effectively where OpenSSL gets most of its entropy.  And it never reseeds. We likely didn't have enough when we started, and certainly not later.

Reseeding: not everyone will get it right... there are too many deadlines and competing priorities.  Looking at an ubuntu example, based only on time(0)... not good entropy.

There is no universal solution - the amount varies with each source and its operating environment. Use hardware, if it's available. Software will rely on timers - because, hopefully, events don't happen at predictable times (not to the nanosecond).

There is a misconception that keyboard strokes and mouse movements will give you a lot of entropy... unless the machine is a headless server... :)

You could use Turbid and Randomsound to gather entropy from your soundcard.

There are a lot of software sources, like CPU, diskstats, HAVEGED, interrupts, IO, memory, net-dev, time, timer-list and TSC. Denis had a cool graph about how much entropy he was getting from these various places.

You need to do due diligence, doing careful evaluation of your sources. Things are not always as advertised.  Not just convincing yourself, but making sure the folks you're selling to trust your choices as well.

The best thing - diversify!  You need multiple independent sources. Use a scheduler to handle reseeding for forward secrecy.  But, be careful not to starve sources, either.

When using OpenSSL, bring your own entropy and reseed.


ICMC16: LibreSSL

May. 19th, 2016 12:25 pm
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Giovanni Bechis, Owner, System Administrator and Developer, SnB, Developer, OpenBSD

The LibreSSL project started in April 2014, after heartbleed was discovered in OpenSSL. Man vendors and systems were impacted by this, and there is no way to tell if you have been attacked or not.  Why did this happen? The OpenSSL code was too complex.  Thought - should we try to fix OpenSSL or fork?

Fork was decided because the fork was too complex and intricate. This has changed more recently, but in April 2014 the OpenSSL developers were only interested in new features, not in bug fixing. Heartbleed wasn't the only reason we decided to fork, it was just that the code was too complex. For example, OpenSSL doesn't use malloc, and the allocator it does use doesn't free memory.  It uses LIFO recycling.  The debugging features in their malloc are useful for debugging but could be used attack.

At the time, pretty much all OpenSSL API headers are public. Many application developers were using interfaces they should not have been exposed to. It uses it's own functions, instead of things provided by libc, etc

There is a lot of #ifdef preprocessing code to work around bugs in compilers or on specific systems.

Forked from OpenSSL 1.0.1g. Have been backporting bug fixes from that tree.

OpenSSL is the "de facto" standard and widely used. It is difficult to get patches applied upstream. They wanted to preserve the API to maintain compatibility with OpenSSL.

They want to make sure they use good coding practices and fix bugs as fast as possible.

No FIPS support, mainly because their developers are not in the US.  They have removed some old ciphers (MD2, etc) and add ChaCha20 and Poly1305.

Removed SSLv3 support. Removed dynamic engine support, mostly because there were no engines for OpenBSD so they could not test.

OpenSSL is portable, but at the expense of needing to reimplement things that are found in most implementations of libc and lots of #ifdef and #ifndef.

Some of the OpenBSD software has been switched to use libressl, like the FTP client software. 

ICMC16: The OpenSSL 1.1 Audit

May. 19th, 2016 12:04 pm
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Kenneth White

There is an Open Crypto Audit Project. Originally formed to do an audit of the TrueCrypt audit.  Currently seeking non-profit status.  More recently looking ath OpenSSL.  Why? It's everywhere!

OpenSSL 1.0.2 FIPS is in over a 100 validations.

Enterprise people often say they don't care about FOSS, don't realize it's deployed very widely in their enterprise!  Like Cisco VPN client.

The audit of OpenSSL was commisioned by the Linux Foundation.  A pretty ambitious scope.

Most of the code in OpenSSL is written in C (70%), and currently has about 8 million lines of code. (that's a lot to audit!)

FIrst look at BigNum, BIO (focus on composition and file functions), ASN.1 and x.509 and 93M cert corpus, and "frankencert" fuzzing.

Next phase will cover the TLS state machine, EVP, protocol flows and core engine implementation, memory management and crypto core (RSA, SHA2, DH/ECDEH, CBC, GGM).

Need to focus on most relevant platforms and algorithms and protocols.

Preliminary findings:
Complexity led to some potential bugs invalidated due to pre- or post- target parsing.  PEM parsing contained unexpected formats including access to ASN.1 decoding facilities, HMAC and CMAC algorithms. Memory leak and integer overflow identified, but very unlikely invalid or low severity issues.  RSA uses blinding and constant time operations by default.

From the fuzzing work, found found 280 certificates that had very bizarre dependencies that resulted in diverse paths being taken.  The fuzz testing for x.509 parsing did not result in any crashes.  Did find bugs with some DER fuzzing, related to performance, but the right things seemed to happen.

Still looking at low impact, low likelihood, low severity potential vulnerabilities, but overall the code is looking very solid.

As Poly1305 and CHaCha20 were added recently, we'd like to take another look.

ICMC16: OpenSSL Update

May. 19th, 2016 11:37 am
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Tim Hudson, Cryptsoft

The OpenSSL team had their first face to face meeting, ever! 11 of the 15 members got together digging into documentation and fixing bugs - and POODLE broke, so... they got to know each other quite well.

The team thinks of time as "before" April 2014 and after... Before there were only 2 main developers, entirely on volunteer basis.  Nor formal decision making process, extremely resource limited.  After April 2014, now have 2 full time developers and 5-6 regular developers.  This really helps the project.

After a wake-up call, you have to be more focused on what you should be doing. Everyone is now analyzing your code-base, looking for the next heartbleed.  Now there is more focus on fuzz testing, increased automated testing. Static code analysis tools are rapidly being updated to detect heartbleed and things like heartbleed.

New: mandatory code review for every single changeset.  [wow!]

The OpenSSL team now has a roadmap, and they are reporting updates against them.  They want to make sure they continue to be "cryptography for the real world" and not ignore "annoying" user base for legitimate concerns or feature needs.

Version 1.0.2 will be supported until 2019.  No longer will all releases be supported for essentially eternity.

OpenSSL now changing defaults for applications, larger key sizes. removing platform code for platforms that are long gone from the field.  Adding new algorithms, like ChaCha20 and Poly1305. The entire TLS state machine has been rewritten.  Big change: internal data structures are going to be opaque, which will allow maintainers to make fixes more easily.

FIPS 140 related work paid for OpenSSL development through 2014.  It is hard to go through a validation with one specific vendor, who will have their own agenda. 

There are 244 other modules that reference OpenSSL in their validations, and another 50 that leverage it but do not list it on their boundary.

The OpenSSL FIPS 2.0 module works with OpenSSL-1.0.x. There is no funding or plans for an OpenSSL FIPS module to work with OpenSSL-1.1.x.

The hopes are that the FIPS 3.0 module will be less intrusive.

If you look at all the OpenSSL related validations, you'll see they cover 174 different operating environments.

How can you help? Download the pre-release versions and build your applications. Join the openssl-dev and/or openssl-users mailing lists. report bugs and submit features 

If FIPS is essential to have in the code base, why hasn't anyone stepped forward with funding?


[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Donald Malloy, LSExperts

For years, Mastercard and Visa said the cost to implement the chips in cards cost more than the fraud, but that has all changed in recent years.  EMV (Chip and Pin) is being rolled out in the US, which will push the US fraud to online (can't use the chip).

Fingerprints are non-revocable. Someone can get them from a picture or hacking into a database.

OATH is an industry consortium, the algorithms are free to use.

They have started a certification program, so we can verify that vendor tokens work together.

Why is OTP still expensive? Comes in soft tokens, hard tokens, usb tokens, etc.  Cost per user has consistently been too high, manufacturers continue to have a business model that overcharges the users. OATH is giving away the  protocols - so why still so much?

working with LinOTP - fast and free.

Since biometrics are irrevocable, how do we get stronger passwords? Could we use behaviour analytics? type a phrase and the computer will know it's you.

 




[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Yongjin Yeom, Kookmin University;Seog Chung Seo, National Security Research Institute

NSR is the only company testing in Korea.

We have vendors, testing authority and certification authority. NSR tests according to Korean standards. NSR develops and standardized testing methodology with vendors.

KCMVP started in 2005, using their own standard. Staring in 2007, leveraged international standards.

116 modules have been validated. There are more software validations than hardware validations. Most of the software validations have been in C and Java.

The process overview of KCMVP looks very similar to CAVP combined with CMVP in the US/Canadian schemes. There are algorithm verification, tests of the self tests, etc ;)

They have a CMVP tool to automatically verify algorithm correctness.

Just like here, there are big concerns about entropy sources. It's hard to get entropy to scale, so they want to discover the limits of entropy source.
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Di Li, Senior Consultant, atsec information security corporation

Please note: Di Li works for atsec, and is not speaking for the Chinese Government.

Their focus is on certifying both hardware and software, including HSMs and smart cards.  In China, only certified products can be sold or used. They should be sold commercially. By law, no foreign encryption products can be sold or used in China.

Additionally use their own algorithms. Some are classified, others leverage international algorithms like ECC, others would be considered a competitor to algorithms like SHA2 or AES-GCM.

They have their own security requirements for cryptographic modules, but there are no IGs, DTRs, etc., so it is different. No such concept of "hybrid", either.

There are two roles in the scheme: OSCCA and vendor. OSCCA issues the certificates and they are also the testing lab.  The vendor designs and develops the product, sell, and promote.  They report their sales figures to OSCCA every year.

There are requirements to be a vendor as well! To get sales permission, you need to demonstrate you are knowledgeable in cryptography among other things. 

Validations are updated every 5 years. As a part of this process, you additionally have to pass design review.

You cannot implement cryptography within a common chip , as there is not enough security in that chip.

Banking must use a certified products. The biggest market is USB tokens and smart cards.
[syndicated profile] valerie_fenwick_blog_feed

Posted by Valerie Fenwick

Apostol Vassilev, Technical Director, Research Lead–STVM, Computer Security Division, NIST
Barry Fussel, Senior Software Engineer, Cisco Systems

Take a look at Verizon's Breach report. It's been going on for 9 years, and we see things are not getting better. It takes attackers only minutes to subvert your security and they are financially motivated.  Most of the industry doesn't even have mature patching process.

We hope validation can help here, but vendors complain it takes too long, the testing depth is too shallow, and it is too costly and rigid.

In the past, we leveraged code reviews to make sure code was correctly implemented. Data shows that code reviews, though,  only find 50% of the bugs.  Better than 0, but not complete. Can we do better?

Speeding up the process to validate, allows people to validate more products.

Patching is important - but the dilemma for the industry is "do I fix my CVE or maintain my validation?" This is not a choice we want our vendors to make.  We should have some ability for people to patch and still maintain validation.

The conformance program needs to be objective, yet we have different labs, companies and validators relying on these written test reports. This is a very complex essay!  Reading the results becomes dizzying.  We want to improve our consistency and objectivity, how can we do this?  So, we asked the industry for feedback on what the industry looks like and how we could improve the program. We started the CMVP working group.

The problem is not just technical, but also economical. To make changes, you have to address all of the problems.

Additionally, we need to reconcile our (NIST's) needs with NIAP's (for common criteria). 

And a new problem - how to validate in the cloud? :)

The largest membership is in the Software Module sub group - whether that is due to the current FIPS 140-2 handling software so poorly, or reflective of a changing marketplace is unclear.

Fussell took us into a deep dive of the automated run-time validation protocol. 

The tool started out as an internal CIsco project under the oversite of David McGrew, but didn't get a lot of traction. Found a home in the CMVP working group.

One of the primary requirements of this protocol is that it be an open standard.

Case example: Cisco has a crypto library that is used in many different products. First they verify that the library is implemented correctly, but then they need a way to verify that when products integrate it they do it correctly.

The protocol is a light weight standard's based protocol (HTTPS/TLS/JSON). No need to reinvent the wheel.

Authentication will be configurable - multi factor authentication should be an option, but for some deployments you won't need a heavy authentication model.

And Barry had a video! (hope to have linked soon)

If things are going to be as cool as the video promises, you'll be able to get a certificate quickly -from a computer. :)  And if you find a new

[syndicated profile] jeremiahgrossman_feed

Posted by Jeremiah Grossman

A couple times a week, people I may or may not know reach out to me for help because they’re experiencing some kind of computer security catastrophe. Sometimes the situation is serious, other times not. They might be dealing with an online bank account takeover, online scam, data breach, malware infection, identity theft, and the list goes on and on from there. Whatever the circumstance, a great many people often find themselves thrust into the deep end of this technology driven world, without the know-how to solve the problem on their own, and no one to call for help. These experiences are especially painful for the elderly and small-business owners, whose livelihood are disrupted, and the stress takes a toll on them. Personally, I hate it when good people get taken advantage of.

In the most recent case, I was introduced to the founder of a TV and movie production company through a mutual friend. They explained that someone is messing with their website and actively using their company name to scam their business contacts. They said ‘hacked,’ but that could mean anything these days. The situation was causing them real brand damage, and with over a dozen show titles to their credit, the business impact is severe. Even over the impersonal medium of email, you could sense a deep feeling of helplessness and desperation. As you might expect, I tend to keep myself happily occupied with family, work, and martial arts and don’t have a lot of time to spare for things like this. But, this plea originated from a good friend, the victim didn’t have anyone else to turn to, and helping out felt like the right thing to do.

After taking a call and exchanging a few emails, I got the real story. Someone, a scammer, registered an incredibly similar domain name to the legitimate one used by the production company. The fake domain name was being used to create a clone of the real website. The scammer then subtly changed the names and photos of the staff and updated the contact information so that any incoming communication would instead go to them. Through email, phone calls, or search results visitors would be contacted by the scammer, who pretended to be with the production company, and would proceed to con their victims out of money. This is a simple, inexpensive, and effective scam that could happen to basically anyone – and it does.

The near-term plan was to get the scam website taken down. Long-term, try to take ownership over the look-a-like domain name.

To start, the first thing I needed to know is who owns the offending domain name. A quick WHOIS lookup revealed the registrar is GoDaddy, but the domain owner itself was masked by Domains By Proxy, a popular service for those wishing to preserve their online privacy. I often use this service myself! This means without going through a legal process, obtaining the real domain owner information isn’t going to happen. Still, in the event the production company would like to try and get ownership over the domain using ICANN’s and trademark law, they have the registrar info to further that process. Next, I needed to identify where the website is being hosted. The ‘dig’ command easily gets me the IP address of the cloned website and an ARIN lookup tells me who the IP address belongs to — the name of the hosting provider. For those curious, collectively performing these tasks took me far less time than writing this paragraph.

Let’s pause our story for a moment to consider the technical knowledge required to get this far, which includes a set of skills many techies take for granted and forget that the vast majority of people simply don’t have. Few people can explain what a domain name is, have any idea what a domain registrar or an IP address is, what’s WHOIS, or even ICANN. They’ve certainly never heard of ARIN, and only a vague familiarity with hosting providers for that matter. And thus far, we’ve only collected purely public information and in doing so reached a point where most can’t get to on their own. Techies should empathize and exercise patience with those not nearly as literate in how the Internet works as we are. Anyway, back to our story.

Now that we’ve learned who the hosting provider is, I helped the production company founder draft an email to send that concisely explains the problem and what we’d like the action to be. Take down the website! Their website nicely listed the abuse@ email address and I pressed send on the message. I figured it could be a while for them to get back to us, and in the meantime decided to take a close look at the scammer’s website.

Using every web hackers best friend, view-source, I skimmed the underlying code of the website. Maybe the scammer left clues as to their identity, tools they used to clone the website, or whatever. In less than 60 seconds, I immediately spotted something very interesting. While the HTML of the page is hosted locally, all the CSS, images, and most importantly, the Javascript is being SRC’ed in from the real website! As you’ll see if a moment, this was a major oversight on the scammer’s part. Are you thinking what I’m thinking? We’ll see. :)

1)    In the logs of the real website, we should be able to ascertain who and how many people visited the scammers website. Because every time someone visits one of his web pages, their browser automatically pulls in the aforementioned third-party content from something we control. This means the visitors IP address is logged, as is what web page they are currently looking at — called the referer. And yes, this is intentionally misspelled and a throwback to Internet antiquity.

2)    If we have the visitors IP address information, it’s quite likely we also have the scammer’s too! Provided they didn’t mask that as well. And if they are, that’s useful bit of information as well. Either way, their IP address is probably the first one we see the in the logs when the referer of the fake website appeared. If we decide to go after the bad guy directly, we at least have something to begin tracking them down with. Subpoenaing the hosting provider or Domains By Proxy is of course another possible course of action, but we’ll see about that path later.

3)    This is the big one. Any web hacker would have quickly theorized that we can probably modify the javascript on the real website, which again is called by the fake website, to at least temporarily redirect it’s visitors. And, that’s exactly what we did! A quick 3-line block of code did just the trick!

if (window.location.host != ‘<real-website.com>') {
        window.location = ‘<real-website.com>’;
}
 
At this moment, we got the production company and visitors of the scammer’s website some immediate relief. That is until the bad guy notices what we did and updates their website code, which is trivial to do. Next I ask the domain registrar (GoDaddy) about the process for taking ownership over domain names that are designed for abuse. They point us towards an ICANN’s trademark dispute policy and suggested we consult with a lawyer experienced in such legal measures. I then advise the founder to seriously consider going down his route.

A couple days go by, and while we wait for the hosting provider to respond, we notice the aforementioned redirect stopped working. As expected, the scammer caught on and fixed their code so that all the web page files now point locally. Drat! What we did learn is the scammer is sentient, responsive, and persistent. He didn’t care so much that were we onto his little game. Interesting. Such brazenness indicated that the scammer is probably outside the US jurisdiction – or optionally just stupid. Then like magic on the same exact day, and the timing could not have been better, the hosting provider informs us that they completed their investigation and disable the scammers website. Success!

For now, my work is done and the production company founder profusely express their thankfulness. This was a good feeling. However, that doesn’t necessarily mean this is the end of our little story, or that it will be a happy one. After all, this is the security of the web we’re talking about, and plainly said, it’s fundamentally broken.

You see, the scammer can easily set up shop with a new hosting provider and start the identical scam all over again and there is absolutely nothing anyone can do to prevent that. There is no good way to help visitors tell the difference between the real website from the fake one. And even if we use ICANN’s process to take ownership over the domain name, the scammer could easily just register another suitable look-a-like domain in no time flat and we’re back at it all over again. This problem is never ending and there really is no good way to solve it once and for all. A website owner’s only option is to wait for something bad to happen, give me or someone else with the right skills a call for help, and proceed similarly.

What I can do is actively monitoring the illegitimate domain name to see when and if it’s IP address changes. If it does, this would indicate that the scammer is moving hosting providers. It took a couple weeks, and that’s exactly what appears to be happening right now. Grr. This is kind of thing happens every day, to who knows how many people, and honestly I’m not sure what the answer is. One thing I do know, the world needs the help of a lot more good computer security people. Join in!



Profile

terriko: (Default)
terriko

April 2016

S M T W T F S
     12
3 456789
10111213141516
17181920212223
24252627282930

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 28th, 2016 11:49 am
Powered by Dreamwidth Studios