
New fuzzing tool finds USB bugs in Linux, Windows, macOS, and FreeBSD - doener
https://www.zdnet.com/article/new-fuzzing-tool-finds-26-usb-bugs-in-linux-windows-macos-and-freebsd/
======
umvi
I don't think many people realize how complicated USB is. The USB 2.0 spec is
like 700 pages long. The USB 3.0 spec is 500 pages long and the intro
paragraph is like "readers are expected to be familiar with the USB 2.0 spec
before proceeding".

I work in embedded systems and I absolutely despair when we need to fix a USB
issue. USB is without a doubt the deepest rabbit hole I ever went down (and I
never did find the bottom, because the issue ended up being due to Synopsys's
USB core and we didn't have access to the Verilog - and apparently neither did
they! They weren't using VCS back in 2016 apparently).

~~~
dayjah
Too soon! I’m currently debugging an issue where a USB 3.2 Gen 2 scientific
camera is unable to negotiate a connection with Linux. Under closer inspection
it seems the USB 3.2 Gen 2 port on this relatively modern Intel NUC is being
identified by the kernel as being USB 2.0. No such issues under Windows; but
we’re not deploying that to the field.

So I go a bit deeper: the chip is actually a thunderbolt chip (aka USB 4.0),
which is able to emulate all of the USB specs. For reasons unknown, the two
controller chips on this NUC present as four controller chips; each chip
presents as one USB 2 root hub and one 3 root hub. One of the chips is only
available via an internal header on the board. All of the externally available
USB ports (3x USB 3 ports, 1x USB 2 port, 1x Thunderbolt port) all result in
connectivity to the USB 2 root hub.

Every fiber in my being wants to work out wtf is happening here; but I’m
resisting because fortunately we have a vendor that can replace this NUC with
one from 2016 instead of this one from 2018.

I did, of course, peek at the spec and experienced the bone-shuddering
realization of how complex this whole system is. No wonder Windows BSODd when
Gates first demoed USB on stage ...

------
hannob
I think this needs some important context, because otherwise it may be read as
"Linux is so insecure compared to the other OSes".

From the screenshot it seems all of the bugs were found with KASAN and most of
them were overread bugs. Likely for the other OSes they were only looking for
crashes and probably often missed these classes of bugs that KASAN can
uncover.

This essentially means they found more bugs in Linux because Linux has better
tools to uncover subtle memory safety bugs.

~~~
frank2
KASAN is a kernel address sanitizer. Is your claim that the other OSes, as
tested, do not do address sanitization?

~~~
johnnyapol
I think their claim is the researchers can run a Linux install with KASAN and
see the results but they are unable to use an equivalent of that on MacOSX,
Windows as Apple, Microsoft do not allow an end-user to perform that kind of
instrumentation on their own device.

~~~
frank2
You and the person I replied to above are essentially correct:

>Fuzzing drivers on [FreeBSD, MacOS, and Windows] is more challenging than the
Linux kernel due to the lack of support infrastructure. These OSes support
neither KASAN, other sanitizers, nor coverage-based collection of executions.
The lack of a memory-based sanitizer means our fuzzer only discovers bugs that
trigger exceptions, and misses all bugs that silently corrupt memory. Because
we cannot collect coverage information, our fuzzer cannot detect seeds that
trigger new inputs.

([https://nebelwelt.net/files/20SEC3.pdf](https://nebelwelt.net/files/20SEC3.pdf))

The researchers employed a partial workaround for the problem, but it is
pretty obvious to me that the partial workaround does not level the playing
field:

>To alleviate the second concern, the lack of coverage-guided optimization, we
experiment with cross-pollination. To seed our dumb fuzzer, we reuse the
inputs generated during our Linux kernel fuzzing campaign.

~~~
my123
XNU definitely supports kasan on macOS, since quite some years. (however,
kasan kernels aren't shipped by default, you can build from source though)

However, no idea if Kernel Debug Kit ships with prebuilt kasan kernel and
drivers.

~~~
saagarjha
I see a kernel.kasan inside the latest KDK. Doubt this extends to drivers, as
all I can find for those are debug symbols.

------
AaronFriel
No matter what the outcome is, remember: We should keep telling ourselves that
it is possible for someone, somewhere unaided by typechecking, memory safety
constraints, static analysis, and fuzz testing to write safe C.

We haven't found that person yet, but if we stop believing that person exists,
then why are we still writing in these languages?

~~~
nineteen999
I'm just so thankful we have so many people in the LISP, Rust and Haskell
communities ready to step up to the plate and replace over 50 years of C/C++
OS development with their grand, impervious and indestructible vision of what
a safe, secure OS should be.

All they'd have to do is provide us a stable, secure foundation and a
hypervisor that can run legacy OS's. Oh, and reimplement/replace the tens of
thousands of API's provided by Windows/UNIX/Linux which are in use by millions
of programmers everyday.

Also they'd need to be able to support all those other secure languages that
have been written in C/C++ over the years. I guess they will be able to
rewrite those as well in short order on top of their new "secure" foundation.

I'm sure it will happen any minute now.

~~~
AaronFriel
Those folks are actually chomping at the bit to be taken seriously and have
been for a very long time! Their proposition is simple: better tools can make
us better developers.

JavaScript developers have told me on a few occasions that TypeScript is
unnecessary, they can just write good JS and they don't need types! And it
doesn't even catch every bug, so why bother?

I think I'm just tired of being told that while _I_ can't write safe C, it's
because I'm not smart enough (which may be true, I guess!), but also that the
reason everyone _else_ can't write safe C is because they, too, happen to also
be not smart enough:
[https://news.ycombinator.com/item?id=23289693](https://news.ycombinator.com/item?id=23289693)

> I design high-scale database kernels, large code bases, written in modern
> C++. I can’t remember the last time we had a memory safety issue. It isn’t
> as though we don’t have plenty of bugs during development, just not those
> kinds of bugs. Competent idiomatic code simply doesn’t leave much room for
> those kinds of bugs to occur. If you “constantly struggle with memory safety
> issues”, you are doing something fundamentally wrong. That’s not something
> you can blame on the language.

>

> I am always baffled by the people that supposedly write modern C++
> professionally and constantly have memory safety issues. Most serious
> projects won’t hire you if you aren’t capable of writing memory safe code in
> your sleep, it is a basic skill.

~~~
nineteen999
> Those folks are actually chomping at the bit to be taken seriously and have
> been for a very long time!

The problem is, to be taken seriously, eventually they will need to
demonstrate that they _can_ solve the problem, rather than just talk about it.

I don't dispute the need for OS/systems development to move towards more
secure languages, that much is clear. It's just none of the "visionaries" that
talk about it so much have a clear roadmap that wouldn't put millions of
working programmers out of jobs, let alone much in the way of working
prototype code.

As such, it seems to be somewhat of a programming language enthusiasts pipe
dream. 99.5% of people who seems to working on hobby OS projects choose C/C++,
because that's where most of the accessible prior art is, and because it gives
them a snowballs chance in hell of being able to port of wide range of pre-
existing software and applications to their platform.

~~~
roblabla
What are you even talking about? First of all, the people working on the
language are obviously not going to be the people implementing the OS. There's
only so many hours in a day, and a language as large as Rust, Haskell are a
full-time job to maintain.

Rust has a bunch of hobby OS projects, and a very serious OS project called
Redox OS[0]. Redox has a libc that's complete enough to allow it to run bash
and other existing programs. It has a complete graphics stack, including its
own compositor and UI toolkit.

Meanwhile, Microsoft is actively testing Rust as a language, both for new
components and rewriting old code that would traditionally be written in
C/C++[1]. They're doing this because memory safety bugs account for 70% of
their critical bugs[2]. This is a major player in the industry, actively
looking at a memory-safe language because they find C or C++ to be inadequate.
If that's not validation enough, I don't know what is.

[0]: [https://www.redox-os.org/](https://www.redox-os.org/)

[1]: [https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-
win...](https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/)

[2]: [https://www.zdnet.com/article/microsoft-70-percent-of-all-
se...](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-
bugs-are-memory-safety-issues/)

~~~
nineteen999
Never said it had to be the language developers themselves to implement a
modern OS, my implied meaning was the vocal proponents of the languages. I
think that was fairly clear, and I don't know why you've jumped to that
assumption.

Everybody who reads HN regularly with an interest in OS design and security
and application security has heard of [0], and [2]. [1] simply says that
Microsoft is "exploring" Rust, for an "experimental" rewrite of a low level
component. That's it. No shipping code yet. I agree its a good step forward,
but let's not overstate the impact just yet. If you consider that "validation
enough", that's fine, but many others will disagree at this early stage,
especially in context of displacing an entire ecosystem of C/C++ based systems
and languages.

Lastly, Redox is a great example of what I'm talking about, people actually
putting their money where their mouth is, and I think it's great to see. It
also has 0% adoption outside of a small group of developers right now, and
clearly has a long way to go. However by shipping a libc in order to support C
programs, they risk exposing application security issues in exactly the same
manner as the type of systems they are trying to replace (surely), unless they
are prepared to develop additional proven mitigations.

Kudos to them for trying, but it remains to be seen whether they even get
enough momentum to threaten, yet alone displace the incumbents. Surely history
has shown that those platforms with the "killer applications" are those most
likely to succeed, and that many elegant and better designed systems than
UNIX/Windows have lost out to pragmatism on the part of customers/consumers.

------
conistonwater
The paper itself:
[https://nebelwelt.net/files/20SEC3.pdf](https://nebelwelt.net/files/20SEC3.pdf)

------
drewg123
The interesting bit to me is that the FreeBSD bug took 2 weeks of fuzzing to
find, but the Mac/Windows bugs were found in one day.

 _USBFuzz found three bugs (two resulting unplanned restart and one resulting
system freeze) on MacOS, and two bugs on Windows (resulting in a Blue Screen
of Death, confirmed on both Window 8 and Windows 10) during the first day of
evaluation. Additionally, one bug was found in a USB Bluetooth dongle driver
on FreeBSD in two weeks._

~~~
blablabla123
FreeBSD is definitely the system that will make it through the apocalypse. A
friend once told me he had a damaged RAM module, trying to install Windows,
various Linux distributions, nothing worked. But it was possible to install
FreeBSD and it just worked...

~~~
ken
What mechanism is at work here? Do FreeBSD hackers write code that doesn't
depend on _RAM_ working?

------
lloeki
(Honest, naïve question, I lack awareness of the Linux versioning scheme)
Isn't Linux way into 5.x land for quite some time? Is the testing of 4.20-rc2
some kind of proxy to test there were no backports of the very latest
mainline?

\----

Researchers said they tested USBFuzz on:

9 recent versions of the Linux kernel: v4.14.81, v4.15,v4.16, v4.17, v4.18.19,
v4.19, v4.19.1, v4.19.2, and v4.20-rc2 (the latest version at the time of
evaluation) FreeBSD 12 (the latest release) MacOS 10.15 Catalina (the latest
release) Windows (both version 8 and 10, with most recent security updates
installed)

~~~
codys
Since v3.0, Linux has treated the first _2_ numbers of it's version as
something that is incremented sequentially (in the v2.6 era, the _3_rd number
was used, prior to v2.6 there was a even/odd stable/unstable split)

For example, we have normal releases v4.19 then v4.20 then v5.0 then v5.1.
There will never be a v4.21.

Stable releases use the third number. v4.14.81 is a stable release of v4.14.0.

So the v4.20-rc2 statement just dates the work:

    
    
        $ git show v4.20-rc2
        tag v4.20-rc2
        Tagger: Linus Torvalds <torvalds@linux-foundation.org>
        Date:   Sun Nov 11 17:12:54 2018 -0600

~~~
gpm
Woah, so they did this a year and a half ago despite releasing this year (note
that the paper has a 2020 reference in it). Weird!

I guess responsible disclosure timelines on this sort of work must really
suck.

~~~
0xffff2
I don't know about computer security, but I've published peer reviewed
research papers in other fields and a year and a half from data collection to
publication doesn't seem unusual to me. If anything it's pretty fast.

------
peter_d_sherman
>"At its core, USBFuzz uses a _software-emulated USB device_ to provide random
device data to drivers (when they perform IO operations)," the researchers
said."

The key to sniffing out all of these "bugs" (AKA, "security concerns") is to
be able to _emulate_ , _emulate_ , _emulate_ , everything as plug-in modules
-- even down to hardware itself.

Virtual machine software does this -- but bugs (AKA, "security concerns") have
been found in Virtual Machines too, so a "welded together at the seams"
Virtual Machine is not the answer -- but rather, a modular, plug-and-play,
open interface one is -- where the data moving into and out of interfaces can
be monitored, logged, recorded, played back, analyzed, and modified easily to
implment a test condition or conditions, as need be.

A _software emulated USB device_ \-- is a good step towards this vision.

It's sort of like if we rebuilt a virtual machine from the ground up, starting
with the CPU emulation, and then said, OK, do I want to emulate this piece of
hardware in the virtual machine software itself, or do I want to proxy it out,
maybe via a serial path, ethernet/socket/ tcp/ip connection, or shared memory
proxy to another plug-and-playable (and separately testable) module...

I think we need to rethink virtual machines as they exist today. Coding an
interface in C for an existing virtual machine and saying that the job is done
is not enough; virtual machines must become vastly more modular/proxyable than
they are today. The bus of such a machine must become virtual and proxyable as
well, such that 3rd party software, modular plug-ins, could observe it in
realtime, as should memory, emulated VGA card, etc... any point there's a
connection to hardware, real or virtual is a proxy point that must be modular
and auditable by 3rd party plug-in programs...

 _THAT 's_ how you write the virtual machines/systems of the future.

Which also become the debugging systems of the future...

In fact, such a "modular virtual machine" \-- could be used by AI driven
software to run unit tests, but run them with different combinations of VGA
cards, emulated CPU's, emulated BIOS'ses, buses, controller chips, what-have-
you...

Oh... and there should be a way to interface the VM with actual hardware
chips... in other words, I have a hardware chip that is in question... emulate
the entire rest of the system, but proxy a physical connection to that chip on
a breakout board... etc.

~~~
jfkebwjsbx
Such a system wouldn’t be a VM but an emulator. They already exist and are
routinely used. There are also specialized low level emulators, too, and even
logic analyzers at the electronics level.

But all that does not really help fuzz a kernel quickly, which is much better
done with a normal VM plus an emulated device, as the researchers did.

------
fsflover
I am glad I am using Qubes OS, which isolates usb devices from the rest of the
system.

~~~
_bxg1
I always assume plugging in an untrusted USB to be security-suicide. At least
on Windows it can run arbitrary code, _by design_. Given that, these bugs
don't really affect my threat model at all.

~~~
teknopaul
I'm pretty sure I dont have an evil maid.

I do wince as my mate, who works as a binman, tests found devices on a Windows
laptop.

So far he has got is about a terrabyte of free storage and no problems.

~~~
jfk13
> and no problems

...that he knows about.

------
izacus
I wonder if any USB device actually relies on these bugs being there to
operate correctly.

~~~
jeffbee
Hard to imagine a device that relies upon use-after-free defects for its
correct functioning.

~~~
ken
"I first heard about this from one of the developers of the hit game SimCity,
who told me that there was a critical bug in his application: it used memory
right after freeing it, a major no-no that happened to work OK on DOS but
would not work under Windows where memory that is freed is likely to be
snatched up by another running application right away. The testers on the
Windows team were going through various popular applications, testing them to
make sure they worked OK, but SimCity kept crashing. They reported this to the
Windows developers, who disassembled SimCity, stepped through it in a
debugger, found the bug, and added special code that checked if SimCity was
running, and if it did, ran the memory allocator in a special mode in which
you could still use memory after freeing it."

[https://www.joelonsoftware.com/2004/06/13/how-microsoft-
lost...](https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-
war/)

------
pjmlp
And the winners are:

\- 2x double-free

\- 8x NULL pointer dereference

\- 6x general protection

\- 6x slab-out-of-bounds access

\- 14x use-after-free access

Naturally it was only due to the current shortage of those mythical C
developers that never make memory corruption mistakes.

~~~
melling
I’m not a Rust programmer but usually one interjects to say that Rust would
have prevented [some of] these issues.

Does Rust in fact prevent most of these at compile time? Any that it does not?

~~~
gpm
\- 2x double-free

Yes, it would be very weird to manage to do this in rust. It would require
screwing up badly in unsafe code. I guess the most likely way to fuck up
unsafe code in this way would be to screw up a custom datastructure like a
custom reference counted pointer (but the obvious solution is to just use the
standard ones).

\- 8x NULL pointer dereference

Yes, rust tells you when pointers might be Null (which is represented by
saying the pointer is Option<PointerType> instead of just PointerType), and
doesn't let you use the pointer in a way that implicitly assumes it isn't
null.

\- 6x general protection

These are generally memory errors, and are certainly undefined behavior, so
yes.

\- 6x slab-out-of-bounds access

"Yes" with a small caveat, depending on how you are using the slab it is
likely that Rust doesn't force you to explicitly think about the out of bounds
case and turns just silently turns the security vulnerability into a runtime
error, which might be handled farther up the stack or might cause the kernel
to halt.

\- 14x use-after-free access

Yes, like double frees. The range of possible fuckups in unsafe code that
cause this is probably slightly larger than the equivalent range for double
frees.

~~~
pml1
So the same argument that is made against the "mythical C programmer that
never makes memory corruption mistakes" is also valid for the mythical Rust
developer that never makes mistakes in unsafe code... It's two sides of the
same coin.

~~~
spieglt
But overall the two situations aren't nearly equivalent. Writing C, you're
constantly at risk of making these mistakes. Writing Rust, you can keep the
vast majority of your code safe and more closely examine the smaller unsafe
area for memory errors. (In driver development, you may have to use more
"unsafe" than for application development, but this doesn't negate the
benefits. Also the compiler output is much more helpful.)

~~~
pml1
> Writing C, you're constantly at risk of making these mistakes. Writing Rust,
> you can keep the vast majority of your code safe and more closely examine
> the smaller unsafe area for memory errors.

I think this is a fallacy...The majority of C code doesn't manipulate pointers
either. The point is, the moment that you have _any_ unsafe code (C or Rust),
it's a question of time before you will have some bugs, especially if you have
a very large number of people working on the same code base...you may be extra
careful, maybe the next guy is not...Rust is not going to magically solve
these problems for unsafe code...

~~~
toyg
I think you guys are debating whether perfect is the enemy of the good.

Rust will not make your code magically bugfree (this is basically impossible
by definition), but it will undoubtedly reduce the number of bugs in a very
significant way and nudge you towards better code.

~~~
spieglt
Exactly, it's a difference in degree, not in kind. Rust isn't perfect with
regard to memory errors, it's just massively better than C. I don't think pml1
will be convinced, but I've been working on a C project lately and I've never
appreciated Rust's memory virtues so much as when using valgrind to debug my
string and hashmap implementations. Chased a memory leak for two evenings that
was just having free() a few lines off in a function. Stupidly simple error,
but my eyes just glazed over the code from having read it so many times. In
Rust, it never would've happened because the borrow checker would've dropped
the memory at the proper time.

------
Koshkin
[http://www.usbmadesimple.co.uk/](http://www.usbmadesimple.co.uk/)

(tl;dr: USB is anything but simple.)

------
jokoon
Pretty sure the NSA has been using similar tools for at least 10 years now.

------
pmarreck
Do Bluetooth next! :)

~~~
ComputerGuru
The FreeBSD vuln was in the drivers for a usb Bluetooth dongle, so there is
apparently _some_ coverage.

------
aspenmayer
None of this is directed at OP.

Not to be _that guy_ , but I posted this many hours ago.[1] I don't care about
the karma, but this is a repost.

@dang, can anything be done to help HN not work like this in the future? Why
have karma for posts but then allow reposts like this? It disincentivises
first posts in favor of gaming the viewers of HN while trying not to get
scooped. It sucks. None of this is directed at OP.

[1]
[https://news.ycombinator.com/item?id=23329790](https://news.ycombinator.com/item?id=23329790)

~~~
kick
He's expressed interest in the past about fixing this; he's not sure how to
handle it yet:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20karma%20shar&sort=byDate&type=comment)

That said, two things:

You should send a message to hn@ycombinator.com if you have something to say
to moderation. They're very responsive, and you'll get a better response rate
than posting in random HN threads that might not even be seen. It also breaks
the Guidelines:

 _Please don 't post on HN to ask or tell us something. Send it to
hn@ycombinator.com._

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

You also shouldn't take this personally. The poster likely didn't see your
post, _very_ likely wasn't 'gaming' anything (they actually have some really
interesting articles in their submission history that don't seem to have been
posted before, and they're a journalist; it was likely they just read it and
posted it), and it wouldn't be practical to 'ban reposts': HN already has a
feature that upvotes a previous submission if you post within a given range
from it.

I know it's not a great feeling to post something that you think is
interesting and to see it get to the front page later via someone else (I can
point to a bunch of my own posts where this happened), but it getting to the
front page at all is something positive. It's not a race, so incentivizing
quick-draw on articles from popular outlets (like zdnet, which has millions of
readers) above all else probably wouldn't be useful, either.

~~~
aspenmayer
I don’t care to do that. It’s a problem with basic functionality. There is
site behavior which disallows reposts, but only sometimes. The sometimes part
is the bug, from my point of view. I honestly don’t care enough to do anything
but say it shouldn’t happen when it happens to me, as long as it happens to
me. Bug reports should be public for non-security related bugs.

This is a bug. This thread is my report. I can be reached on this thread.

Edit: I have emailed and asked that replies are in-thread or linked to in this
thread. I hope we can get some clarity into whether this is a "won't fix"
situation or more of a subjective call on a per-case basis, or something else
entirely.

I don't want to make waves, just trying to surf.

~~~
dang
Take a look at the past explanations at
[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20reposts%20good&sort=byDate&type=comment)
and if you still have a question I haven't answered there, let me know what it
is. Examples:

[https://news.ycombinator.com/item?id=22042481](https://news.ycombinator.com/item?id=22042481)

[https://news.ycombinator.com/item?id=21457217](https://news.ycombinator.com/item?id=21457217)

[https://news.ycombinator.com/item?id=20206120](https://news.ycombinator.com/item?id=20206120)

[https://news.ycombinator.com/item?id=18156460](https://news.ycombinator.com/item?id=18156460)

[https://hn.algolia.com/?query=by:dang%20reposts%20mitigate&s...](https://hn.algolia.com/?query=by:dang%20reposts%20mitigate&sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0)

[https://hn.algolia.com/?query=by:dang%20reposts%20cracks&sor...](https://hn.algolia.com/?query=by:dang%20reposts%20cracks&sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0)

~~~
aspenmayer
I do have one unanswered question: Why did this particular repost get posted
instead of upvoting my post?

~~~
dang
Because your post fell below the bar for 'significant attention' as explained
in the comments I linked to.

~~~
aspenmayer
Maybe if I had gotten some of the karma from the repost it would have cleared
the bar. This argument is circular, and I know you have to make a judgment
call, but this feels like the wrong way to go about a fair, transparent
system. Perhaps that is not a goal of HN, but from my few interactions with
you on this site, I think you probably care a whole lot more about HN than I
do, and I care too! Thanks for all you do.

Edit:

Why not do it like a lottery with more than one winning ticket sold? Share the
karma pool among the OP and the reposters. Just an idea.

Or, let the reposter keep the karma, but put a byline saying something like
'first posted by user123 on jan 2, 1969' with a link? I care far more about
attribution than karma. I care about making good posts, but if someone else
gets the credit, why would I bother? If no one will see it, the intrinsic
value to me is something I already had. To share is to be seen. If a tree
falls in the forest with no one around to hear it and all that.

~~~
dang
Yes, we're planning to implement some form of karma sharing. That information
was in kick's reply to you upthread
([https://news.ycombinator.com/item?id=23342187](https://news.ycombinator.com/item?id=23342187)
\- see the first link there).

The reason for wanting to do that is incentivize finding good stories that
haven't been posted yet:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20karma%20incentiv&sort=byDate&type=comment)

~~~
aspenmayer
This is the first time I’ve heard the words “karma sharing” from a
representative of HN. I didn’t mean to miss what ‘kick was getting at, but I’m
glad for the discussion. I also apologize if I came off as aggressive. I am
working to be a better person online and offline, and I appreciate the
dialogue. I also feel that this thread is a good thing for clarity around
these issues on the site. I wish my phrasing and attitude came off better, but
we are what we do, and so I’ll try to do better.

