
Authentication and the Have I Been Pwned API - Rels
https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/
======
zaroth
All this seems to be hinting more than ever, that the time to provide these
results directly and exclusively to the email address being queried is
approaching.

Why is this API being abused? Because it provides valuable information—which
took a significant amount of effort to curate—about an email address.

The list of services which have lost my (hashed or not) password at some point
ever in the past eventually turns into a list of every service I’ve ever
subscribed to.

Whether or not it’s possible to scrape that information together, is it really
something that should be available to pull over an API for a million emails a
month?

Note this is very different information than the password breach count, which
gives you an approximate count of how many times a given password has been
breached, and works as a proxy for password strength without disclosing any
PII.

~~~
diminoten
Sorry, but the cat is out of the bag. HIBP is evening the playing field,
making the data less valuable to those who have the skills to collect it.

It's the same thing as responsible/full disclosure; by making this information
available to anyone (publish a vulnerability), you greatly reduce the power of
those who have the skills to collect it anyway (the person who found the
0day).

So yes, this information needs to be available, or it'll only be some people
who have it, not none, and those few people who do have it will be 10x
stronger than they are now.

This is the old Antisec debate all over again, let's skip to the part where we
end up agreeing generally that disclosure is better, okay? No need to relive
2009 or whatever.

~~~
nwah1
"Disclosure" could mean many things. The idea of providing the info directly
via email to the affected user seems to adequately disclose things to the
relevant parties.

Are there additional benefits of the public api that on balance benefit the
public more than attackers?

~~~
diminoten
Yeah, the availability of the data being common rather than rare, so the skill
of collecting that data doesn't create a power structure where only the
hackers/skilled users have power.

Imagine it being $500/month to access HIBP, because that's the alternative,
not some, "everyone agrees to only use this info for good".

~~~
jtbayly
Explain to me how anybody besides myself can use info about _my_ leaked
account for something good or useful.

I can’t think of an example.

Therefore, having that info cost more is better. Having it cost a lot more is
a lot better. (I’m assuming _I_ can still get access for free by having
provided directly to my email address.)

~~~
diminoten
What? No, you're not understanding. Even _if_ no one but you could use this
info legitimately, the fact that it's widely available depowers the people who
have the skills to collect it (specifically, people who want to do you harm).

By virtue of the fact that this info is widespread, you have no choice but to
take actions to protect yourself from this information. That means the
information becomes useless.

You are, in a way, being shamed into acting, through public disclosure. So no,
having that info cost is not more better, it's more worse.

Furthermore, it is not an option to _only_ let you have this information. That
ship sailed when the breaches happened. You don't get access to this
information for free, you don't get to control the dissemination of this
information, you are powerless. You're acting like HIBP is the only way people
can find this info out; it's not. That $500 price tag is _just for you_.
People who are more skilled than you or I at collecting this info get it for
free, and that's never going away.

~~~
jtbayly
You can’t have it both ways. Either it’s widely available, or it isn’t.

If it’s already widely available then HIBP doesn’t accomplish anything. (It
doesn’t anyway, since it doesn’t “shame” anybody except people who are already
signed up, who only need and get their own info.) If it isn’t widely available
then HIBP is helping people who are bad at collecting and using this
information to do so.

We accept that from bug reports only because of the other benefits that come
from releasing the info.

~~~
diminoten
You're not getting that the alternative is much worse.

Your data is out there. Period. The end. You don't have control over that. All
you're doing is trying to re-establish control over data you already lost.

The question now is, do you want it _only_ in the hands of people who want to
harm you, or do you want it in the hands of both people who want to harm you
_as well as_ people who want to help you?

You seem to only want bad guys to have your data. That's weird.

~~~
jtbayly
Thanks for the explanation. I get your point now. I did not find BFDM’s
proposed benefits from white hats having access to be compelling. So what I’m
struggling with is simply the idea that anybody could do something good with
my data. If only bad can be done, then the fewer people spreading the data
around, the better. Your presupposition is that some people will do good with
it if they have access that currently only bad people have. Can you give an
example of one of some of those good things?

~~~
diminoten
1Password tells you which of your passwords have been part of a breach. Many
other companies will suspend the accounts of anyone whose login information to
_their_ leaked as part of another site's breach.

Other websites won't allow you to use a password that's listed as a common
password from the aggregated passwords in breaches.

Lots of studies have been done on password frequency, such as the top 100 most
common passwords and what security people can do about their repeated use.

Based on your question however, I'm concerned you don't actually get my point.
You're being forced into action, exactly how companies are forced into action,
by the availability of this information. You _have_ to change your password if
it's easily available to anyone who uses this API and who has your email
address, you no longer get to pretend it's not a big deal.

~~~
zaroth
> 1Password tells you...

This is software acting as an agent of the effected user. 1Password could be
authorized by the email holder to gain access to the API without making the
information public.

> Other websites won't allow you to use...

This and the following example in your comment are discussing the breached
password API, which is a completely different API that I specifically
mentioned up-front as not compromising any PII.

I take zero issue with providing an API to see counts of how many times a
password has shown up on breach lists, although I wouldn't use the API myself
on any of my own passwords, because it leaks a 1-in-1-million discriminator to
the actual password you are querying.

~~~
diminoten
You don't get to take issue with any of this. Your information was already
stolen! You have no say, the end.

~~~
jtbayly
So your fallback position is that it is perfectly legitimate to traffic in
stolen PII. Got it.

Well, I take issue with that.

~~~
diminoten
Yes, in some cases it's perfectly legitimate to "traffic" (terrible word
choice) in stolen PII, that is correct.

And my "fallback" position is that it's better this way than the other way,
where it's actually being trafficked, rather than your hyperbolic assertion
that it is now.

------
theandrewbailey
> Making an authenticated call is a piece of cake, you just add an hibp-api-
> key header as follows:

> GET
> [https://haveibeenpwned.com/api/v3/breachedaccount/test@examp...](https://haveibeenpwned.com/api/v3/breachedaccount/test@example.com)

> hibp-api-key: [your key]

Wouldn't the standard Authorization: Bearer <key> header be more compliant?

~~~
pionar
No, because it's not a bearer token.

Edit for clarity: A bearer token [0] is a concept for OAuth. This is not
OAuth.

[0]
[https://tools.ietf.org/html/rfc6750#section-1.2](https://tools.ietf.org/html/rfc6750#section-1.2)

~~~
Androider
OAuth doesn't have a monopoly on bearer tokens. And it is literally the
definition of a bearer token: you shall know the messenger who presents this
token, a concept old as history itself.

~~~
y4mi
Should every OS which uses windows be able to call itself Windows, because
windows are a quite old thing as well?

Like it or not, there _is_ an rfc for this and using it for anything else
would be code smell at best

~~~
patmorgan23
> Should every OS which uses windows be able to call itself Windows, because
> windows are a quite old thing as well?

> Like it or not, there is an rfc for this and using it for anything else
> would be code smell at best

No but every OS that uses windows can call them windows....

~~~
y4mi
I guess they should be able to call them windows.

Can you link to any tool which uses bearer tokens and doesn't grant them
through oauth2?

Or it's internal, please explain how the token is obtained.

I haven't seen any to date but I guess I could be wrong

~~~
X-Istence
Github will happily hand you an access token by visiting
"[https://github.com/settings/tokens"](https://github.com/settings/tokens").

These are bearer tokens, in that the bearer gets granted access by that token
alone.

You happen to send it along in a Basic authentication in HTTP instead of as an
Authorization header, but it is a bearer token all the same.

No OAuth2 flow required.

~~~
X-Istence
Any service that uses API keys are basically handing out bearer tokens.
Whoever holds that API key can make requests to the service, it grants you
access.

------
jawns
I wish the post made more clear, ideally right at the top, that the new fee
applies only to third-party apps that access the HIBP API, not to end users
whose email addresses are being checked against the API. You have to read
through the post a bit before that becomes clear.

Individual users who just want to figure out whether they've been pwned will
not have to pony up the cash. They can still visit
[https://haveibeenpwned.com](https://haveibeenpwned.com) and get that
information for free.

~~~
nathan_f77
It would also be great to emphasize that this only applies to the HIBP API,
and the Pwned Passwords API will still be free. (It's mentioned about half-way
through the article.)

~~~
jrochkind1
Hm, I didn't actually realize there was a separate Pwned Passwords API. Having
trouble finding docs on it (could be becuase I'm a horrible googler).

~~~
bpye
Pwned Passwords is detailed towards the bottom of the API page -
[https://haveibeenpwned.com/API/v3](https://haveibeenpwned.com/API/v3)

------
JoshTriplett
> Late last year after seeing a similar pattern with a well-known hosting
> provider, I reached out to them to try and better understand what was going
> on. I provided a bunch of IP addresses which they promptly investigated and
> reported back to me on

I'd love to know how to get a hosting provider to actually _answer_ such
requests. (I hope the answer isn't just "be high profile". I'm hoping the
answer is more like "know the right people to contact or the right phrasing to
get through first-line support".)

I've reached out to hosting providers before, providing clear logs of
malicious activity, and either gotten no answer, or occasionally gotten a rote
"prove it came from us" that would trivially have been answered by actually
reading the logs.

(Examples of such logs include SSH brute-forcing attempts, HTTP logs showing
attempts to exploit web-app security holes, and spam headers showing the IP
that contacted my provider's mail server.)

I've mostly stopped even trying, due to the near-zero response rate.

In an ideal world, I'd love to see reports like this lead to "we can confirm
and we've shut down outbound traffic from that system until it gets fixed".

~~~
coderholic
How are you contacting them? If you use the correct abuse contact you'll
usually get a response. We (IPinfo.io) are adding abuse contact info to our
API within the next week or so (see
[https://twitter.com/ipinfoio/status/1138901541937602560](https://twitter.com/ipinfoio/status/1138901541937602560))
- let me know if you'd like early access.

~~~
JoshTriplett
Typically via abuse contacts or abuse forms.

The only type of service providers I've _ever_ had useful responses from are
email/mailing-list service providers, many of which will very quickly
investigate and terminate spammers.

------
novaleaf
I feel his pain.

I run a SaaS with what I think is a pretty generous free tier (PhantomJsCloud
dot com), and yeah, I have numerous people from all over the world doing their
best to shit all over it:

\- switching IP addresses every request to circumvent "demo user" rate
limiting

\- creating upwards of 100 fake accounts to get free credits ($0.05/day each
account)

\- embedding api calls into their webpages so their users ip address is used
for "demo user" credits

\- API driven credit cards and hijinks around that.

\- using url shorteners to circumvent blacklisted domains

I'm not sure if it's a case of people being incapable of paying credit cards,
or just their ethics allow stealing anything that's not bolted down?

I don't mind people signing up with a burner email address, but unfortunately
most these abusers are too. I am going to be banning all throw away email
accounts soon. And if that doesn't work (which it probably wont) I'm going to
have to kill my free tier.

~~~
peterwwillis
Can you do what the big cloud providers do, and demand a "real" phone number
be verified for sign-up? Not impossible to beat, but more costly. Or maybe
there's a market for paying customers somewhere between your free and paid
tiers?

~~~
novaleaf
My lowest paid tier is USD$10/mth. As my target audience are developers, I
think it's hard to believe that any of them would really be unable to pay
that, yet still gain value from my service.

Maybe I'm just a peace loving hippy but I'm rather shocked at the levels of
abuse I see. I do want to enable paypal, just in case it's a lack-of-
credit/debit card issue.

------
ksahin
"After 4 and a bit years, by far and away the most popular method with an
uptake of more than 90% is versioning via the URL. So that's all V3 supports.
I don't care about the philosophical arguments to the contrary, I care about
working software and in this case, the people have well and truly spoken. I
don't want to have to maintain code and provide support for something people
barely use when there's a perfectly viable alternative."

Well said !

~~~
mehrdadn
Funny thing is here I am wondering why he didn't pass a query parameter
instead of altering the path or adding a header to version the API... does
anyone know? It has the advantage of being clickable while not implying the
resource is different.

~~~
floatingatoll
One reason could be constructed by example, as:

    
    
      <Location /v3>
    

vs.

    
    
      <LocationMatch ?[.*&]v=3(&|$)>
    

Which is to say that, depending on the application's coincidental design and
structural choices over time, managing versions at /v1 /v2 /v3 might well be
vastly easier for the "shoestring budget" operator than at /?v=1 /?v=2 /?v=3.

~~~
mehrdadn
It seems unlikely considering the other 3 were more drastically different and
yet seen as pretty equally easy.

------
elamje
I wonder if this actually has more to do with trying to sell HIBP, than abuse.
He just announced that he was selling HIBP a month or two ago. Presumably, if
he can get people to pay a nominal fee now for access to the api, it makes
HIBP much more valuable to a potential acquirer. If you can prove people are
willing to pay $.01/month for a subscription, you can assume(as a potential
acquirer) that they would pay $.02/month in the future. Much harder to sell
something that is completely free because of the risk that monetization
completely fails later.

In previous blog posts he mentions that he gets 99.x% cache hits on
Cloudflare, then also has a cache on his Azure service. He is sponsored by
Cloudflare and Microsoft and doesn’t pay for the service unless something has
changed since a few months ago. If that is still true, I don’t fully buy that
he is actually spending money on Microsoft api hits as the post claims.

But, I like Troy and HIBP, so maybe I’m just too much of a skeptic :-)

------
skybrian
Very understandable, and also yet another example of why we can't have nice
services on the Internet. Traffic from bad actors pushes anyone offering an
API in a similar direction, or discontinuing it altogether.

------
birdman3131
I find it ironic that a site dedicated to seeing if you have been compromised
has no method of changing your API key if it is compromised.

~~~
incidentnormal
Even though he explained why (it is likely a forthcoming feature), I did enjoy
this comment.

------
londons_explore
Who bruteforce scrapes the HIBP API across many IP addresses when they could
just download the original leaked username & password databases?

Theres even a torrent file of all of them I won't link here...

~~~
rolltiide
Torrent file Of ALL leaks?

I usually only see some

And when people ask about a latest leak, others disingenuously reply “just
check YOUR email on HIBP what kind of person needs the database”

~~~
necovek
If you run a web service and want to proactively expire breached passwords,
you need to have full list of plain-text passwords to hash them with algorithm
you are using (and use the same salt if you are doing that too).

------
yjftsjthsd-h
Obvious next concern: Will bad actors just scrape the website? Putting
authentication and payments in front of that rather defeats the entire point,
and without that you're back to rate limiting which is exactly what has just
been declared as a failed approach.

~~~
abathur
Probably.

But you can justify a significantly more restrictive rate limit for a website
form intended for individual mortal humans to check their own personal email
addresses for breaches.

The API has to support request frequencies for legitimate usage that are
obviously exploitable at a sufficiently small scale to attract a few
exploiters...

------
zxcvbn4038
Adding authentication so you know who is using your service is reasonable, but
not sure why author is complaining about 1.2M requests per day, that is only
14 requests per second on average.

~~~
floatingatoll
They consider those requests to be "bad actors". It's not necessarily about
the volume of traffic, it's that they are compromised VPSes configured to
perform unknown malicious activity that takes advantage of a free endpoint in
support of unknown malicious intent. See also "Why do bad actors abuse this
endpoint?" discussion elsethread:
[https://news.ycombinator.com/item?id=20480230](https://news.ycombinator.com/item?id=20480230)

~~~
wolco
Wouldn't most api traffic come from vps's regardless of the intent?

~~~
floatingatoll
The article notes that the VPS providers indicated that those top API traffic
consumers were all a specific cron.php on compromised VPSes, so while in
theory your statement is true, in reality the issue here was maliciously-
compromises VPSes, not VPSes in general.

------
w8rbt
I obtain the SHA1 hashes published by HIBP, load them into a bloom filter and
use that for checks. It's super fast (constant time lookups) and avoids a
network dependency/third party service. Here's working Go code:

[https://github.com/w8rbt/bp](https://github.com/w8rbt/bp)

Edit: This is solely for password vetting during account creation and password
reset (which will remain free/no-cost in the API).

------
sucrose
Why are bad actors abusing the API? What benefit does it give them to just be
able to check for leaked data on e-mail addresses? Especially when it doesn't
actually provide the leaked data...

~~~
geddy
Perhaps they hammer it inefficiently or simply too often, possibly without
even realizing it?

~~~
smacktoward
Never underestimate the potential impact of stupid people in large numbers.

------
sroussey
Makes sense. I was writing an email to Troy that he can post about how to set
custom user agent in Electron and Cordova, as the defaults fail. Guess it
won’t be needed.

------
Aeolun
I don’t use this API myself, so it doesn’t really effect me, but this somehow
feels like one of the last purely good things was lost.

------
Daviey
Next step, premium access without rate limit?

------
DINKDINK
All the ways congestion controls are implemented on the web lead to a
cognitively infantilizing UX, privacy violations, and even "skynet"
enabling[1] (hyperbolic but nothing stopping it from happening).

"Are you really human? What's: 3 x 9"

"Can you click on images of buses?, hmmmm don't believe you're human still,
can you click images of stores, hmmm now bikes, hmmm now vehicles, oh I didn't
mean all vehicles I just meant autos and not motorcycles, here quick copy this
token, oh it expired? Too bad. How about you click on images of buses for
me..."

"Sorry, browsers that protect your privacy and location aren't allowed. We
only allow users who are willing to deanonymize themselves."

"Well we all know / _those people_ / who come / _that place_ / are antisocial
users"

"Here's your IP addresses back. Oh yeah, sorry about blacklisting them"

This is a comment about the meta issue Troy faces. If costs are
rubegoldberg'ed to create a facade of "free", it's not actually free (even if
user data isn't being sold). e.g. A median-wage (10e3USD/year) world worker
spending 20 seconds solving a captcha has an opportunity cost of 0.03USD[2].
Further more, having to solve congestion issues by implementing requirements
to use closed/inaccessible (credit cards) poorly programmable, sucks too.
Additionally, if a congestion solution is ("I'd rather low-demand users have
free access and high-demand users have expensive access) isn't solved by
having a flat rate (which a "keep it low cost, mantra is incentivized to keep
low"). There is market demand for: If your demands on my service are x, I'll
give you back the $3.50 but if you consume y resources You have to pay Z.

Wouldn't it be great if there was a way machines could own money, send it over
a layer-2 network, that was open, cheaper than credit cards, faster than L1
bitcoin, and get your money refunded if you didn't demand excessive server
resources, all while not using game-able "good users come from here" privacy
violating algos?

This is why micropayment using layer-2 bitcoin on the Lightning Network has
significantly-valuable, latent, economic-coordination implications.
Micropayments aren't about paying for 1/1000 of a peanut. They're about
obviating all the engineering, social, product costs dealt with dealing with
Marginal Value, Marginal Cost issues. BAD: The marginal cost of anti-DoS
counter measures can always be above the marginal value of deploying them
("listen folks it costs to much to keep this service running, we'll have to
shut it down". UNSTOPPABLE: If a price is put on service requests (Services on
Demand)[3] the marginal value will never be below the marginal cost ("I can
keep this AED locator map service running because I know a spamming request
will incur costs above my production costs").

In a future where L2 Bitcoin payment/Lightning client infrastructure is
prevalent, gone will be the days of annoying, productivity-draining captchas,
attribute-discriminating access. Troy could charged a 0.01USD "bond" payment
for a request (Which he could give back fast and costlessly to a low-demand
user). Meaning the 14e3/min requests for 3 hours would have required the high-
demand user a payment of $25,000USD[4].\

0.01USD refundable payment for honest users.

$25,000 USD penalty for high-demand "spammer"

[1] [https://i.redd.it/pb5nggw3rulz.jpg](https://i.redd.it/pb5nggw3rulz.jpg)

[2] 20/60/60 * 5

[3] [https://medium.com/@soddiraju/the-not-so-micro-potential-
for...](https://medium.com/@soddiraju/the-not-so-micro-potential-for-
micropayments-c581d3090d47)

[4] 14e3 * .01 * 60 * 3

~~~
skybrian
That would only solve paying for services if you are an amoral service
provider and don't care where the money really comes from as long as you get
paid.

It doesn't do anything for people who don't want their services used by bad
actors, which is increasingly the case these days - see all the people
concerned about privacy and how big tech companies use their data. It's not
going to help for anything social where you are trying to promote pro-social
usage and discourage anti-social usage, however you define it.

Those concerns inevitably lead to things like "know your customer" and supply-
chain policing. You can still build nice services, but not anonymous ones.

The issues are pretty much the same as TOR. Some people are willing to run TOR
nodes because the good outweighs the bad, others get squeamish about child
pornography and say: no thanks.

And that's why it's an API. If the "have I been owned" database were harmless
and there were no concerns about bad actors, it would be a torrent, not a
service.

~~~
DINKDINK
>It doesn't do anything for people who don't want their services used by bad
actors, which is increasingly the case these days

My comment illustrates precisely how such an incentive structure denies high-
resource demand users.

>That would only solve paying for services if you are an amoral service
provider and don't care where the money really comes from as long as you get
paid.

This makes no sense to me, sorry. Are you claiming that anyone who accepts
cash payments is amoral because a euro/dollar bill could be stolen and
equivalently people who accept bitcoin payments are amoral because they don't
surveil their customer's financial history?

~~~
skybrian
By "amoral" I don't mean immoral, I mean you don't care what anyone does and
you're happy not knowing the consequences of your actions.

Depending on what you're providing, maybe that's fine. In the open source
world, we give away code all the time, to everyone. Most public reading
material is fine.

But services differ and for some services of interest to bad actors, many
people are concerned about the consequences when they do business.

------
Nullabillity
Looks like AgileBits is getting scared.

------
dustinmoris
> One thing I want to be crystal clear about here is that the $3.50 fee is no
> way an attempt to monetise something I always wanted to provide for free.

If this was true, then all revenue made from those 3.5 would get donated to a
worthy cause, not donated into Troy's own pocket. I am not saying that he
shouldn't monetise it, but please let's be honest about it.

> The point is that the $3.50 number is pretty much bang on the mark for the
> cost of providing the service.

The cost of the service is the actual final bill which has to be paid for this
service, taken into account all the free credits Troy gets as a Microsoft
Regional Director, free credits for hugely advertising Azure at every
occasion, free credits from Cloudflare for constantly advertising for them,
the tax which he doesn't pay as a registered company, etc. divided by the
actual amount of customers who use the API. This cost could be much more, or
significantly less than $3.5. If Troy wanted to be more transparent then he
could, but given that he is very secretive and very selective about the bits
of information he shares around all of this, my guess is the cost is much less
than what Tory makes everyone believe.

Overall I don't think it is ethical to monetise a service which is built on
stolen data. There is a good chance that Troy holds data on me, my parents, my
sister, wife and lots of other people who's data have been breached over the
years and have no idea who Troy is, what the heck HIBP is or even know how to
contest or request from Troy to remove their data from his service, yet it's
being used for monetisation.

There was never a consent from anyone to hord our data. It's stolen, and only
because stolen data is easily discoverable on the internet doesn't make it
alright to actively search, store and monetise that data. It's still stolen
and should get deleted from everywhere.

~~~
jtbayly
This is such a clearly useful, legitimate service. You cannot tell the bad
guys to delete your data. The next best thing is to be alerted when your data
is found in a bad guy’s trove.

~~~
dustinmoris
It's not that clear cut unfortunately.

What do you really know about Troy and his service? Really just what he wants
you to know.

For example, Troy stores extremely valuable information about millions of
people without their consent. A lesbian women in the Arabs, who might have had
her credentials breached on a gay forum, who also has a gambling addiction and
had her password breached on a gambling website and on another dating website
for prostitution services might not want some Aussie guy selling all that
information about her to anyone who pays him money. There is nothing,
absolutely nothing ethical about this!

My sister does not know anything about Troy, I showed her his Twitter profile
and the first things which stood out to her:

\- Old man

\- Orange skin like Trump

\- Loves to show off outdated cars

\- Making occasionally snarky comments about Indians, Indonesians and other
Asian people, always suggesting that anything illegal is coming from those
countries

\- Constantly tries to self validate himself by bragging with something
expensive he's recently bought in life

\- Very capitalistic and money focused individual

It's not great optics for people who have never seen his blog. His blog is
just marketing at the end of the day. There is no regulation, no actual
organisation or anyone who can be held accountable for gross mishandling of
the data.

It's just an old Aussie guy who stores hordes of stolen data on his private
laptop and in his private cloud and sells it to other people who clearly gain
benefit from collecting that data from his service.

There is trust and naivity, and in this case anyone who doesn't find it
slightly dodgy is simply naive. Sorry, but that is the reality.

~~~
bbatsell
I am trying to assume good faith, but I confess to being incredibly confused
by this post. I just skimmed the last two months of Troy’s tweets (which
constitutes quite a few — he is prolific) and couldn’t find a _single_ one
that matches up with any of your summations. Would you mind showing your work?

~~~
gjm11
I'm wondering whether (deliberately or accidentally) dustinmorris pulled up
the wrong Twitter profile or something. No part of his description seems to me
like it has any connection with reality.

