MoR!Harry's opposition to killing has always been more of a philosophical objection than an instinctual one, foreshadowed heavily back in chapters 7, 10, and 16. Given the effects of Voldemort's alterations to his brain during youth, depending on your idea of identity this not the typical situation of confronting the psychological cost of taking life.

Ironically, non-lethal transfiguration was probably available, even if Harry wouldn't or couldn't think of it -- there's no restriction to, say, converting people's blood into propofol or methohexital, for example. That'd be unhealthy even beyond the normal health risks of human transfiguration, but in exchange for its risk of breathing issues and transmutation-related blood-clot-in-brain effects, comes with the benefit of exceptionally fast activity, and the volume required is well within the constraints of the problem. While the Deatheaters are more complicated a problem despite Voldemort calling them useless, there are a handful of other possible solutions that would be less likely immediately lethal. The only person Harry /had/ to maim was Voldemort, and that's because direct transfiguration would have alerted him.

Given that Harry almost certainly killed Sirius, and probably killed Lucius, and we have a number of chapters left, this may well end up being a narrative complication and a flaw, even if an understandable one.

It's not been explicitly confirmed, but given the similarity in forms to later notes signed Santa (and confirmed to be Dumbledore), the note's writer claiming the Cloak was freely given by Harry's father, and the explicit warning against letting Dumbledore see the Cloak, it's very likely that Dumbledore gave Harry the Cloak as in canon.

Dumbledore gave Harry a pack of cards that had portkey functionality, under the name Santa Claus and claiming that they were a portkey to Salem, but instead heading to a location somewhere in London. Harry gave them back for further investigation, thinking that they might be a trap, Dumbledore took them back but didn't activate the portkey.

It's possible that this was just a short reference, meant to establish Dumbledore's steps of trust in parallel to the gift of the Cloak of Invisibility, and that Harry did not retrieve the portkey and Dumbledore did not place it upon Harry's person...

But activation trigger was to rip the King of Hearts -- a king card known for its face character stabbing itself in the back of the head -- in half.

So there is no defense against Obliviation that Voldemort could have prepared for himself?

With perfect sight toward the future, perhaps he could have. It's far from convincing that it would have actually helped, without blocking thirty other vulnerabilities.

Obliviation's particularly interesting because it requires no upkeep, but it's far from the only thing that would bypass Horcruxes. Voldemort's just as vulnerable to being repeatedly stunned, to petrification (hence the murder of the basilisk), to transfiguration, to the Imperius, to pretty much any mind-affecting charm. The biggest defense is, well, the same as anyone else's defense to the Killing Curse -- don't be there. Creating a defense specifically against large-scale Obliviation isn't very valuable if the attacker has countless further options to permanently disable anyone so defenseless as to be vulnerable to an Obliviate.

Before Harry shot at him, Voldemort was cursed to be unable to threaten Harry's immortality, and given the several times he's found himself getting wrong answers to questions previously, I don't think he was certain Harry would have betrayed him even with such a convenient que. So that covers anything that happens before Harry fires the gun.

After that point... I think he's trying to cover his bases. That he set up such a ploy to enable him to kill Harry means that he's likely at least going to try. But that's not the only Winning move, and it's a Winning move that prevents other Winning moves from being attempted.

"There are plots that must succeed, where you keep the core idea as simple as possible and take every precaution." "All thiss, all I have done, iss to ssmassh that desstiny at every point of intervention."

This is one of those plots. "Keep Harry Potter from destroying universe" does not allow duct tape, WD-40, and lesser wishes to attempt a do-over. Killing Harry is probably the most effective way to keep that from happening, if you can do it. The last time Vold tried to subvert or redirect a Prophecy by destroying most of a person involved, things went so badly he spent most of a decade as a howling disembodied spirit. It's not been explicitly stated that Prophecies act like Time Turners (aka DO NOT MESS WITH TIME/NO), but it's pretty strongly implied to result in something like Mage's Paradox or Continuum's Frag. Resurrecting Hermoine and giving aid to Harry Potter was something that had to be done before any Death Eaters were summoned and arrived, and was about the only such thing, and was disjoint enough from people directly related to the Prophecy as to be unlikely to result in Paradox/Frag.

Vold knows Harry's best friend as a pillar of restrictions. Even if we know her to be a threat to his plans, Vold knows that her death triggered Harry's transformation into The One Who Tears Stars and that this is more dangerous than even an immortal Hermoine.

((I think he forgot some of the matters he said earlier, though. The Parsletongue curse will probably strike soon since he promised neither he nor his would seek to ever harm Hermoine. I'm genuinely surprised that cutting curse here didn't already cause something horrible to happen to him.))

What is your threat model?

An attacker creates a large number of nodes and overwhelms any signal in the initial system.

For the specific example of a reddit-based forum, it's trivial for an attacker to make up a sizable proportion of assigned reputation points through the use of sockpuppets. It is only moderately difficult for an attacker to automate the time-consuming portions of this process.

I also don't think there's a good solution to sockpuppetry short of mandatory biometrics.

10% of the problem is hard. That does not explain the small amount of work done on the other 90%. The vast majority of sockpuppets aren't that complicated: most don't use VPNs or anonymizers, most don't use large stylistic variation, and many even use the same browser from one persona to the next. It's also common for a sockpuppets to have certain network attributes in common with their original persona. Full authorship analysis has both structural (primarily training bias) and pragmatic (CPU time) limitations that would make it unfeasible for large forums...

But there are a number of fairly simple steps to fight sockpuppets that computers handle better than humans, and yet still require often-unpleasant manual work to check.

Why not? The trade-off is in the details of how much reputation matters. There is a large space between reputation being just a number that's not used anywhere and reputation determining what, how, and when can you post.

Yes, but there aren't open-source systems that exist and have documentation which do these things beyond the most basic level. At most, there are simple reputation systems where a small amount has an impact on site functionality, such as this site. But Reddit's codebase does not allow upvotes to be limited or weighed based on the age of account, does not have , and would require pretty significant work to change any of these attributes. (The main site at least acts against some of the more overt mass-downvoting by acting against downvotes applied to the profile page, but this doesn't seem present here?)

Not if you can trivially easy block/ignore them which is the case for Twitter and FB.

If a large enough percentage of outside user content is "bad", users begin to treat that space as advertising and ignore it. Many forums also don't make it easy to block users (see : here), and almost none handle blocking even the most overt of sockpuppets well.

What's wrong with a username/password combo (besides all the usual things) or, if you want to get a bit more sophisticated, with having the user generate a private key for himself?

In addition to the usual problems, which are pretty serious to start with, you're relying on the client. To borrow from information security, the client is in the hands of the enemy. Sockpuppet (sybil in trust networks) attacks, where entity pretends to be many different users (aka sockpuppets), and impersonation attacks, where a user pretends to be someone they are not, are both well-documented and exceptionally common. Every forum package I can find relies on social taboos or simply ignoring the problem, followed by direct human administrator intervention, and most don't even make administrator intervention easy.

There are also very few sites that have integrated support for private-key-like technologies, and most forum packages are not readily compatible with even all password managers.

This isn't a problem that can be perfectly solved, true. But right now it's not even got bandaids.

Once again, with feeling :-D -- to which purpose? Generally speaking, if you run a forum all you need is a way to filter out idiots and trolls. Your regular users will figure out reputation on their own and their conclusions will be all different.

"Normal" social reputation runs into pretty significant issues as soon as your group size exceeds even fairly small groups -- I can imagine folk who could handle a couple thousand names, but it's common for a site to have orders of magnitude more users. These systems can provide useful tools for noticing and handling matters that are much more evident in pure data than in "expert judgments". But these are relatively minor benefits.

At a deeper level, a well-formed reputation system should encourage 'good' posting (posting that matches the expressed desires of the forum community) and discourage 'bad' posts (posting that goes against the expressed desires of the forum community), as well as reduce incentives toward me-too or this-is-wrong-stop responses.

This isn't without trade-offs : you'll implicitly make the forum's culture drift more slowly, and encourage surviving dissenters to be contrarians for whom the reputation system doesn't matter. But the existing reputation systems don't let you make that trade-off, and instead you have to decide whether to use a far more naive system that is very vulnerable to attack.

You can build an automated system to suit your fancy, but there's no guarantee (and, actually, a pretty solid bet) that it won't suit other people well.

To some extent -- spell-check and capitalization expectations for a writing community will be different than that of a video game or chemistry forum, help forums will expect shorter-lifespan users than the median community -- but a sizable number of these aspects are common to nearly all communities.

Why would Twitter or FB bother assigning reputation to users? They want to filter out bad actors and maximize their eyeballs and their revenue which generally means keeping users sufficiently happy and well-measured.

They have incentives toward keeping users. "Bad" posters are tautologically a disincentive for most users (exceptions: some folk do show revealed preferences for hearing from terrible people).

what is it that you authenticate? Do you mean trust in the same sense as "web of trust" in PGP-type crypto systems?

For starters, a system to be sure that a user or service is the same user or service it was previously. Web of trusts /or/ a central authority would work, but honestly we run into limits even before the gap between electronic worlds and meatspace. PGP would be nice, but PGP itself is closed-source, and neither PGP nor OpenPGP/GPG are user-accessible enough to even survive in the e-mail sphere they were originally intended to operate. SSL allows for server authentication (ignoring the technical issues), but isn't great for user authentication.

I'm not aware of any generalized implementation for other use, and the closest precursors (keychain management in Murmur/Mumble server control?) are both limited and intended to be application-specific. But at the same time, I recognize that I don't follow the security or open-source worlds as much as I should.

For reputation as an assessment of user ratings, you can obviously build a bunch of various metrics, but the real question is which one is the best. And that question implies another one: Best for what?

Oh, yeah. It's not an easy problem to solve Right.

I'm more interested in if anyone's trying to solve it. I can see a lot of issues with a user-based reputation even in addition to the obvious limitation and tradeoffs that fubarobfusco provides -- a visible metric is more prone to being gamed but obscuring the metric reduces its utility as a feedback for 'good' posting, value drift without a defined root versus possible closure without, so on.

What surprises me is that there are so few attempts to improve the system beyond the basics. IP.Board, vBulletin, and phpBoard plugins are usually pretty similar -- the best I've seen merely lets you disable them on a per-subfora basis rather than globally, and they otherwise use a single point score. Reddit uses the same Karma system whether you're answering a complex scientific question or making a bad joke. LessWrong improves on that only by allowing users to see how contentious a comment's scoring. Discourse uses count of posts and tags, almost embarrassingly minimalistic. I've seen a few systems that make moderator and admin 'likes' count for more. I think that's about the fanciest.

I don't expect them to have an implementation that matches my desires, but I'm really surprised that there's no attempts to run multi-dimensional reputation systems, to weigh votes by length of post or age of poster, spellcheck or capitalizations thresholds. These might even be /bad/ decisions, but usually you see someone making them.

I expect Twitter or FaceBook have something complex underneath the hood, but if they do, they're not talking about the specifics and not doing a very good job. Maybe its their dominance in the social development community, but I dunno.

Commenting to 'save' this comment. That's a really clever way to handle that.