h a l f b a k e r yI like this idea, only I think it should be run by the government.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Registering for an account with every random website is a pain, particularly when all you want to do is post a comment and move on, possibly never to return.
What is the advantage of registration to users? Well, one plus is that it allows regular users to be identified; it prevents the malicious from
pretending to be someone else.
Which is actually quite an advantage, even for users who may only post once. But... registering is a pain, and is likely to deter many comments. It may also incur extra legal duties on the website owner.
I propose a system by which users can be 'anonymously identifiable'. This is a system not of identity, but hidden identity or 'hidentity'.
How does it work?
The (comment) author enters a user-name, and also a password. The website generates a hash of the password plus username, and uses that to generate a memorable string. This is pretty straightforward to do using lists of adjectives and nouns, for example of the form "Bavarian beaver cheese"[1], "Mexican insanity pepper"[2] and "dwarven combat muffin"[3][4]
This memorable string is tagged on to the comment header.
Why not just use the hash? Because no-one would notice if a random hexadecimal next to a name changed.
Registration is never required, and no personally identifying information need ever be held by the website server.
Then when someone tries to spoof another, they can't match the hash-name, at least, probably not at their first attempt, and so are easily spotted.
And as a fringe benefit, there can be multiple users with the same username. Why be "Kat123" when you can be "Kat : munificent spotted apple"
[1] In-joke
[2] In-joke
[3] In-joke
[4] The reason my examples all have three words is because n^3 gets big enough for fairly small n, and is about right in terms of memorability.
Also I think it's optimally funny.
Tripcode
http://en.wikipedia.org/wiki/Tripcode
[derefr, May 02 2010]
The system in action
http://lysisgames.c...10/commentbeta.html
(beta test - please post something) [Loris, May 04 2010]
Reminded me of this
http://xkcd.com/936/
[4whom, May 02 2012]
ooooh, Monro(e) made one
http://preshing.com...-password-generator
not the same thing, but sounds good when you say them out loud. [4whom, May 02 2012]
(?) steggi....
http://www.steggi.jp/try1.php
[not_morrison_rm, May 02 2012]
SQRL
https://www.grc.com/sqrl/sqrl.htm
as mentioned in my annotation [notexactly, Jun 15 2015]
Identicon
https://en.wikipedia.org/wiki/Identicon
as mentioned in my annotation [notexactly, Jun 15 2015]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I'm working on baking this, for my game website. I'd greatly appreciate it if anyone would help me beta-test the system. (link) |
|
| |
Further to the text string, the hidentity can potentially include further memorable information. Relatively easy things to do include giving comments different background colours and borders. |
|
| |
Isn't this a custom tripcode? [bun] for funny (and memorable) custom tripcodes, then. |
|
| |
There was an XKCD comic on this I think, will try and find. |
|
| |
hmm... or you could wait until the thread goes unposted to for <time> before allowing a username to be reused... but I like this better (generated hex string). [+] |
|
| |
Well, it works. The problem is that my blog doesn't get many comments. |
|
| |
Your sample is too small, your standard deviations are too high, and you should be ashamed...:-). Played Silver Lining (while I was visiting) BTW, loved it! |
|
| |
Just please explain to me how this is different from custom tripcodes? |
|
| |
Well, tripcodes are similar. I didn't initially know about them when I posted the idea.
My understanding is that standard tripcodes are effectively a one-way hash of a password, so generally look like random data. Custom tripcodes are similar, except that they contain a small fraction of user-defined text somewhere in the string. |
|
| |
Custom tripcodes need to be generated by brute-force searching, whereas mine are memorable (albeit 'randomly' assigned) for free, and don't have any line noise.
For my implementation in particular one difference is that a custom tripcode will necessarily involve a complex password, whereas I've gone out of my way to emphasise simplistic passwords (since I don't want anyone reusing their secure passwords). Plus my comments are pretty colours. |
|
| |
Basically it's the difference in emphasis between a community site with committed users (who will take the time and effort to add value to their representation on the site), and a blog, which wants to receive comments from casual passers-by. |
|
| |
//Plus my comments are pretty colours.// Well there you have it! |
|
| |
//it prevents the malicious from pretending to be someone else. |
|
| |
As someone, who might, or might not be pretending not to myself does this include me? |
|
| |
Anyway, I seem to thinking of something, almost, but not quite similar..see link to steggi |
|
| |
PS not totally bug-fixed, you have to pick 5 or more words. |
|
| |
// Registering for an account with every random
website is a pain, particularly when all you want to do
is post a comment and move on, possibly never to
return. // |
|
| |
SQRL (linked) solves this and much more. It doesn't
on its own make anonymous commenters
unimpersonatable, but it would be easy to interface it
with a system such as yours or Identicon (linked) to
do so, while replacing the username and password
entirely (and thereby removing the need for the user
to make up and remember those, and removing the
ability of someone else to guess them, however
unlikely that may be). |
|
| |
SQRL is interesting, but there's a bit of a chicken and egg situation before it's established as a common authentication system. If I don't want to register somewhere, I'm unlikely to to install client-side software to avoid it.
From a developer's perspective there's also the issue that the authentication might be an external point of failure. I'm not sure whether this is true, because I've not fully understood the protocol.
Regardless of this, I fear SQRL might have missed the boat, because most people don't seem to care about anonymity and use facebook login. |
|
| |