HOBA Revisted with WebCrypto

The Hoba Meteorite in Namibia

Here's direct link to the running demo which explains in much more detail what's going on than in this post at the HOBA Demo Site

Years ago, I got really pissed off about LinkedIn doing something incredibly stupid, especially for a big company which was storing unsalted passwords on their servers and their subsequent leak. That got me to thinking about getting rid of passwords on the wire if at all possible. This led me to my work on a prototype that used public key crypto to join, login, and enrolling new devices. You can see my original posts  here and here, along with the resulting experimental HOBA RFC (RFC 7486)

I was really excited when I heard about the w3c WebAuthn work hoping it was the successor to our experiment. The reality was when I tried to get WebAuthn to work, it seems regrettably difficult to get up and running, especially without an external signing dongle. It is quite possible that my problems were completely wrapped up with not wanting to require a signing dongle. Chrome doesn't support local key stores at all with WebAuthn, and Firefox does so only by fiddling with about: flags. This is a real shame as I really hoped that WebAuthn could finally bend the curve against passwords being transmitted over the wire which is still a huge problem. Since HOBA was written a lot has changed. WebCrypto now contains solid crypto  functionality accessible to browsers, in comparison to the horrible javascript hackery that I used in the original HOBA RFC. Another thing that has changed for the better is that it is much more common for servers to require an out of band verification (email, sms) to enroll new devices. This was one of my big worries at the time because HOBA required those out of band mechanism for enrolling new devices. Thankfully I don't have to fight that social problem too... lots of somebodies have done that for me in the mean time.

So I decided to give my prototype another look, and see if I could make it into what I had hoped WebAuthn was. Happily, all of the algorithms and backend code are still relevant from my prototype, it was just a matter of replacing the javascript versions of crypto to the more civilized WebCrypto version. Most of the effort was just dusting the cobwebs off the code and stripping it to a bare minimum. In fact, refactoring the crypto code to allow both to run side by side as well as actually writing the WebCrypto driver took all of one day, and a lot of that due to some whacky to/from PEM that was getting me wrapped around the axle which had nothing to do with WebCrypto at all. I've put both versions of code up on GitHub as an example of how this problem space can be attacked in a much more straightforward way if you don't need the added security of crypto dongles. The server code is written in PHP. Sew me. It could trivially be ported to any other language, and the key issue is integration with your own enrollment and login code in the backend so it serves only as an example in the first place. The HOBA-related code is actually very small and pretty easy to understand. The new device enrollment is probably the hardest to understand, but the main takeaway is that out of band verification of ownership of email, phone numbers, etc is pretty common these days so lots of sites have experience with deploying that. When I first wrote my HOBA code, that was much less prevalent.

There are two pretty big open issues. The first is the most straight forward which is whether it should be using a nonce from the server validate freshness instead of time. My guess is that the answer is yes and the implementation of a Digest-like (RFC 7616), as well as the original time based replay protection. The second is how to get enough review to actually believe that it works and doesn't have holes. I've been thinking about writing an internet draft and floating it at IETF but I'm not sure they'd want to take it because the client and server code are definitionally controlled by the same entity so it would mainly be for security review, not protocol agreement across different vendors.

I have created a site to demo the HOBA demo site as well as a Github Repo. Give it a spin and take a look. The demo is stupidly simple: join the site, logout, login to the site. If you want to enroll a new device, either find another or just use another browser and try to login in with your username. The backend will send mail to verify the new login. The only difference with all of this is that there aren't any passwords.

The Water Cooler Problem

 

Telecommuting Works, but is Different

Having telecommuted for almost a couple of decades off and on (mostly on), the technology has come long way. As a software developer and a networking geek, it's pretty trivial to work from home these days. There are undeniable benefits to working from home like saving time, frustration and money not having to commute, the obvious environmental benefits, and not having to be planted in a god-awful "open plan" row crop. Even if telecommuting were a net neutral on the productivity front, it would be a massive win for everybody, even if it were just a day or two a week.

Telecommuting can work, and can be way more productive. It does take discipline and is an acquired skill, but it can be learned. There are lots of people who say that telecommuting doesn't work, but it begs the question of whether the reason telecommuting fails is because companies are shit to begin with. Telecommuting does give you more ways to give them the finger, after all. The very act of not trusting their workers is its own problem and says way more about the people who distrust than the ones who stand accused. There is a simple problem to people who goof off: you reprimand them, or fire them. Same as going into the office. Being there physically does not mean they are actually working. Their output tells you that, both in the office and at home. If you think you can tell just by watching people in person, you are deluded. 

It is true that some people have a hard time telecommuting though, and not all  jobs are as easy from home as being an anti-social software engineer. But telecommuting need not be an either-or proposition. I would often telecommute in the mornings and then arrive late in the office with much less traffic, and then leave relatively early to beat traffic again, so as to have 4 or so hours to interact in person. In other situations, I would almost completely telecommute unless there was some particular reason to come in, like a coworker flying in to have some high bandwidth time with.

That said, telecommuting has its share of problems, both social and technical. In the following sections I will attempt to create an inexhaustive list of problems which I'll bundle together as the "Water Cooler Problem". I'm not trying to solve any of these, just enumerate what they are. This is especially relevant given the giant social experiment happening right now with the covid-19 pandemic. They say that things like pandemics cause huge changes. Like the previous one that I've lived with, I expect this to be no exception. This is telecommuting's debutante ball, for better or worse.

The Actual Water Cooler  

The Water Cooler is an abstraction for a place that coworkers can casually meet. It could be the lunch room, kitchen or by an actual water cooler. Quite a bit has been written about the benefits of the Water Cooler such as making and keeping social bonds which are not necessarily work related. I'm not entirely sure I buy into this though, at least for the non-work related stuff. When I was at Cisco, I rarely talked about outside life with coworkers unless they were a close friend as well. I barely knew who had kids or not and what outside interests they had. It just wasn't relevant or important. Even over lunch it was more about what was going on work wise. Same with other places I've worked.

That said, there is definitely worth to having lunch together and informally talking about what the current problems are, various shitshows around the company, and other comings and goings. Virtually, this doesn't happen that I'm aware of. There isn't much to prevent it given current technology: you could just have a standing meeting called "Lunch?" at noon every work day for your group and you can gross out virtually at them chomping down a hideous pb&j sandwich. It's not the same, but it wouldn't be especially different. Given the current lockdown, maybe it will become more popular. When I mainly telecommuted, I really didn't miss it particularly. Other people may value it highly. So I have mixed feelings about this entire form of interaction.

The Over the Cubical Phenomenon

Sticking your head over your cubicle, or hanging out in the doorway of a coworker is a classic example of how workflow happens when you are in the office. You ask a quick question, and get a quick answer within a few exchanges, or it can turn into something bigger because you realize that you are both clueless and need to hash it out.

The main aspect of the over the cubical problem is that it cannot require a classic threeway handshake before information flows which is what current meeting tech requires (eg, a meeting invite...). Information must flow from the start of  your presence over the cubical, and not after a response. This implies that some amount of gate keeping needs to be available to limit who can look into your cubical, based on "location",  hierarchical distance, and social availability so as not to subject people to interruption denial of service attacks.

Another factor is appropriate interruption. Interrupting people has been measured to require a significant amount of time to get back to the previous task. A common mode in real life is to give a quick "give me a sec" or "can you come back in a few" so they can finish up what they are currently working on. The other thing that real life gives are hints that they are not available at all and that you should come back later. Like if they are already with somebody, or they look like they are really busy. That is a much more difficult task remotely. As in I have no clue how you'd do that.

Chat is Not a Substitute

Chat is sort of a half-way between email and a meeting. And while it's often good enough to hash out problem, it's not a panacea. The main thing I see is that it is rare for chat to upgrade to face to face style interaction when that is actually appropriate. Maybe it's just me being an old geezer and not knowing that the younguns do this all the time, but it's definitely not been my experience. It needs to be extremely seamless to work correctly. Like one click from the initiator and with little or no effort on the recipient.

Which points to the second problem: there seems to be social barriers to doing that. I really don't know why, but it would just never occur to me change to face to face midstream. If I am the norm, that means that it will take some amount of social training to make that an acceptable thing to do.

Spontaneity and Brainstorming

Part of the supposed benefit of the Water Cooler is spontaneity so that you can brainstorm. The chance meeting that turns into something bigger. Sometimes much bigger. When I was working at Cisco a small group of upper level engineers were tasked with what Cisco could to help with the spam problem. A chance meeting by myself and one of the others (Eliot Lear) allowed me to talk about something I was thinking about without having to show my cards to everybody else in case it was insane or useless. I might have done the same by email, but it was better in real life because the back and forth is faster. He ended up liking parts of it, and was dubious about other parts, which gave me confidence to explain what I was thinking to the larger group. The rest as they say, is RFC 4871 (DKIM) which signs almost every piece of email on the internet these days.

So that was definitely a success story, and I'm sure there are zillions of others just like that. It's hard to say that it was the thing though: I'm pretty brave at revealing my ignorance so it would likely have gotten out one way or the other. Others are not as brave (or reckless) as I am, so bouncing ideas off of others privately can be really important. The current state of tech with respect to conferencing is definitely not conducive to this kind of interaction. The main question is how much it matters.

Before and After Meetings

Before and after formal meetings is a place for the Water Cooler effect to happen. On conference calls, allowing people to chat amongst the other participants before the meeting is pretty common, but it seems like either it's the default or meeting owners choose to disable that feature which is puzzling to me. After conference calls, however, are completely different: people just hang up. In real life, it is much more nuanced. As people leave, they may linger either in the conference room, or out in the hall and chat either one on one, or in smaller groups. There may be more than one of these groups. It may be social, or more often it's a followup to the meeting itself but in a smaller setting. These are completely spontaneous and often more informative than the meeting itself, given structure. It is also a very good place for junior and senior workers to mix and especially more junior workers to be able to be more open with their ignorance than in an open meeting setting. It is super important that junior workers be comfortable knowing that they don't know it all and just ask and learn. That is a serious problem for telecommuting.

This to me is probably the most important problem. On the bright side, it seems like it could be amenable to technical solutions. But there are always the social implications that make it hard. How do I know if they have to jump onto another call? How do know that in real life? It's pretty obvious if they are scurrying to their next meeting. If they hang out a bit finishing up, that probably means they are amenable. So it's pretty easy gauge in real life. In virtual life? I don't know.

Mixing of Junior and Senior 

Cisco was/is a complete creature of mailing lists. It had a pretty unique mailing list though called clueless. It was populated by junior engineers all the way up to fellows. Though it was much more technically oriented, it had lots of participation from high level execs -- often geeks turned suits, but not all. I'm sure that Cisco is not unique with this kind of interaction, but it was a very curious creature in a way. It facilitated younger engineers to actually interact with people who are gods in the networking industry and see them as people rather than just technical specs, and delivered products. This one is cranky, that one is surprisingly social and very accessible. You find out what's going on around the company, what people are interested in, what people's hobby horses are, etc. Likewise, the senior engineers get to see the up and coming engineers and what their talents are, and how they might be worthy of helping them along to grow their talent.

For a large company that is almost impossible to do in meat space, so here virtual is actually a win in terms of in the large. In the small however, virtual doesn't work as well. It's much easier to see somebody who probably knows what you need to know, and ask them in a few minutes which otherwise may have taken hours or days. Email works to a degree, but in person it is better especially if a whiteboard is helpful (which it often is). And there is the social cuing that makes it easier to ask somebody something in person who you barely know, than sending off email that may go unread for a long time.

Whiteboards and Casual Meets

Often you'll meet up with somebody either by chance or by interrupting them, and find the need for a whiteboard. I've never used one of these virtual whiteboards in formal conference calls, but I am extremely dubious that using a mouse to draw something is any way a substitute for a marker. I suppose you could get a e-pen, but that's just one more thing on my desk. Maybe phones and/or tablets with touchscreens make this easier. But that too is problematic because one of the advantages of a whiteboard is that they are physically big, and phones and tablets are tiny. I use a 4k monitor which is attached to my Mac so I suppose that might be a possible compromise, but I'm not sure how it would work. Happily, this post is not about solution space. The problem remains a problem and this post remains something to point them out.

Customs are Different Online?

People do not seem to like video on conference call. It's been available on formal meetings for ages, but people don't seem to use it from what I've seen. Which is very peculiar because obviously in real life you can't do otherwise. There may be something deeper going on here though. When I am in a real life meeting there is no way I can forget what I'm doing when I'm constantly bombarded with the feedback of seeing and hearing the people around me. I had one mortifying incident happen to me as I was driving to San Jose from San Francisco on a conference call. Somebody cut me off, and as normal I screamed at him (even though he couldn't hear of course). It was not on mute. Oops! That would never happen in real life, so there may be a  rational reason we may not want to show our mugs to make certain we don't floss while sitting in a meeting.

It's all the more peculiar because humans are social animals and visual cues are extremely important. There seems to be a big difference when you get a bunch of people staring blankly at their computers than in real life. In real life, attention (or not!) is given to the person who is talking but can veer off to look at somebody else to judge what their reaction is, or to signal to another that a response is necessary, etc. Since you can't tell what the person on the other side is actually looking at remotely those sorts of interactions are not possible.

Lack of visual cues make another problem almost insufferable: blowhards can speak forever and you can't get a word in edgewise. I mean if I wanted a lecture, record it and I'll listen to it when I feel like it. If at all. This is in fact a technical problem largely of our own making, but it is also a social one in that the blowhard may believe that his prolific words of wisdom have captivated the audience. This simply doesn't go down that way in real life. Exasperation is a readily observable social cue as well as just signaling that you want to talk. Which isn't to say that they can't blow-hard in real life, but they can get non-verbal feedback too.

Etiquette  

There are a lot of questions about etiquette in the virtual realm, and it's not clear that they map 1:1 to real life. Or at the very least, they present new dimensions to how you map real life etiquette to a virtual one. Suppose I wanted to transition from text to a live conference.  If I offer and you decline, that is bad. If I offer and you accept unwillingly but socially required to, that is bad too. This is especially true of meeting/chance encounters. In real life, you can see somebody and guess whether they are really busy or whether they are coming up for  a breath of air. Or at least it's a lot easier, if imperfect. Likewise, even if you intend to interrupt, you can let your presence be known and let them tell you when it is OK to interrupt.

There are no doubt lots of other areas of etiquette which may well be different or new in a virtual setting.  As anybody who knows me, I am treading on thin ice with anything pertaining to etiquette so I'll stop while I'm behind.

Adding it Up: How Important is the Water Cooler?

As I've said, I've telecommuted a lot in the last 20 years. Even though I have a long, if incomplete,  list of differences they are not all equally important. It is manifestly the case that you can do good work completely from home not having any of these real life features outlined above. Or that you can get by mostly virtually, with the occasional meet up for high bandwidth interaction. That tells me that it is much more of a nice-to-have feature than a must-have feature. Some nice-to-haves are much more important than others. The End of Meeting problem is a pretty serious deficiency and especially for more junior coworkers. That is when items discussed are freshest on people's minds, but just hanging up abruptly stops those interchanges dead in their tracks.

The Over the Cubical problem is also pretty serious. For years, I didn't have anybody to just geek out with on the spur of the moment. Once you schedule an actual meeting, you've already lost any momentum toward just getting past something you're working on -- formality is the enemy. That I really missed. The Actual Water Cooler Problem is much more meh for me. I'm willing to be convinced that I'm the outlier but I'm suspicious that it is solution in search of a problem. I'm more than willing to not know about other coworkers lives if it saves me from being planted as an open office row crop. It is deeply satisfying that study after study shows that the benefits of collaboration with open offices is in fact negative and that it was always about saving money with a post hoc rationalization about its benefits.

Telecommuting can definitely be done successfully, but we are still quite a ways off from solving some serious downsides. We'll be learning for years to come given the Great Covid Experiment in Telecommuting. For one, we'll find out about the validity of baked in biases, given this was widespread without the self-selection problem. We should also be able to gauge what productivity is, and how it balances with all of the upsides. Since a large slice of the people who telecommuted are new to this, they can feed back what their hurdles were. It should also inform the industry what technical problems are out there for the new telecommuters, and the remaining problems for old hat telecommuters.

Interesting times we live in, fer shure.

The Toxicity of Interview Programming Tests, Pinché Cabróns

When I was at Cisco, my last project was about what Cisco could do about the email spam problem. Cisco had exactly no presence with email in any form, so this was as greenfield as it could get within the confines of $MEGACORP. We got chartered by Dave Rossetti and got together a bunch of senior engineers where we immediately started tapping our white canes in the email universe. I remember talking to Eliot Lear one day about how maybe we could affix a signature to each piece of email from a stable private key from the sender and let the magic of Bayesian filtering do its job. I don't think that Eliot was overly optimistic about unanchored keys -- although I don't think he laughed out loud either. I floating the idea with the rest of the group after that. I'm struggling to remember whether Jim Fenton (Jim, help me?) had been thinking down similar lines, or not, but the end result is that our white canes were now tapping at a furious rate at what would ultimately be called Internet Identified Mail (IIM). IIM had a shiny new thing we called a key distribution server (KDS) which bound the key to a given domain, and used HTTP to transport the keys to the receiving domain to verify the signature, so I'm sure that Eliot was assuaged.

We wrote an internet draft and started socializing it. In the mean time, I hacked up a sendmail milter (code that sits in the mail flow pipeline that can munge the email) and hashed out a lot of the boring message on the wire syntax mainly by needing to get down to that level to be able to code it up. Jim and I were much more interested about the semantics, after all. After having a working prototype, along with our socialization outside Cisco we ended up finding out that Mark Delaney at Yahoo down the street from us was working on his Domain Keys draft/implementation which looked different, but eerily similar too. We finally got together and made our cases to each other -- we were looking from the vantage point of enterprise, and Mark understandably was thinking service provider. After some soul searching Jim and I decided that the main differences were with syntax in way the signatures parameters were sent, canonicalization, and the use DNS vs HTTP for key lookup. Truly yawn inducing details thinking back about it.

So DKIM was born -- Domain Keys (Mark) Identified Mail (Jim and I). This lead to a very large push outside with lots of IETF folks. One the remarkable things about the experience is that the eventual working group had rough consensus and running code in spades, and well before the actual working group was spun up. I managed to eek out a small victory in being the first one to want to interop code with others, with Murray Kucherawy then at Sendmail following like the next day. Murray's worked a lot better than mine, but he had written the DK milter, so he was at a big advantage.

During the journey, we started talking to a company called Ironport who were also participating and knew what Murray and I had done. Jim and I were part of the due diligence team that vetted Ironport that Cisco went on to buy. In the mean time, internally we had started our own effort, and my DKIM code was put into Cisco's mail pipeline with a racked up box (Cisco is a hardware company... it's what you do). So not only did I write the code for DKIM, it was running in a Fortune 500 company's mail infrastructure, and for a company that lived and died by email, that was no small thing. It never had a hiccup.

So what does this have to do with Toxic Programming Tests you quite reasonable ask? All of the above should show to any idiot that I'm quite capable of writing solid code in short order. Once Ironport was part of Cisco, it was obvious that our project was done so I decided to try to jump over to the Ironport acquisition. When I finally interviewed, they gave me a programming test -- strstr as I recall. I wrote a shitty version of it but said that in real life I'd get out Knuth and lean on his genius. I mean, I had been out of school for 25 years by then... these algorithms are not on the tip of my tongue. Afterward, I was told that the universal reaction was that I couldn't write code. I'm like what in the fucking fuck? They reduced all of the evidence to the contrary to a single coding test that I wasn't even expecting! In another interview later I was vetoed because I couldn't recall off the top of my head what the Java keyword for a constant was (final) by a shitty junior engineer. I know lots of languages and it takes a little bit of time to swap them in and out. FWIW, I knew the answer but just couldn't remember it in the interview.

That is toxic. Coding tests have always been pretty close to useless because different people like to code in different ways. I like to be holed away and absolutely loath people staring over my shoulder. But guess what, that's what coding tests force you to do! So by all means, ignore your lying eyes and base everything on 25 year old memories of algorithms which in real life you'd be fired if you were to roll your own. Rinse repeat. Over and over. Interviewers are completely convinced that if you don't know whatever obscure algorithm they are throwing at you, you can't code. Research by Google of all people -- because they are the absolute best at this toxicity -- showed that coding tests and lot of the other toxic interviewing they did was not only useless, but were actively harmful. I interviewed once at Google before this revelation and got the same idiotic treatment and rejection. For years they would call back asking me to interview again, and every time I said no and the reason why. I finally started telling recruiters that if it involved programming tests, I wasn't interested.

The thing that's most stunning about all of this is that they never want to talk about what you've done in the past. The excuse that I've been given is that it could all be a lie. But memorizing algorithms is its own sort of lie. In my opinion, your past is an excellent place to quiz the interviewee because they better be able speak to the architecture, design and implementation with authority. A thing I would look for are the subconscious "we"'s which can mean that they are embellishing their part in the project. But that's a different rant.

After doing some research on this admitted hobby horse of mine is that a Fizzbuzz-like test might be ok, but treating even mid-career engineers the same as fresh college grads is lunacy. As I've written before, a lot of these interviewers are really just looking to have their penis extended so they are doing these kinds of interviews in bad faith in the first place. Yet way too many companies seem to rely on these kinds of tests as if they were delivered wisdom. Sorry, no I'm not going to re-read Knuth to get a job at your shitty-ass company that I don't know a damn thing about, let alone what I might be doing.


Tests, to god-damned hell with tests! We have no tests. In fact, we don't need tests. I don't have to show you any stinking tests, you god-damned cabrón and chinga tu madre!

Weaponizing PC Aspirations from Poorly Trained AI's [frank language]

I was banned from Reddit after a short stint of posting to r/askgaybros recently. The person to whom I was responding (1234ideclareworldwar) had just got done telling me that I either had AIDS-related dementia  or was mentally retarded because I somehow had a chip on my shoulder.  I have no clue how those even relate to each other. He had previously said that he wouldn't date somebody who was HIV positive because they were in effect reckless barebackers including all of the people who died at the beginning of the pandemic. My crime was to point out that there was no such concept of "barebacking" back then -- it was just gay men having sex with each other -- and that he'd either be the type of person who abandoned his friends as social pariahs to die a painful death alone, or he could be one of those who died a painful death alone himself.

Poof! That was it. Assumedly enough of the people of his persuasion (and there are lots of hateful young gay incels just like him) reported me and that was that. The content while somewhat graphic was certainly not harassment -- it was the literal truth. I was only trying to explain in a pointed way what the situation actually was to somebody who was clearly Monday morning quarterbacking, and full of the yummy privilege of hindsight.

The coup de gras, however, was me retelling this story on Facebook as a comment on a friend's posting, I was put in Facebook jail as well. I had just described what happened and my experience with the legions of gay incels that seem to populate that subreddit and their clueless hatefulness. Apparently as a gay man I am not allowed to use the F word (and I probably can't even say it here because Google's AI's are probably no better) in any context even though as a gay man I have been actively trying to reclaim that word as our word. It's not as easy to tell with Facebook, but I doubt that any of the original poster's friends reported me to Facebook. This was most likely Facebook acting as net.nanny on its own. When I appealed, it said that it might not get reviewed because of the Covid-19 pandemic, but in fact it "reviewed" it a few minutes later with the same results. That says that it was not, in fact, a human but some poorly trained bot (read: egrep) making the decision.

Ok, enough of the pity party, it's just a concrete example of something that is happening on a widespread basis without doubt. The larger problem is that these poorly trained bots (I hesitate to even call them AI's because they seem to be at the level of egrep) allow people with bad intentions to game the system. These poorly trained bots in fact are punishing the people they are intending to protect. Since they do not have the capability of understanding context -- and even human moderators generally just do peephole scanning -- they are enabling people to use that lack of context to retaliate against speech they do not like.

I should point out that this is fine for moderated groups/subreddits who have their own rules. Moderators can be a pissy bunch, but in the end it is their group to be pissy about. You are always free to create your own group with its own rules. The problem is with platform-wide moderation where it's it is painfully obvious that it is not up to the task of providing a fair and even moderation service. In the Reddit example, the user whom I supposedly harassed is still posting away with complete impunity. I was dished up more vile and harassing -ist (fill in the blank) in those 4 months by young gay men than I ever was by homophobes on Usenet's unmoderated soc.motss in the many years I participated. While Reddit does not disclose its moderation algorithms (security by obscurity!), it's pretty obvious that it is heavily influenced by the number of reports. While that may seem reasonable since homophobes coming into a gay group is not very desirable, it can have the perverse effect that the young gay men in my example who reflexively dislike older gay men -- this is common as dirt -- can game the system to get rid of them. The platform-wide bots that enforce this are clearly not up to the task. Yet enforce it they do anyway -- poorly and unevenly.

In the case of Facebook in particular, it is even more egregious. When a marginalized group cannot talk about their marginalization in frank terms, the platform is reinforcing that marginalization. As far as I can tell, anybody can report a comment if they can see it. While that is good for actual bad actors, it can be weaponized by bad actors to report content to retaliate against people they dislike, often for reasons of victim's marginalization. Facebook is in particular awful because you can't even try to give context while appealing the punishment. I suspect that it because either the bots cannot do anything useful with it, or it makes human moderation too costly. Reddit has pretty much admitted the latter. So basically this moderation is nothing more than a glorified egrep for the most widely used social media platforms on the planet.

Topically, I can almost guarantee that people have already been put into Facebook jail for making fun of Trump's dangerous and insane suggestion that people ingest cleaning products to protect or cure themselves from Covid-19. Since they can be trivially reported by Trump supporters as incitement  to harm or fake news, it is up to the bots to detect irony. Irony is extremely context sensitive and on Facebook writing on your own or a friend's wall it often comes down to actually knowing the parties of the conversation and whether it's irony or not: "of course he doesn't mean it literally, it's $FRIEND".  Bots or even human moderators surely have no clue. Since the jail message to me mentioned Covid-19 as being a reason for a possible delay for review, I'll bet a buck that it is because their bots cannot distinguish people rightfully lampooning a dangerous charlatan president from the morons who actually take his idiocy at face value and pass it along in all seriousness. Putting even one person in Facebook jail for spreading the word about yet another dangerous and incompetent thing that Trump is touting that should be avoided is bad. Very bad. Forbidding this kind of speech is an existential threat to our democracy as it gives the bad actors a trivial way to game the system by silencing the very people the platform claims to protect. Just as I am not allowed to call out ageism in the gay community on Reddit, people who fear that our democracy is coming apart in real time are silenced on Facebook by the people who cheer that on.

And that gets to the biggest problem of all. Platform-wide moderation is a cost center. There is little incentive to do anything to it other than reduce its cost. Being accurate and fair is almost certainly way down the list of priorities. Good moderation is extremely expensive because you have to hire and train people who are then given an endless supply of judgement calls -- a huge amount of which they are absolutely unqualified to judge. Do you think that people at moderation centers in Morocco have any clue about the subtleties of gay male culture in the US? Of course they don't, and that is putting aside the cultural biases of the moderators. Since even bad human moderation is expensive, social media has been deploying even more clueless "AI's" to keep costs down. The "AI's" deployed are even less equipped to deal with the subtleties of human speech and interaction. For all the hype, AI's are dumber than shit.

This sets up a huge dilemma: cyber-security -- and maybe security in general -- is asymmetric, where the bad guys have a huge upper hand. Bruce Schneier wrote a great blog post about exactly that asymmetry. It is trivial for attackers to slice and dice up Facebook's population -- that's the service for which they make their ad money after all -- and target them for reporting. Even assuming that there isn't an API to automate the reporting task, there is a huge effort difference for, say, a human given a list of general things to report the target for, than for the moderation task itself. Perversely, the more virtuous the social media platforms try to project, the easier it is for attackers to subvert its moderation since the bar is much lower, sweeping more and more people into the false positive pile.

The long and short of this is that while punishment for harassment might be a good idea in theory as with Potter Stewart's famous quip about pornography and "I know it when I see it",  "seeing it" does not scale to internet scales. It's also clear that we have no clue how to solve that any time soon. Given that it is trivial to subvert on a small scale, it should cause people to shudder at the thought of censoring weapons being used at a nation-state scale, either for its own population, rivals' populations, or more likely both. It would be ironic in a horrible way that the go-to way to stifle dissent is to is to use the tools of virtue as a weapon by those who have none.

The silver lining of all of this for me is that I have been cut off from the horrible people I have been dealing with, and it's feeling pretty good thus far. Fuck you Facebook. Fuck you Reddit. I am not your product anymore. I have no need for you. I have no use for your enabling hateful Trumpanzees who are the poster children for Dunning Kruger Syndrome. Nor do I have any use for hateful young ageist incel gay boys who think that it's a good thing we died of AIDS as they bask in the moral superiority of hindsight. The joke is on them: you'll end up being be old, gay,  and hated and wonder what happened. And best of all, the Trumpanzees will all be dead from Evolution in Action as they infect each other with the Covids, and munch on Clorox Chewables as a cure. Life is good.

On Second Thought... SIP Security

I have argued here that SIP's STIR/SHAKEN is misguided and is probably solving the wrong problem, and that the "right" problem is in fact the sip:mike@mtcc.com problem. But what if we are both wrong? The most obvious question is whether there is going to be anything resembling the PSTN at all in the future. Phones are increasingly not phones at all, but instead devices to access internet services. While email is probably bumping along at the same clip or growing, actually talking on a telephone is distinctly in decline especially among the youngins. They certainly use SMS texting, but there are any number of wholesale replacements for SMS-like texting. Given the lack of end-to-end privacy of SMS, apps like Whatsapp fill in that void and is very popular from everything I've heard. Given the heavily regulated PSTN and the tension with law enforcement, it seems highly unlikely that SMS will ever provide that sort of privacy.

So the obvious question here is whether in, oh say, 10 years legacy telephony (regardless of how it's transported) will be very important. My bet is that as a means of communication the answer is "no". Sure, old geezers like moi will continue to use the old fangled things, but for younger generations the decline will surely accelerate. Lest anybody think that I'm saying that in 10 years time that the PSTN will evaporate, I'm definitely not saying that. But my suspicion is that its raison d'etre will largely be overtaken by new technologies. Given that telephony is almost 150 years old there are definitely a lot of legacy things baked into everyday life that will still be needed for decades to come. But those needs are increasingly around the edges, and they are slowly but surely getting internet enabled analogs.

What that implies to me is that more and more people are going to just turn the telephony functionality off, or at least find ways to not have it annoy you. Even in my geezerhood, I am sorely tempted to do exactly that given the spam problem. All of this puts the telephants into an interesting situation: having to provide an expensive and heavily regulated service that is in free fall. Long gone are the days when telephony was a profit center. Mobile providers haven't charged for telephony in ages, and landlines are becoming  jokes to outwit clueless teenagers. One thing we can be sure of though: if something ain't a profit center but you can't get rid of it, you put exactly as little investment into it as possible.

The other thing that has been happening since I wrote the original post is the Covid-19 pandemic. They say these kinds of things have a way of really reshaping society. It was certainly true of the previous pandemic, especially for gay people. HIV and the corrupt and incompetent response to it shaped a generation of activists who had no other choice but to take things into their own hands to affect change. It also forced several generations worth of tireless work on anti-retrovirals and pushed the envelope of biology in general. We are surely reaping the rewards of all of that work, including the possibility that HIV drugs like Lopinavir may be helpful for Covid-19 too.

Since Covid-19 affects everybody, it is likely that the change is going to be enormous. Working at home as well as using things like Zoom for social interaction has become a major change in daily life. It is highly likely that this petri dish we've been thrown in to is going to force us to especially look at why we need to go into the office every day of every week. I could be wrong, but telephony is probably not the go-to answer for either telework or social interaction. This further contributes to its downward spiral and relevance.

While it seems to be a pretty safe bet to say that telephony qua telephony is in decline, it's still an open question in my mind whether that also applies to SIP qua SIP. The work on G.164 identities seems to me to be a lot of work for little long term gain. But I really don't know whether SIP is used much outside of telephony. Most of the new communication services don't seem to have any inter-provider needs, so SIP isn't a requirement. And if you take the inter-provider problem off the table, the spam problem is reduced to the more tractable intra-provider problem.

So is there actually a DKIM-like analog problem in SIP beyond telephony? I think that it's an open question. Centralization has become the watchword for the last several decades. On the other hand, centralization is starting to create backlash as nations and governments watch it wearily. A Bell-like breakup of, say, Facebook could happen. Or nations might take back messaging and video services and we'll need inter-provider connectivity after all. Who knows? I sure don't.

As always, one engineer, three opinions.

SIP: what about the From: header? No love?

I posted a while ago with questions about SIP's STIR/SHAKEN stuff (RFC 7340 has a very good problem statement worth reading) that I became aware of. Well, it turns out that it's really trying to shore up the miserable P-Asserted-Identity mess. I actually kind of like saying I told you so, so if that makes me a horrible person I'll own it. For SIP, P-Asserted-Identity is really nothing more than passing on the PSTN identities (caller-id, e.164 addresses). Which begs the question of whether you can trust their contents. The answer now is the same as the answer 15 years ago, and that answer is... no. The only real surprise is how long it took for $EVIL to figure this out.

For many, many reasons trying to give some guarantees about whether somebody is allowed to assert a given e.164 address is a very hard problem. The new standards have had to deal with this and it's not pretty. Not a knock on the work, it's just that the problem is really, really awful and hard: the PSTN never, ever envisioned the sort of trust model that has become common, or the financial incentives to not care about the problem. This is going to take a great amount of effort to roll out and that's just the beginning. $EVIL is not a static thing, and if I understand correctly there are some pretty significant holes that can't really be plugged.

Which got me to thinking. Why in the hell do I even care about e.164 addresses in this day and age? They are, actually, quite a nuisance. I can barely remember my own phone number, let alone anybody else's. SIP from the very beginning didn't really envision co-existing with the PSTN. It was a new way to use internet mechanisms instead of the inadequate PSTN standards. SIP was just like email, in that it had headers, one of which is a From: header that is identical to email addresses. The idea is that if you wanted to email me, you'd use mike@mtcc.com. If you wanted to call me, you'd use mike@mtcc.com. Simple. It was't until telcos started getting interested in SIP that PSTN integration started rear its ugly head. And hence the sorry situation we're in today.

So let's go retro for a moment. Maybe the original idea of using From: addresses wasn't so bad an idea, and is certainly widely in use today. A lot has changed since the telcos have butted into the VoIP world. For one thing, it's practically extinct. If it weren't for cell phones and the last mile it probably would be extinct. From what I can tell, it's IP the second it hits telco equipment. My little provider here in the Sierra has a gadget that terminates POTS and sends it out as SIP and RTP,  has a DSLAM and backhauls IP over fiber and is battery backed up from CO. Pretty nifty that stuff I've worked on is a block or two away. I think it's pretty much the same for the cellular RAN networks. Since POTS is pretty much dead that just leaves cellular. And if you believe the hype about 5G it will be pretty redundant since it supposedly deals jitter, latency and other things that make VoIP a little dodgy on 4G. I'm not sure of the exact details, but I'll take them at their word that VoIP will be pretty acceptable on 5G. Update: found out that VoLTE is a Thing. So PSTN stuff is now almost completely redundant.

So it's a pretty SIP-y world, and it's about to get a lot more. If I have a SIP UA on my phone, I can completely decouple who provides the bits from who provides the rendezvous services. And I can guarantee you that the telcos are not going to be my first choice. So I may well get my wish that the From: address becomes what people expect on an incoming call, not PSTN anachronisms. So all is good, right? Well, no. Not quite. We still have the problem of spoofed addresses, but now it's put on the From: header instead of the P-Asserted-Identity header.

As far as I can tell (and i could be wrong because there's a mountain of SIP RFC's), there's really not a viable end to end or end to middle or middle to middle kind of way of asserting identity. Yes, I know there is an RFC for S/MIME, but client certs have never seen any wide adoption, and probably never will. And S/MIME is really about end to end crypto which while useful, is not exactly problem that SIP's version of the "caller id" problem is trying to solve.

What we learned with email back in the DKIM days is that end-to-end authentication is a hopeless task. Domain based aggregation, on the other hand, seemed quite tractable. That is a domain can claim responsibility for a particular message (email for DKIM) as having come or passed through its infrastructure. The way we characterized is that DKIM is a "blame me" mechanism if something malicious happened with one of its users. The tradeoff that DKIM  made, however, is that you really don't know if the user part of the email address is who they say they are. But for the purposes of reporting abuse that's not necessary: it's really the sending provider's problem to figure that out. As it turned out, a lot of providers and probably all of the major providers nowadays require SMTP auth. I'm not sure if there was any cause and effect from DKIM to adoption of SMTP auth, but it was certainly in the air at the time.

Now back to SIP. Given the spam we're seeing it sure would be nice to have a "blame me" mechanism to see who injected a particular piece of voice spam into the SIP legs of the INVITE. Reputations can be aggregated at a domain level, and signing policies can be advertised for evaluation of the message. While I might not trust my provider on every front, our interests are alined  when dealing with spam and misuse. Even if I can't verify the incoming INVITE directly (say, you're on a 4G phone), I do trust that my provider can verify it on my behalf and they could stuff the verified message's From: into the caller-id, or somesuch. With VoLTE, they're using SIP so you wouldn't even need to do anything heroic: just show the From: address.

A nice property of this is that the unpluggable holes with e.164 address security aren't a problem in a world that is becoming more and more native SIP. We should be looking forward to that future in addition to any backward looking legacy problems. DKIM has been amazingly successful and extremely widely deployed with tremendous volumes. And since email message structure is the template from many protocols including SIP, it should be pretty easily transferable. In fact, in the day I actually wrote a SIP DKIM signer and verifier just for fun, so mechanically there's not any problems.

There are definitely questions to be answered though: Should verbs other than INVITE be signed? Should the replies? I'm not sure of what benefit there would be to signing REGISTER, for example, but it may be just as well to sign everything regardless of whether it's useful. And then there is the every present  problem of B2BUA's (back to back UA's). Honestly, these aren't entirely different than the Mailing List Problem with DKIM. The answer there is that the entity in the middle that breaks the signature should resign it. And it's probably not as bad a problem as with mailing lists because if I understand correctly B2BUA's are mostly being used as session border controllers which are typically in the same domain as the sender which is typically not the case with mailing lists.

In conclusion while it might be worthwhile to solve the E.164 problem, we definitely need to look to a future where it eventually shrivels up and dies. The future is being able to verify the sending domain of SIP messages, and especially knowing whether the From: address checks out which should be the case in a large percentage of signaling traffic. That would greatly help the voice spam problem since we would be able to reliably blame the sending domain.

The Apple App Store is Security Theater

Apples are sometimes rotten

 

Money, $$$, Money

From its inception the Apple App store has been about exactly one thing: separating you from your money. That's not exactly news, but Apple being the good marketers they are, decided to put a nice bow on their money turd by claiming that they were going to curate the apps and be super careful, and look out for you, and send roses to your mother on mother's day, and, and... they may do some of those things, and the people who do that curation may in fact be honestly trying to do their job to stop bad guys. But in the end, it's all a bunch of hooey, aka security theater.

The App Store Treadmill

In order to understand this, you have to understand what the process is for developers. In a nutshell, your iPhone, etc will not run an app whose code has not been signed by an Apple cert/key. This blocks any other store from being able to sell apps for the iPhone. There are a few exceptions to this (obviously one that allows developers to develop, but also enterprise apps these days too I hear), but the main line loop is: developer develops app, developer submits app for approval, Apple either approves it and it goes up to the App Store, or they reject it and the developer has to fix whatever they are complaining about. Rinse, repeat. My experience with their rejection criteria was mostly that it was petty and small things that didn't have much if anything to do with security. Others may have different experiences. The huge downside is that if they reject your app for whatever reason, you have to resubmit the app for approval once you're done, and...Wait. A long time. If you were fixing a critical bug -- including a security bug! -- tough noogies.

Now Apple has always been very secretive about what their testing entails. We weren't trying to build an app to probe the surface of their security testing, so it's really hard to say what it might involve. Maybe they do find both malicious and unintentional problems. Maybe they find that a lot. Who knows? But there is a gigantic hole, like you could sail the Titantic through it sized hole, that makes all of that testing complete useless, especially if you're a bad guy.

Using WebViews

When we were building the Phresheez app, it became pretty scary to think about writing and maintaining two different UI's. A common language between the two would be very useful. And as it happens there is: javascript. Both Android and iOS have what are known as webviews (UIWebView was what we used on the iPhone). Webviews are pretty much what they sound like: embedded web browsers that an app can display on the phone. More importantly, the app can communicate with the code running in the webview bidirectionally. This is very handy: we wrote the parts of the app that needed be written natively (mostly the GPS handling stuff), and all of the UI in the webview. Portability problem solved.

There's one other important property about all of this. Since it's just web stuff (html, js, css, etc) the app can either get it locally from the app's assets, or make a request to some server somewhere, or both. So we bundled up all of this stuff up into a zip ball on our backend servers, and the app would know how to go fetch the zip ball and download it into the webview. Remember about all of that waiting for reviews? Problem solved.

The Hole

There is nothing nefarious about what we did. We had perfectly legitimate reasons for doing this, and Apple does not have a policy against this. I'm not sure they could ever have a policy banning that because that's just the way the web works: you can just add script tags in the html that point to a remote server and that's perfectly legitimate. How does this make all of Apple's so-called vetting security theater? Well if it's legitimate to load javascript code from an external server from a good guy, it's legitimate to load it from an external server from a bad guy. And a clever bad guy could even go to the trouble of cleanup their malware while they are in App Store review, and then switch back to the evil code after.

Wouldn't that be against Apple's policies? You bet. But they would be none the wiser until after the app was deployed. Which is the exact same situation that Apple fanboys love to make fun of Android. You put your evil stuff in javascript, run the webview, PROFIT! Note: the webview doesn't even have to be part of your UI... it's just a vehicle to run javascript if that's all you want to do.

The Pooch, She is Screwed

This feature has been in iOS from the very beginning, and there are tons of hybrid web/native app packages out there. To close this hole would be to break every single one of them, and for that matter probably break every app that uses a webview at all. So they realistically can't do that, and even if they did it would be catastrophic. Apple really doesn't need to spend much if any resources behind the curtain to preemptively root out bad guys. Any bad guy worth their salt would already know this trick. If Apple does spend lots of resources, it's just a marketing expense.

This is why I've been saying that so-called vetting is all a bunch of security theater. This was always a marketing thing and nothing more.