Basic scripting etiquette and how to respect privacy

[michaelcoyote]

There was some talk on wall chat today about privacy and respect for the space of others along with how scripts should act.

The thing that set off this discussion was that someone ran a script that fingered all active users, which is fine, but then put it in their public_html. This was called out and the file was taken down, but this did set off a useful discussion on what is allowed, etc.

There was also some discussion of the post @ftrain did today.

Some of the thoughts in no particular order:

• Anything internal to the server (e.g. finger info, plan files, etc.) should not be exposed to the outside internet.
• Scripts should respect the privacy of others through a file that is easy to create.
  • I suggested a ~/.privacy file that can be easily created and any script going into others homedirs should check there first
  • Also a per-script opt out could be implemented in addition to this.
  • I also thought that an opt-in system like a .public file may be safer and should be considered
• Documentation for script creators on creating scripts that don't expose info needlesly or carelessly should be available.

• Documentations for beginners on how to use Unix permissions, chfn, and other tools to protect sensitive files and personal information should be readily available for those wishing for additional protection.

  I'm more than willing to give an initial draft document a crack, but wanted to get this background documented.

@jessamynwest, You were there as well. If you have bandwidth, I'd like to hear your thoughts.

[jessamynwest]

Agree. Also watch that user to make sure they're not a random envelope pusher as opposed to just someone curiously inquisitive.

The MeFi rule was always anything that you'd need a password to view needs to not be surfaced to the googleable web. Something like that seems sound to me, with reasonable "Hey I didn't know" being an excuse once... or maybe twice.

I think people should not have to create a privacy file to have basic privacy. This should be something all users have from the get-go if it's to happen at all. So yeah, I think opt-out/opt-in are tricky language sometimes but privacy should be default, I'm less clear on technical stuff on how to ensure it but happy to talk personal aspects.

Even in the past few days I've seen a lot of language that is basically "Well if they don't know the rules that's ON THEM" which is not that surprising but something that probably needs to be gently pushed back against. No one should have to read a manual to enjoy tilde.club and we should be able to redirect them if they get lost/confused/in-too-deep.

The big failure of techie communities to my mind, is barriers to entry, especially WALLOFWORDS. I know that no one here wants to create that again if they could help it, so let's try to have some default settings that presume people want privacy and presume they may not know things and try to make it a fun sandbox for them.

People with bigger skillsets can run wild until the wildrunning is a problem. We probably need some low-key ToS that warns people that we're still working the bugs out.

[michaelcoyote]

@jessamynwest Thanks for your response. I agree with everything you said there.

WRT to the "Well if they don't know the rules that's ON THEM" stuff, I agree. That needs to be pushed against in any form. Also the WALLOFWORDS. I know I can be as bad as anyone in that respect.

Like @ftrain says: "UNIX is for the children"

Opt in security with a .public file? I'm cool with that. I will come up with some code examples.

I'm going to submit this as a pull request as a MD formatted document in the docs. I'm just going to sketch it in for now then submit it for comment. I expect and welcome any fine tuning.

[beaugunderson]

Huge +1 for opt-in .public vs. opt-out .private :)

[ftrain]

Maybe we just need a ~/.tilde file that has privacy stuff, name stuff, location stuff, that people can edit all at once to control their public personae and opt in or out of community features

Paul Ford // (646) 369-7128 // @ftrain

On Fri, Oct 10, 2014 at 5:53 PM, Beau Gunderson notifications@github.com wrote:

Huge +1 for opt-in .public vs. opt-out .private :)

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58721207.

[michaelcoyote]

@ftrain part of the discussion was making it easier for people to be safe. My thought around this was that touch ~/.private (or rm ~/.public for that matter) was easier to explain and for tyros to achieve than editing a file.

[beaugunderson]

Sounds like it would be useful to have everything there, maybe in .ini format? Easy to parse from most languages, something like:

public = true
location = Seattle, WA

On Fri, Oct 10, 2014 at 2:55 PM, Paul Ford notifications@github.com wrote:

Maybe we just need a ~/.tilde file that has privacy stuff, name stuff, location stuff, that people can edit all at once to control their public personae and opt in or out of community features

Paul Ford // (646) 369-7128 // @ftrain

On Fri, Oct 10, 2014 at 5:53 PM, Beau Gunderson notifications@github.com

wrote:

Huge +1 for opt-in .public vs. opt-out .private :)

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58721207.

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58721387.

[ftrain]

@michaelcoyote sensible

[michaelcoyote]

I'm not against having such a file (or a foaf.rdf as was suggested by someone). I was thinking an easy to understand and manage system that a new user can get. The file is there or it isn't.

As a side note, the existence of a file is easy to test for in most scripting languages. It's one line. There is also no overhead associated with reading and parsing a value out of a file, so there's that technical argument for this path.

[beaugunderson]

+1 on .public cuz it's easiest :)

On Fri, Oct 10, 2014 at 3:03 PM, Michael notifications@github.com wrote:

I'm not against having such a file (or a foaf.rdf as was suggested by someone). I was thinking an easy to understand and manage system that a new user can get. The file is there or it isn't.

As a side note, the existence of a file is easy to test for in most scripting languages. It's one line. There is also no overhead associated with reading and parsing a value out of a file, so there's that technical argument for this path.

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58722070.

[ftrain]

Agreed and very unixy. On Oct 10, 2014 6:03 PM, "Michael" notifications@github.com wrote:

I'm not against having such a file (or a foaf.rdf as was suggested by someone). I was thinking an easy to understand and manage system that a new user can get. The file is there or it isn't.

As a side note, the existence of a file is easy to test for in most scripting languages. It's one line. There is also no overhead associated with reading and parsing a value out of a file, so there's that technical argument for this path.

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58722070.

[admoman]

This is something we as a community need to get a handle on. And pretty quickly. I won't link to it here, but someone is now posting all wall posts to a public page on tilde.club. Starting mid-afternoon today (PT). I know there are people logging walls, but I think this is the first public posting.

This page makes me very uncomfortable. If for no other reason than people who have been using wall won't obviously know that what they say is being put onto the internet for everyone to see.

So there's that.

But I think there's a deeper issue here. A cultural one. So it's kinda ugly as so many human things are. The divide between "share everything! what's to hide?" and (here's my bias...) reality. I think private spaces are nice.

I feel strongly that what's on the server should stay on the server. By this I mean things you could only know if you were logged in (who, finger, disk usage, etc). Basically anything that's not a webpage someone created in their public_html should not be put on the internet as a whole without Express Written Consent. Of course, there's no way to prevent leakage/bad actors, but we should at least TRY.

I like the idea of .public, but I think as time goes on there will be some granularity needed. To sum up, I would like tilde.club to have an opt-in culture, not opt-out.

For example, I'm considering writing an RSS feed generator for all the pages on the site for myself, but I see it as being generally useful. But. I think people should opt-in to having their pages in a public-facing feed. I'll have a personal/private feed of everything because I'm in the club. Anyone else in the club could as well. But for a public feed, I think it needs to be opt-in. This is obviously more restrictive than what I suggested above, but this is the sense of what I'm suggesting. Considering other people first.

As I said on-site today, I think it's good that ~megnut wrote that she felt safe here. I'd like to keep that feeling for everyone. Putting the club-only stuff online (who, disk usage, location, etc) endangers that.

[jessamynwest]

For now we can just sort of re-align people's expectations and just say "that's not cool" because you're right, that's not okay, or it doesn't seem like it to me. It's not like it's such a wildfire thing that we can't handle it case by case until we figure out how to set expectations.

It's totally AOK to link to stuff that seems against-the-rules-y even if there aren't really any rules yet.

[michaelcoyote]

Here is the rough draft of the "safe scripting" doc (https://github.com/tildeclub/tilde.club/pull/24). It's rough and needs more I know, but I wanted to get it out there and get more feedback.

I've also got another user security doc sitting out there that I've just outlined. I'll probably pick at that over the next few days.

[michaelcoyote]

I'm of the mind that anything identifying a user that is internal to the server should stay so. Meaning who, finger, last, and those sorts of things.

I'm OK with things like load average, iostat, disk space, etc. making it out to the world. To me, this data is fair game. I'd like folks (including myself) to have some data on the server that they can use and learn from. Full disclosure, I do a bit of rrdtool logging of non-identifying system info as a fun project.

Logging the wall traffic and having it exposed to the Internet is not a practice I'd like to see continue though.

[admoman]

I agree with aggregate/non-identifying data being OK to publish. Lots of cool things to do with that data.

[ftrain]

I've been thinking a lot about this. It is complex. I'm not done thinking about it. I fully welcome feedback and criticism of my logic.

The larger issue is "what should be private vs. public on this system?" The specific issue is, should we make a policy that "wall chats" are not logged and displayed in public?

The natural instinct--my natural instinct--is to say: "You're right--security matters and it's important to build a community where people can speak their minds. No more wall logging." We can talk that through but ultimately it is a short-term solution about one instance.

There's a more fundamental issue here that we can't route around. This is, so far, a community constructing itself around the inherently social nature of the Unix operating system, sharing one computer. And there is no way to secure wall and make it private.

• Imagine we worked together and found a way to look for wall-logging processes on the system and kill them. This would be a bad use of resources but imagine it was possible.
• It wouldn't matter, because a user can just log the output of their terminal at home and we will never know until it is too late and the logs are on PasteBin and tweeted out. We wouldn't even know which user did it.

Even if we don't expand tilde.club membership there are hundreds of people here and there is no obvious recourse if someone decides to do something like that. They could think they were acting ethically by publicizing that information. We have no choice but to assume the presence of some bad actors and people with different ethics around privacy.

While community guidelines will emerge in time, as the FAQ grows (if you are interested in the community please volunteer to help with the FAQ), and a guiding principle like "don't log wall! keep it private!" is fine, I believe that it would be unethical to guide people to believe that wall chat is in any way truly private. Also, for some people, saying "don't log wall" while it's technically possible is going to lead to their next thought, which is "I can log wall!" We can only find out that they have done it after the fact.

So people are going to need to decide what and how much they disclose in channels like that. And collectively we are going to have to educate ourselves, and teach each other, about how privacy works at a lower level than we are used to. The upside is that you are a full-fledged user of this system and you have a tremendous amount of control over the privacy of your files.

Because this is a Unix machine, all users can assume a privacy model based on Unix users, groups, and permissions. Baroque but robust. This means:

• Users with root access can see everything on the server at any time.
• File permissions will be respected by scripts run by non-root users.
• Talk conversations, email conversations, and email list threads are private to the recipients.
• Public, scrape-able conversations could become public.
• File-based encryption can allow for total privacy, even with public files, even from root users.

Unix allows each individual to create their own privacy policy. This is a lot to learn about and it's not the easiest part of Unix to understand. Some of it will feel unpleasant, or even unsafe to some people. Documentation and helper shell scripts (one to set a directory private, one to make it public, things like that) can ease the path.

One other issue: It's important for people to know who is running things so that they can decide how they feel about the people with root access. So we'll need to make proper introductions of who has root/superuser permissions soon.

I am amazed and so happy about the community here and I want it to keep finding the joy of making things and to feel safe.

I do not believe that it is ethical for me or anyone to make promises about privacy and security that the operating system cannot keep.

[vielmetti]

I'm actually surprised that we have wall enabled for all users; that's usually a command reserved for systems people who can alert for downtime, not as a general purpose chat system.

On m-net and grex there's "party" which is a multiuser chat, kind of like a single IRC channel.

I'd be inclined to suggest that in the long run you disable "wall" or restrict it. In the short run it's probably fine.

[jessamynwest]

My feeling on what privacy one can expect is based on "who has access to this information?"

Wall goes to all users who are logged in. A log of wall that went to just users of the system is different than elevating those messages outside of the group of people who would otherwise have access to them via a publicly accessible web page. Logging the wall is one thing. Posting the logged wall is another thing entirely. This is about the latter. Having access to people's finger info is one thing. Posting it is another.

I believe that it would be unethical to guide people to believe that wall chat is in any way truly private.

Sure, but I think you're creating a dichotomy (private/non-private) when there's a spectrum (private ... accessible to authorized users ... not-private with a lot of flavors in between)

I agree that after-the-fact managing this stuff really is the best you can do, but I think that's acceptable. That's how you set norms, educate users and talk it out.

I, too, think that having wall accessible to everyone won't scale and this will be a non-issue following some more scaling discussion but for now I feel pretty strongly that

1. asking people to keep information within its context isn't that onerous
2. assuming good faith about people who overstep this is also just fine and these two things don't conflict
3. and yes users will need to learn about this via sometimes-troubling situations, but how they get managed at a top down level is also educating them

Moderating is almost always more difficult than not-moderating for situations like this. That's the friction and why so many places online are ... less pleasant.

I'm of the mind that anything identifying a user that is internal to the server should stay so. Meaning who, finger, last, and those sorts of things.

This is my feeling.

[vielmetti]

Personally I'd rather tail the wall log than have wall scribble all over my vim sessions.

[joshmillard]

It wouldn't matter, because a user can just log the output of their terminal at home and we will never know until it is too late and the logs are on PasteBin and tweeted out. We wouldn't even know which user did it.

Right, this is something that doesn't have a (practical) technical solution, so we're left with an ethotic one in terms of guiding behavior. Which isn't in any way impermeable but can help to greatly reduce the frequency with which privacy rug-pulls occur; if there's a shared understanding among the community that "don't make other folks' stuff public without explicit permission, manually or algorithmically" is the prevailing ethos, that's something that can be passed on to new users as they become active and can be reinforced naturally on a user-to-user basis.

Ideally the need actual top-down moderation of this stuff (like Jessamyn says, that's one of the trickier parts) can be somewhat minimized through that kind of good faith community policing, though practically it can never be eliminated. Every once in a while someone in charge is gonna have to have a word with someone, maybe a stern one; every great once in a while someone is gonna get booted for picking a particularly crappy hill to die on.

I think it's a really good idea to establish a clear set of community guidelines about this stuff and putting it somewhere very visible, on the sooner side; it doesn't have to be perfect to start with, but I think we we'd get a lot of mileage out of even a basic draft that (a) addresses these basic ideas/concerns and (b) makes it clear what the mechanism/forum for discussing it should be.

Of which: agreed on wall not scaling. It's goofy and weird and I love it but right now I think its primary value is just that there isn't a clearer "this is where to go to talk" organizing force on the site right now, and probably wall should go as soon as that has been figured out. IRC, both on the server and over on freenode, isn't bad but also is sort of itself ephemeral and catch-as-catch can so that's not really a solution either in the long run though I have been seeing a lot more people jumping into both at least which has reduced the amount of all-wall-all-the-time action.

[vielmetti]

Here's the info on "party"

http://www.cyberspace.org/party.xhtml

I don't know if it's available as source, but it might be worth checking on.

[michaelcoyote]

Ok, I've parked the scripting doc for now. It seems to me we have a lot more discussion to do before I can go back to it.

One of the things I was thinking about was that I wanted more experienced users to think about their actions in relation to the privacy of others, especially new users who may not understand the the system. Maybe a scripting document isn't the place for this but perhaps some sort of note to experienced users covering their responsibility to look out for the best interests of others ("..with great power comes great responsibility..."?).

As for teaching new users Unix permissions, yes this is also important. I also think it's less important than educating experienced users their responsibility to look out for others..

As a side note I started a separate document for teaching new users permissions when I started the scripting doc. I'm still in the "OMG THIS IS ALL TERRIBLE" stage with that document, so it may take me a few days to get it out.

[michaelcoyote]

@vielmetti the mesg n command will turn off wall messages on a per pty basis. You can have a window open with wall messages going and another window my tmux session for my $EDITOR and irc client. For my part I say leave wall running. For me it's a throwback to the old shellhosts of yore that always seemed to have a running wallchat session going.

Also, I've noticed that the new users seem to understand wallchat pretty quickly even though it's a wonderfully janky mess.. I'm all for keeping the barriers low here on tilde dot club.

[jonbell-lot23]

Hello! I'm jonbell and I was the one who asked how to finger everyone's profile and copy it to a file, then I ran the script and posted the file (though it wasn't linked to from anywhere, for what it's worth). Sorry about that.

Jessamyn said: "Agree. Also watch that user to make sure they're not a random envelope pusher as opposed to just someone curiously inquisitive."

In this case, it was 100% curiosity and not thinking. But I learned a lot from this experience. Here's what I propose for a way forward:

• We've pretty much decided that internal info should stay internal
• So let's write it up in a doc
• But it'd be great if the doc celebrated curiosity rather than WALLOFANGRYTEXT

For example, here's the entry I would have pointed myself to, if I could go back in time:

THINGS WE LEARNED EARLY ON, ITEM 8: Internal stuff is private stuff

Tilde's community is known for being curious and whimsical, which is one thing that makes it so fun. But early on we realized that it's really easy to scrape internal things and post them publicly. After some good-natured debate, we realized this isn't a good idea. On tilde, please don't take internal stuff and post it externally. Examples include [blah blah blah].

[jonbell-lot23]

@ftrain said: "(if you are interested in the community please volunteer to help with the FAQ)"

I am interested. Consider me volunteered.

[jessamynwest]

Excellent. I've been thinking more that we have sort of two things

• the faq for people who are faq curious and where stuff gets outlined to be referred to, expanded upon (version control very useful)
• a way a user who has questions (techie, etiquette, in-between) can get info or a person to contact and not have to just buttonhole @ftrain or whoever their person is (still interested in mentors, not sure if that would scale)

We can't guarantee that people log in to the shell or that they will see things on a web page so we have to sort of redundantly make this stuff available. Having the shell-level help stuff be visible (make it a visible part of motd like IRC info is) will be a good start

[jessamynwest]

FAQ is also bifurcated. We have the shell-command FAQ and the web page FAQ.

@ienjoy maybe you'd like to check out some of the shell command FAQ and see if some of it can be wedged into the web faq we're working on? I'm pretty new to working in git but I got the hang of it. Want to try moving a few useful pieces of info over? Let me know what you'd need from me to make this happen or if you hit a wall. You can get to the shell command faq by logging in and typing faq (scroll back, it's long) the regular web faq is here...

https://github.com/tildeclub/tilde.club/blob/master/faq.md

(top level of git hierarchy) and it gets "slurped to the ~faq website every hour so you can noodle and not worry. You can email me jessamyn@gmail.com which will probably get me more quickly than git-atting.

[jonbell-lot23]

@jessamynwest Sounds good! I've been out of version control long enough that I failed to make GitHub work for me last time I tried. But I will give it another go this evening. Wish me luck :)

[admoman]

@ienjoy If you have any issues working with GitHub, I'd be glad to help.

[jessamynwest]

@ienjoy Good luck! I had literally never done anything with it before. I found Markdown irritating but I powered through it. Stay simple and I think you'll be fine. If not, we'll (all) help. Thanks!

[jonbell-lot23]

I am pretty sure I just did a pull request. Or I might have launched missiles at the moon. Something happened. Possibly good things!

[jessamynwest]

I think so, yes!

[joshmillard]

In the spirit of experimentation, I am just piping up here via email to see if I can actually straight up respond via email and have it Just Work.

On Sat, Oct 11, 2014 at 3:52 PM, Jessamyn notifications@github.com wrote:

I think so, yes!

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-58767399.

Josh Millard

Music! http://music.joshmillard.com/ Blog! http://joshmillard.com/

[vielmetti]

I'm using a client called The Bee App to watch Github issues, it's pretty nice.

http://vielmetti.typepad.com/vacuum/2014/10/the-bee-app-a-multiplatform-issue-tracker-client-for-mac.html

[ftrain]

I tried to install some talkers and completely failed. We seem to be drifting in the direction of IRC. We have a shell-script talker, IRC, freenode IRC, and wall so I'm hesitant to add another.

[cyberis]

~ford's post today made an observation, and provided a framework to think about how our tech affects us (does technology make people or vice versa). We should remember that tech is a big weight at the end of a long stick; tech like any tool is a force multiplier. The weight gives momentum and the stick provides moment, but it's wielder provides the initial trajectory. Some one who intends ill can do more so with tech likewise someone who wishes to do good will have a longer reach. The naive can unintentionally harm themselves and others. I think if there has been an anachronistic attraction to a shell account and its attendant ~, it is because we know intuitively that our naivete with so much tech has gotten us in a bit of trouble. TMI in tweets, walls that haunt us and snapchats that linger have certainly made me long for a simpler tech experience. Perhaps that should be a consideration, especially in regard to how much tech is in the stack and how public information is disseminated. Perhaps we need a smaller hammer until we know who we are and what we want, no?

[kigerpunk]

A wall log seems like a good idea; people can log it regardless of whether or not the server does, so privacy is irrelevant. With the server logging it, people can just read the log instead of being interrupted, which sounds like a good idea. Somewhat relatedly, is there any way to get changes in the wall log put in ~/Mail?

[jonbell-lot23]

+1 I think this would be great.

[michaelcoyote]

Closing this. The documents are now in the wiki.

[reppep]

I feel a need to rebut something @ftrain said.

File-based encryption can allow for total privacy, even with public files, even from root users.

We must assume that anyone with root-level access (whether an authorized sysop or a root-level hacker/trojan) can either slurp up encryption keys when they are used, or snoop on the process of reading the encrypted file (decrypted copy), or compromise other systems for access.

Encryption is powerful but "total privacy" is a dangerous fiction.

[ftrain]

Yeah, this is true and correct, thanks Chris.

Paul Ford // (646) 369-7128 // @ftrain

On Wed, Oct 22, 2014 at 10:55 AM, Chris Pepper notifications@github.com wrote:

I feel a need to rebut something @ftrain https://github.com/ftrain said.

File-based encryption can allow for total privacy, even with public files, even from root users.

We must assume that anyone with root-level access (whether an authorized sysop or a root-level hacker/trojan) can either slurp up encryption keys when they are used, or snoop on the process of reading the encrypted file (decrypted copy), or compromise other systems for access.

Encryption is powerful but "total privacy" is a dangerous fiction.

— Reply to this email directly or view it on GitHub https://github.com/tildeclub/tilde.club/issues/23#issuecomment-60097742.