LCA 2017 Day 3

A good start to the day with the announcement of the commutation of the bulk of Chelsea Manning’s sentance, which is a nicely positive story from the States. It’s been a few days of having good luck photographing wildlife.

Using a keyboard, PocketGit, and DroidEdit with my phone for note-taking has been working very well; it’s a much more convienient bundle to carry about that a laptop, but has the happy side effect that it’s much harder to get distracted from the talk by alt-tabbing to social media, email, etc etc than with a lappy.

Opening

My photo of the dolphins that showed up beside the venue got on the opening slides. Squee!

Kathy Reid celebrated her ascendancy to the Linux Australia presidency by calling out Michael and Michael for their awesome work on the papers committee for more than a decade.

The raffle is only at 25% of its target after 40% of the conference. Boooooo!

Designing for Failure

Dan Callahan

“What I’m about to share are my personal reflections”, not the official view of Mozilla or the former Persona team.

Mozilla is particularly concerned with keeping the web open and accesible, to protect the Internet as a public resource and a platform. Mozilla’s work on Firefox, as their best-known project, is not just about having a FOSS browser, but to ensure an organisation with openness has a stake at the table when the future of the web is being discussed.

Persona was designed to solve the problem of authentication on the web, providing the ability to provide a decentralised auth system that could work with any email domain, rather than locking providers and users into a particular corporate such as Google or Facebook.

Authentication Matters

“I want to convince you that this was an important and necessary piece of work for the web.”

• Revisit the state of things 5 years ago: per-site logins were breaking under breaches and hacks. Users rarely follow good password hygiene, and many companies were doing a poor job on their end.

• Social authentication began to emerge; for example authing through Facebook. While it was great that we were killing the password was great, seeing this fold into a world where, say, Spotify would only allow social login.

• 500px was an example of an alternative strategy; allowing social logins, but also a traditional email/password as a fallback.

• Unfortunately this imposition of a third party imposes the T&Cs of the third party in order to use your service. If your user doesn’t make Facebook happy - by eliminating anonymity and pseudonymity, for example - then they will lose acces to your site.

  • Dan offered the example of Indigenous American leader Kim TallBear was suspended from Facebook. She demonstrated that her name was legally TallBear - but Facebook wanted more proof that her name was valid.

• Persona was an innoculation against this, to provide a social login that is also under the control of the user.

• Unfortunately, Persona failed.

• Dan is a cave diver. Cave diving is a difficult and dangerous passtime - it requires specialised training and experience on top of the basic diving and experience. Dan thinks that the ideas that have reduced fatalities are things we could learn from.

• The Five Rules of accident analysis:

  • Never exceed your training.
  • Maintain a continuous guideline to open water.
  • Reserve two thirds of your gas for exiting.
  • Never exceed the maximum operational depth of your gas.
  • Carry three lights.

• Soon, Persona will drop off the Internet, and that’s sad. But we don’t have a culture of learning from our mistakes - we need to discuss them so we can do better next time.

Free Licenses are Not Enough

• Licenses, in and of themselves, are not sufficient to allow your users to carry on when your fail or lose interest, or to fork their own. You haven’t ensured their freedom.

• Persona had inadvertently designed in a point of centralisation: there needed to be a central relay between the web site and the email provider. While there was a plan to make the relay a browser extension - but that never happened.

  • If you fork the project, you have to fork the community; the web site has a baked-in assumptiont that it will use the Mozilla persona server.

• Bits rot more quickly online

  • If the LibreOffice team went away, you still have the binaries. They stop updating, but at least you can keep using it.
  • Compare with what happens if WordPress stops being updated - how long is it before the unpaid hosting bills and unpatched software burns it all down.
  • The answer is not to abandon the web - but what is? Dan notes if he had an answer this would be a tutorial, not a keynote.

• Complexity Limits Agency

  • People are not meaningfully empowered if the skills required to even set it up are too exotic or specialised.
  • You may, in fact, be solving it for the people who least need to be helped.

Prolong Your Project’s Life

• Measure the right thing. Are we infrastructure? Are we a product? Are we pitching things the right way.

  • Persona was set up and measured as a product. So metrics - number of users, deployed sites and so on - were measured as a product, and as a product it was a failure.
  • But it was successful as infrastructure. If it had been staffed and funded as an infrastructure project, maybe it would still exist.

• Explicitly define and communicate your scope.

  • Many of the flows and behaviours didn’t work well with the sites Persona was supposed to be serving.
  • Persona got roped into auth for FirefoxOS - but it wasn’t a great fit, and trying to make it work wasn’t good.

• Ruthlessly oppose complexity.

  • As the scope crept beyond the vision, the code became needlessly complex, making it harder and harder to work on, and almost impossible for contributers to join in.
  • If you want other people to help, if you want to leave a legacy, you need to eliminate complexity.

The complexity of Persona meant that there were only one or two non-Mozilla contributers able to help out.

Plan for Your Projet’s Failure

• On a long enough timeline, everything fails.

• Sometimes the bus factor is the commuter bus that takes them to another job.

• The best time to plan for failure is at the start of the project.

• If you know you’re dead, say so.

  • It took three years for the Foundation to go from having removed all the staff to acknowledge it was now dead.
  • There’s a fear that admitting a thing is done for you, will kill it.
  • But by not cleanly killing Persona, Mozilla killed other projects - because they’re waiting for Mozilla to come back to Persona. And it never happened. But neither to those other projects.
  • The sooner you admit you’re dead, the sooner other people can start preparing to replace you.

• Ensure your users can recover, without your involvement.

  • The chances of you mustering the energy to help users cleanly exit are slim to none.
  • The failure of a project is shattering. You’re going to be miserable - how likely is it you’ll feel like hand-holding the people jumping into the lifeboats, write up what they need to know?
  • For Persona it turned out the people who were most active in helping that clean exit were non-core contributers, who had enough to knowledge to help people leave, but weren’t closely enough involved to be burned out.

• Use standard data formats.

  • For example, NewsBlur will let you export OPML, a standard format that other readers can use. That’s failure-proofing for the users.

Minimize the harm caused when your project goes away. Consider this when we build networked services and free software.

To summarise:

1. Auth is an important open problem.
2. Free licenses don’t ensure functional freedom.
3. Define your scope and solve a simple problem.
4. Conciously consider your project’s death; minimize harm.
5. Talk about failure.

Future Privacy

Michael Cordover

Software engineer at Etsy, with a legal background (“Australian lawyer, American programmer”). Not representing Etsy’s views. Likes PHP and Haskel.

Some History

• Right to be let alone (solitude).
• Personal papers (secrecy).

This is a relatively recent concept, legally speaking. The right to personal papers, for example, was in the US consitution, but the right to be let alone emerged in the 19th century.

With a shift in technology, we now think about some additional rights tied back to them:

• Anonymity.
• The right to be forgotten.

These ideas have become more important primarily as a result of the vast expansion of technology; the right to be forgotten is a counterpoint to a world where it is easy to record, to gather information about people, and to make it easy to discover.

Where the law went wrong

• Big change is hard.
• Technology is hard.
• Names aren’t that important.

We can track without associating with your real name (which is much of the Australian legislation is concerned with). The framework focused on the legal name as an identifier is pointless when we can uniquely identify people by a GUID. You can be identified and profiled even in a reputational system that you can’t see and don’t participate in.

• Do you consent?
• When?
• To what?

While consent is an important idea in our day-to-day basis in the technology sphere much of the consent is not informed consent. “Do you consent to the use of your information?” is all very well, but no-one can be expect to understand how companies are feeding your information into models, neural networks, reputational scoring systems.

Consent also implies you are agreeing before information is being gathered, but this is not how the web works - you’ve visited the site before you know you have to consent.

Consent must be able to be withdrawn for it to be useful, and the way companies are building their system makes this effectively impossible.

Often the disclaimer is boilerplate that is used in many places - but two organisations can use the same legal language to cover very different use cases for your information. And that’s partly because it’s practically impossible to come up with a simple-to-read privacy policy which will also accurately describe what the organisation is doing.

Even if you get it, does it matter?

Often we like the services provided, but they’re only possible with the intrusive data collection. But there are risks, and many of us don’t understand what the trade-offs are.

The information that you can use to find your car from your “where have I been” can also show which doctor you went to yesterday. And that’s problematic. It hands significant power to the entities with that information, which may be the company, or it may be the government.

And this is just what we see

Tapad: correlating multi-device profiles for single individuals to try and build comprehensive profiles and smash the segregation people might try to have between their work and home computers or phones, for example.

These information dragnets, corporate, or governmental, are hard to avoid and as the technology makes it easier and easier to mass-monitor. As the cost of surveillance plummets, why not monitor everyone?

What is to be done?

• Force people to own their own data. But is that practical? Owning your own data is really hard.
  • If your answer is “all you have to do is put a server in your basement, and install linux, and install pump.io” they will ask you, “Why don’t I just use Twitter?”
  • Remotely hosted services are popular because it’s easier.
• So if that’s not a solution:
  • Open systems.
  • Decentralisation.
  • Federation.
  • Non-permissive by default.
• What sites do is way too much.
  • Do one thing and do it well.
  • Or nobody will even understand what you do.
• But what that really means is:
  • Ban Google analytics.
  • Ban facebook.
  • Stop digital by default.
  • Go back twenty years.
  • That’s probably not going to happen.
  • Because we don’t want to give up the benefits.

Nothing. Sorry.

An Introduction to .NET Core on Linux & Docker

Tod Thomson

Tod’s notes are available on Github if you’d like to work through them at home.

Handle Conflict, Like a Boss!

Deb Nicholson

“Like a boss: with confidence and certainty, so you don’t have to be the boss.”

• A lot of conflict comes from missing information.
  • One week, Alice paid the phone bill and left a message for Bob saying he needed to pay his share of the bill.
  • A week later, Alice had heard nothing, so left increasingly angry notes about the unpaid phone bill.
  • Deb had to explain that “Bob is out of town at his grandmother’s funeral.”
  • The sticky notes quickly disappeared.

Sometimes conflict can be resolved by something as simple as better information.

Conflict is Natural

• Without conflict you turn into Reavers and eat people. Or maybe not.

• But conflict happens because people have different ideas. Conflict needs to be handled.

• Mismatched goals are a common cause of conflict: people may be on the same project or in the same organisation, but you may have very different ideas about what the right outcome is.

  • Understanding one another is a key thing for defusing this conflict.
  • Try to understand the other person and their context; try to help them understand where you’re coming from.

• Identity - when people identify with a particular role heavily, changes to that role, or risks to the existence of the role will generate resistance.

• You may need to go deep: people may not tell you what is bothering them.

• Could we just… not? You will be trampled and steamrolled if you don’t learn to push back constructively.

• Conflict lovers: if you don’t tackle conflict, if you don’t push back, people who love conflict will come to you. You will become a jerk magnet.

• “There are many FOSS projects, but only one me.” @sarahsharp

  • There is no FOSS project, or job, worth your health and wellbeing.

Identify the obvious and less obvious causes

• Three different styles of handling conflict.
  1. Avoidance.
     • Walk away, stop talking.
     • Sometimes this is actually valid - but often it’s counter-productive.
     • It can lead to festering, disconnection.
     • It also acts as support for the status quo, for bad stuff.
  2. Accommodation.
     • When someone would rather be liked than fix things.
     • People compromised when they shouldn’t.
     • Accommodation might lead to the false middle - “let people be mean on 3 days of the week, but require nice behaviour 3 days.”
     • It looks like you don’t take the problem seriously.
  3. Assertion.
     • Can look like aggression.
     • A person who digs in when there is conflict.
     • It can manifest as competitive, ego-driven responses.
     • Over time this wears everyone else around the person who loves to assert.
     • Eventually people stop telling you things - which is especially bad if you’re supposed to be a leader.
     • “Oh, that’s the shouting project.”
     • “If you want that, I’m not telling you how to live your live…”

The more you know…

The more you know about what’s going on, the more likely you are to be able to resolve conflict. * But don’t just assume you know what’s going on the basis of a drive-by.

So what are the some sources of conflict:

• History: if people don’t know the history, sometimes they act without proper context.
  • “Why are we doing that thing?”
  • You may not know that someone is always consulted about a thing.
  • A solution: use historical motivations to get buy-in for new strategies.
• You don’t know their motivation - they look like they’re behaving randomly or irrationaly.
  • A solution: ask about the other person’s motivations.
• Fear.
  • It might be a threat to identity.
  • “What’s the worst that could happen?”; move slowly and try to tease the root of the fear out.
• Right place, wrong time.
  • Unproductive meetings.
  • Misdirected emails.
  • Wrong audience.
  • Help everyone get perspective - change the location, bring in a third party.

What do you do with all this information

• Put yourself in the other person’s shoes.
• Find alignment - what are your common goals? Reiterate them and try to negotiate in light of that.
• A word about who is doing this work: don’t let it slip into someone by default without rewards and recognition. If it’s something that always needs doing, have it be the role of someone who wants to do it.

Avoiding future conflicts

• Assuming the best.
• Set expectations about wht behaviour is acceptable.
• No ad hominem. It’s really hard to put that toothpaste back in the tube.
  • Especially important for project leaders; groups take their cue from you.

Conflict Resolution Amongst groups

• Set an example.
• What could we accomplish if we worked together?
  • If we didn’t bash each other’s tools, and projects and things.
• More face-to-face.

Q&A

• Is there a point where you eject a person? Yes. Absolutely.
• How do you resolve conflict is a FOSS project is split evenly? Well, you may have to fork; “I don’t say that lightly”, but if goals are completely different, peopel may have to go their own seperate ways.
• If there’s been a blow-up and it comes up again six months later, how do you deal with that? Try to head that off: explain the issue is settled, and that it needs to be park from the meeting/mailing list/etc.
• What if the problem person is the BDFL? A coup probably won’t help. You can try explaining to the person the problems they cause, but you may have to exit.

274f626f5cdff925639f400f611f183b996162be