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.

Don't Eat Webauthn, it's Made of HOBA's!

So I recently heard about a new W3C standard called Webauthn. From what I can tell it's very much in the spirit of our HOBA RFC (RFC 7340). Ours was more of a sketch of what could be, and my javascript implementation of one of the alternative ideas in the RFC was a truly horrible hack and I knew it, even if I did try to justify some of the sketchier aspects of it. But it was 2012 and the working group didn't even spin up till 2015, so we were clearly ahead of our time.

It works pretty much like my javascript implementation, but with much better crypto, credential storage, etc, etc. But it also goes on to specify interfaces to signing dongles which is good for what it's trying to do, but I'm seriously worried that people are going to think that webauthn *requires* portable keys, biometric, etc. That would be a shame because the real enemy is not passwords, per se, it's passwords that are transmitted over the wire. And of course, their reuse. A single strong local password which is never put on a wire is perfectly fine to gain access to credentials. That's pretty much what we do today with password managers, browser fill-in-the-blanks, etc.

The reason I think that's bad is because I worry that site owners doing their own authentication will view it as niche if they think it's required to have something other a local password. Why would Epicurious implement this if they thought it was just going to be the slice of people who have access to these things? Remember, not everything is done on phones so counting on, say, biometrics only works for some of the use cases. That would be a very bad result, as webauthn using a local credential store password is a perfectly fine thing to keep others out of my super secret recipe box.

One of the things I did with my part of HOBA is elaborated quite a bit on the enrollment problem. On the tutorial sites I found, nobody seemed to mention it. I can definitely understand why the standard itself considers that out of scope (it is), but it's a little odd that it's not getting talked about much that I've found because it's probably the hardest part of deploying webauthn server-side. Maybe my Google foo failed me, but dealing with enrollment always sucks. Since webauthn is device specific, it's going to take some guidance on how to implement it server side, and users getting used to a new routine. Fortunately on the user side, we've come a long way on enrollment with more and more sites validating that the use of a new device is ok. With webauthn, that would have to be universal.

All in all, I think this is great stuff and about time. The scourge of passwords on the wire has a real chance of going away in time as sites adopt it. Let's just not hitch it to getting rid of passwords altogether. All forms of credentials have their own set of issues and tradeoffs. The important part is keeping them off the wire.

Stir/Shaken Questions

I've been looking over STIR/SHAKEN stuff for dealing with Spam-o-SIP. There's a really nice problem statement (rfc 7340) which outlines all of the interactions with the legacy PSTN and its interactions with SIP gateways and session border controllers (SBC). The gist of the resulting set of RFC's presents a pretty complicated architecture with Policy Administrators (PA) (I assume something like the ITU or some other such creature) which does admission control of who is allowed to join the telephone number bearing club, delegated CA's to sign club member's certs, and then a sort of peculiar over-the-wire signing and verifying service within each provider. From my understanding this is all within a SIP network -- anything beyond a PSTN gateway is terra incognita if the gateway switch is relaying it from a source it does not control. But that's just a previously unsolved technical problem, I think, and the layer 8 solutions from the past may still be effective, re: Caller ID. Now I must fess up that I only recently heard about this, so my characterizations are likely to have flaws or be downright wrong, so take this with a grain of salt.

Plain Old SIP

My first question is whether this is intended to be a solution for plain old SIP URI's as well? If so, it's sort of worrisome to have his PA entity determining who can join the club for an all-IP service. Binding telephone numbers to particular carriers and making certain that the carrier is part of the telephone number club is a much different problem space than SIP-SIP with no telephone numbers involved. Assuming that is not intended to solve for that problem, is there a way to identify either the end user URI, or aggregated at provider boundaries on, say, a domain basis? With DKIM, we chose to allow mail providers to sign the mail with their domain -- whether or not they are the originating domain -- to say "blame me".  This gives the originating provider some incentive not to be blamed by requiring MUA authentication, etc.

RFC 7340 talks about SIP Identity (rfc 4474) and I can certainly understand the issue with B2BUA's which have analogs in the email universe (cf mailing lists). With DKIM we essentially punted and declared that the breaking gateway should sign the mail anew, and that they are now the one to blame. This seems to have worked out ok, as far I can tell. Dealing with spam is all about messy heuristics and I expect that SIP spam will be no different. The general idea is to be able get enough clues about bad actors as part of the full set of clues.

DKIM for SIP?

It has always seemed that a DKIM like approach would work for SIP as well. It has the nice property that it doesn't require a centralized CA. I'm too lazy to look up SIP identity, but I'm guessing that it does require them in some form. The web got lucky with TLS because there were only a very few browsers and the accepted CA root list was controlled by them before things could get out of control. With SIP, it's been around a long time and SIP Identity didn't get much traction from what I read, so I'm not sure if that's part of the problem, or is just academic since it just didn't get deployed.

DKIM for SIP would be fairly trivial to implement. In fact, I hacked together a SIP proxy that signed and verified SIP messages. And, of course, the infrastructure is all there as DKIM at this point is really old and really widely deployed. If SIP Identity doesn't get used for whatever reason, and we don't have a deployed solution for SIP-SIP calls, that seems like a really big hole. Fortunately, we have an existence proof with email which could be retrofitted pretty easily.

Is this Partly a UI Problem?

When I receive a call, my phone does the best it can to tell me who it is rather than giving me just a plain old telephone number. In fact, that's one of the best ways to determine whether it's spam is if you don't recognize the number. At this point, we are all very comfortable using email addresses as identities. So what I'm getting at is why doesn't my phone app take plain old SIP calls and treat them equivalently? In which case, it can use the From: address rather than some Paleolithic telephone number. There's nothing stopping Google or Apple from adding a new SIP protocol head onto their existing call apps, after all. This would at least break the notion that legacy telephone numbers are the only ID I should see when I get an incoming call. Hopefully the legacy PSTN calling will be winding down in the next 10 years or so, but we certainly don't want to carry along legacy telephone anachronisms into the future of an all SIP infrastructure. 

Signer and Verifier Services

This is more of a quibble, but I really don't understand why there needs to be a separate on-the-wire protocol for SIP proxies and authentication. With DKIM, the signing and verifying are done in the MTA, and it demonstrably works just fine. The CPU cost of signing these days is minuscule, and verification was always nothing. Plus, it costs time to send something over the wire and get a response, and with SIP that is a consideration. So I just don't get what motivated this.

Conclusion

While I think this looks like good work, I'm worried that it's putting a lot of time and energy into dealing with a legacy issue, and perhaps either not dealing with the SIP-SIP case, or dealing with it in a way that requires being invited to a club.  Either would be very bad. We really should be trying as hard as possible to make plain old SIP the way people expect to get a "phone call", and SIP itself needs to be able to have a workable solution that doesn't depend in any way on legacy PSTN stuff or we're going to be in the same boat a few years down the line.