revise and publish rethinking identity

1 files changed, 292 insertions, 0 deletions

diff --git a/_posts/2018-10-25-rethinking-identity.md b/_posts/2018-10-25-rethinking-identity.md
new file mode 100644
index 0000000..d3520d7
--- /dev/null
+++ b/_posts/2018-10-25-rethinking-identity.md
@@ -0,0 +1,292 @@
+---
+title: Rethinking Identity
+description: >-
+    A more useful way of thinking about identity on the internet, and using that
+    to build a service which makes our online life better.
+---
+
+In my view, the major social media platforms (Facebook, Twitter, Instagram,
+etc...) are broken. They worked well at small scales, but billions of people are
+now exposed to them, and [Murphy's Law][murphy] has come into effect. The weak
+points in the platforms have been found and exploited, to the point where
+they're barely usable for interacting with anyone you don't already know in
+person.
+
+[murphy]: https://en.wikipedia.org/wiki/Murphy%27s_law
+
+On the other hand, social media, at its core, is a powerful tool that humans
+have developed, and it's not one to be thrown away lightly (if it can be thrown
+away at all). It's worthwhile to try and fix it. So that's what this post is
+about.
+
+A lot of moaning and groaning has already been done on how social media is toxic
+for the average person. But the average person isn't doing anything more than
+receiving and reacting to their environment. If that environment is toxic, the
+person in it becomes so as well. It's certainly possible to filter the toxicity
+out, and use a platform to your own benefit, but that takes work on the user's
+part. It would be nice to think that people will do more than follow the path of
+least resistance, but at scale that's simply not how reality is, and people
+shouldn't be expected to do that work.
+
+To identify what has become toxic about the platforms, first we need to identify
+what a non-toxic platform would look like.
+
+The ideal definition for social media is to give people a place to socialize
+with friends, family, and the rest of the world. Defining "socialize" is tricky,
+and probably an exercise only a socially awkward person who doesn't do enough
+socializing would undertake. "Expressing one's feelings, knowledge, and
+experiences to other people, and receiving theirs in turn" feels like a good
+approximation. A platform where true socializing was the only activity would be
+ideal.
+
+Here are some trends on our social media which have nothing to do with
+socializing: artificially boosted follower numbers on Instagram to obtain
+product sponsors, shills in Reddit comments boosting a product or company,
+russian trolls on Twitter spreading propaganda, trolls everywhere being dicks
+and switching IPs when they get banned, and [that basketball president whose
+wife used burner Twitter accounts to trash talk players][president].
+
+[president]: https://www.nytimes.com/2018/06/07/sports/bryan-colangelo-sixers-wife.html
+
+These are all examples of how anonymity can be abused on social media. I want
+to say up front that I'm _not_ against anonymity on the internet, and that I
+think we can have our cake and eat it too. But we _should_ acknowledge the
+direct and indirect problems anonymity causes. We can't trust that anyone on
+social media is being honest about who they are and what their motivation is.
+This problem extends outside of social media too, to Amazon product reviews (and
+basically any other review system), online polls and raffles, multiplayer games,
+and surely many other other cases.
+
+## Identity
+
+To fix social media, and other large swaths of the internet, we need to rethink
+identity. This process started for me a long time ago, when I watched [this TED
+talk][identity], which discusses ways in which we misunderstand identity.
+Crucially, David Birch points out that identity is not a name, it's more
+fundamental than that.
+
+[identity]: https://www.ted.com/talks/david_birch_identity_without_a_name
+
+In the context of online platforms, where a user creates an account which
+identifies them in some way, identity breaks down into 3 distinct problems
+which are often conflated:
+
+* Authentication: Is this identity owned by this person?
+* Differentiation: Is this identity unique to this person?
+* Authorization: Is this identity allowed to do X?
+
+For internet platform developers, authentication has been given the full focus.
+Blog posts, articles, guides, and services abound which deal with properly
+hashing and checking passwords, two factor authentication, proper account
+recovery procedure, etc... While authentication is not a 100% solved problem,
+it's had the most work done on it, and the problems which this post deals with
+are not affected by it.
+
+The problem which should instead be focused on is differentiation.
+
+## Differentiation
+
+I want to make very clear, once more, that I am _not_ in favor of de-anonymizing
+the web, and doing so is not what I'm proposing.
+
+Differentiation is without a doubt the most difficult identity problem to solve.
+It's not even clear that it's solvable offline. Take this situation: you are in
+a room, and you are told that one person is going to walk in, then leave, then
+another person will do the same. These two persons may or may not be the same
+person. You're allowed to do anything you like to each person (with their
+consent) in order to determine if they are the same person or not.
+
+For the vast, vast majority of cases you can simply look with your eyeballs and
+see if they are different people. But this will not work 100% of the time.
+Identical twins are an obvious example of two persons looking like one, but a
+malicious actor with a disguise might be one person posing as two. Biometrics
+like fingerprints, iris scanning, and DNA testing fail for many reasons (the
+identical twin case being one). You could attempt to give the first a unique
+marking on their skin, but who's to say they don't have a solvent, which can
+clean that marking off, waiting right outside the door?
+
+The solutions and refutations can continue on pedantically for some time, but
+the point is that there is likely not a 100% solution, and even the 90%
+solutions require significant investment. Differentiation is a hard problem,
+which most developers don't want to solve. Most are fine with surrogates like
+checking that an email or phone number is unique to the platform, but these
+aren't enough to stop a dedicated individual or organization.
+
+### Roll Your Own Differentiation
+
+If a platform wants to roll their own solution to the differentiation problem, a
+proper solution, it might look something like this:
+
+* Submit an image of your passport, or other government issued ID. This would
+  have to be checked against the appropriate government agency to ensure the
+  ID is legitimate.
+
+* Submit an image of your face, alongside a written note containing a code given
+  by the platform. Software to detect manipulated images would need to be
+  employed, as well as reverse image searching to ensure the image isn't being
+  reused.
+
+* Once completed, all data needs to be hashed/fingerprinted and then destroyed,
+  so sensitive data isn't sitting around on servers, but can still be checked
+  against future users signing up for the platform.
+
+* A dedicated support team would be needed to handle edge-cases and mistakes.
+
+None of these is trivial, nor would I trust an up-and-coming platform which is
+being bootstrapped out of a basement to implement any of them correctly.
+Additionally, going through with this process would be a _giant_ point of
+friction for a user creating a new account; they likely would go use a different
+platform instead, which didn't have all this nonsense required.
+
+### Differentiation as a Service
+
+This is the crux of this post.
+
+Instead of each platform rolling their own differentiation, what if there was a
+service for it. Users would still have to go through the hassle described above,
+but only once forever, and on a more trustable site. Then platforms, no matter
+what stage of development they're at, could use that service to ensure that
+their community of users is free from the problems of fake accounts and trolls.
+
+This is what the service would look like:
+
+* A user would have to, at some point, have gone through the steps above to
+  create an account on the differentiation-as-a-service (DaaS) platform. This
+  account would have the normal authentication mechanisms that most platforms
+  do (password, two-factor, etc...).
+
+* When creating an account on a new platform, the user would login to their DaaS
+  account (similar to the common "login with Google/Facebook/Twitter" buttons).
+
+* The DaaS then returns an opaque token, an effectively random string which
+  uniquely identifies that user, to the platform. The platform can then check in
+  its own user database for any other users using that token, and know if the
+  user already has an account. All of this happens without any identifying
+  information being passed to the platform.
+
+Similar to how many sites outsource to Cloudflare to handle DDoS protection,
+which is better handled en masse by people familiar with the problem, the DaaS
+allows for outsourcing the problem of differentiation. Users are more likely to
+trust an established DaaS service than a random website they're signing up for.
+And signing up for a DaaS is a one-time event, so if enough platforms are using
+the DaaS it could become worthwhile for them to do so.
+
+Finally, since the DaaS also handles authentication, a platform could outsource
+that aspect of identity management to it as well. This is optional for the
+platform, but for smaller platforms which are just starting up it might be
+worthwhile to save that development time.
+
+### Traits of a Successful DaaS
+
+It's possible for me to imagine a world where use of DaaS' is common, but
+bridging the gap between that world and this one is not as obvious. Still, I
+think it's necessary if the internet is to ever evolve passed being, primarily,
+a home for trolls. There are a number of traits of an up-and-coming DaaS which
+would aid it in being accepted by the internet:
+
+* **Patience**: there is a critical mass of users and platforms using DaaS'
+  where it becomes more advantageous for platforms to use the DaaS than not.
+  Until then, the DaaS and platforms using it need to take deliberate but small
+  steps. For example: making DaaS usage optional for platform users, and giving
+  their accounts special marks to indicate they're "authentic" (like Twitter's
+  blue checkmark); giving those users' activity higher weight in algorithms;
+  allowing others to filter out activity of non-"authentic" users; etc... These
+  are all preliminary steps which can be taken which encourage but don't require
+  platform users to use a DaaS.
+
+* **User-friendly**: most likely the platforms using a DaaS are what are going
+  to be paying the bills. A successful DaaS will need to remember that, no
+  matter where the money comes from, if the users aren't happy they'll stop
+  using the DaaS, and platforms will be forced to switch to a different one or
+  stop using them altogether. User-friendliness means more than a nice
+  interface; it means actually caring for the users' interests, taking their
+  privacy and security seriously, and in all other aspects being on their side.
+  In that same vein, competition is important, and so...
+
+* **No country/government affiliation**: If the DaaS was to be run by a
+  government agency it would have no incentive to provide a good user
+  experience, since the users aren't paying the bills (they might not even be in
+  that country). A DaaS shouldn't be exclusive to any one government or country
+  anyway. Perhaps it starts out that way, to get off the ground, but ultimately
+  the internet is a global institution, and is healthiest when it's connecting
+  individuals _around the world_. A successful DaaS will reach beyond borders
+  and try to connect everyone.
+
+Obviously actually starting a DaaS would be a huge undertaking, and would
+require proper management and good developers and all that, but such things
+apply to most services.
+
+## Authorization
+
+The final aspect of identity management, which I haven't talked about yet, is
+authorization. This aspect deals with what a particular identity is allowed to
+do. For example, is an identity allowed to claim they have a particular name, or
+are from a particular place, or are of a particular age? Other things like
+administration and moderation privileges also fall under authorization, but they
+are generally defined and managed within a platform.
+
+A DaaS has the potential to help with authorization as well, though with a giant
+caveat. If a DaaS were to not fingerprint and destroy the user's data, like
+their name and birthday and whatnot, but instead store them, then the following
+use-case could also be implemented:
+
+* A platform wants to know if a user is above a certain age, let's say. It asks
+  the DaaS for that information.
+
+* The DaaS asks the user, OAuth style, whether the user is ok with giving the
+  platform that information.
+
+* If so, the platform is given that information.
+
+This is a tricky situation. It adds a lot of liablity for the user, since their
+raw data will be stored with the DaaS, ripe for hacking. It also places a lot of
+trust with the DaaS to be responsible with users' data and not go giving it out
+willy-nilly to others, and instead to only give out the bare-minimum that the
+user allows. Since the user is not the DaaS' direct customer, this might be too
+much to ask. Nevertheless, it's a use-case which is worth thinking about.
+
+## Dapps
+
+The idea of decentralized applications, or dapps, has begun to gain traction.
+While not mainstream yet, I think they have potential, and it's necessary to
+discuss how a DaaS would operate in a world where the internet is no longer
+hosted in central datacenters.
+
+Consider an Ethereum-based dapp. If a user were to register one ethereum address
+(which are really public keys) with their DaaS account, the following use-case
+could be implemented:
+
+* A charity dapp has an ethereum contract, which receives a call from an
+  ethereum address asking for money. The dapp wants to ensure every person it
+  sends money to hasn't received any that day.
+
+* The DaaS has a separate ethereum contract it manages, where it stores all
+  addresses which have been registered to a user. There is no need to keep any
+  other user information in the contract.
+
+* The charity dapp's contract calls the DaaS' contract, asking it if the address
+  is one of its addresses. If so, and if the charity contract hasn't given to
+  that address yet today, it can send money to that address.
+
+There would perhaps need to be some mechanism by which a user could change their
+address, which would be complex since that address might be in use by a dapp
+already, but it's likely a solvable problem.
+
+A charity dapp is a bit of a silly example; ideally with a charity dapp there'd
+also be some mechanism to ensure a person actually _needs_ the money. But
+there's other dapp ideas which would become feasible, due to the inability of a
+person to impersonate many people, if DaaS use becomes normal.
+
+## Why Did I Write This?
+
+Perhaps you've gotten this far and are asking: "Clearly you've thought about
+this a lot, why don't you make this yourself and make some phat stacks of cash
+with a startup?" The answer is that this project would need to be started and
+run by serious people, who can be dedicated and thorough and responsible. I'm
+not sure I'm one of those people; I get distracted easily. But I would like to
+see this idea tried, and so I've written this up thinking maybe someone else
+would take the reins.
+
+I'm not asking for equity or anything, if you want to try; it's a free idea for
+the taking. But if it turns out to be a bazillion dollar Good Idea™, I won't say
+no to a donation...