Any particular reason you want to get decibans involved in all this? They just seem to add massive confusion (e.g. : bans are just bits in different log base, as such they are a measure of information. I look at the table and see negative values -- does this mean I lost information somehow? I know what you mean, but many people reading your draft won't.)
I'd just stick to % confidence which is reasonably clear and intuitive and not touch either decibans or odds ratios. Given that you expect humans to come up with these confidence estimates, I'd just offer a choice of integers from 1 to 100.
At least one small part of my motivation for this choice is to encourage Bayesian-style reasoning among a larger group of people, thus promoting rationality in general. :)
An option I've thought of, off or on, is that in addition to decibans, a value could be entered for CONFIDENCE with a '%' on the end, allowing for the clear-and-intuitive description you describe. (Eg, either 'CONFIDENCE=20' or 'CONFIDENCE=99%'.) However, adding such an option adds further complexity, which is the opposite of what the solution is supposed to do, so I haven't so far.
(Also, even if percentages were allowed, I wouldn't want to limit the user to 99% and 100% with nothing in between - that would prevent most of benefits the web-of-trust system described.)
I do fully accept your point that I need to be somewhat clearer about negative deciban values, at the very least.
is to encourage Bayesian-style reasoning among a larger group of people
Frankly, a look at that table of decibans and odds ratios will serve as an effective deterrent from considering Bayesian approaches...
If you want people to learn to like oatmeal don't start by serving haggis :-/
I am also not quite sure how does your proposal for the web-of-trust system is supposed to work. Normally the web of trust verifies the link between a public key and an identity. But you seem to want to use the web of trust to pass an opinion on content of fields..? So, for example, your friends can cryptographically sign their assent that you were born in town X? I don't see much use for that but then I'm not sure I see the big picture. Can you explain it? What do you want to achieve and which problems do you want to fix?
If you want people to learn to like oatmeal don't start by serving haggis :-/
True. Unfortunately, I haven't yet come up with a more palatable presentation - which is why I'm posting here.
Can you explain it?
At present, most web-of-trust systems are all-or-nothing; either a public key is trusted as belonging to a particular identity, or not. PGP adds a 'partially trusted' level, but it's not much improvement. This leads to the current hierarchical certificate-authority system, where the root certificates are trusted absolutely, and from those roots, the certs they sign are trusted, and then the certs those ones sign, and so on. Unfortunately, experience has demonstrated the fragility of this system, with root certs suborned by malicious groups in order to spy on theoretically encrypted traffic.
An alternate approach is to use a more Bayesian approach - instead of a binary 0 or 1, belief-levels of 0.5, 0.9995, and everything else in between. So, using the CONFIDENCE field, person A can say they're 90% sure that b@c.d belongs to Person B, and if person B says they're 90% sure that key X belongs to person C, and so on. No root authority needed - so suborning a 'root' authority will cause much less trouble. (Once I get this format established, I plan on adapting a protocol called 'webfist' to implement the whole distributed mesh-network web-of-trust thing.)
The CONFIDENCE field can be used for other things, such as a genealogist saying they're only partly-sure about someone's birthday, but that's mostly a pleasant bonus.
At present, most web-of-trust systems are all-or-nothing ... the root certificates are trusted absolutely
Well, kinda. I think somebody (OpenPGP, maybe?) did something like vote (=cert) counting. And, of course, unless you're in a forced situation (such as a browser SSL/TLS connection to your bank) you can choose which CAs you want to trust.
instead of a binary 0 or 1, belief-levels of 0.5, 0.9995, and everything else in between
I am not so sure this is an improvement. First, the users will have to deal with additional complexity. Second, this can be gamed or misused -- I'm sure some entities will just sign all certs with the highest value possible in the CONFIDENCE field. Third, for people without common friends you'll still need some kind of "central"/trusted CAs and suborning their root certs is still going to be quite valuable.
You are assuming people will spend time and mental energy trying to form rational judgments of trust and commit them as CONFIDENCE percentages. I suspect the system has a good chance of quickly devolving into a binary state: either MAX_VALUE or anything else.
And let's be frank about the current situation: the original PGP idea of the web of trust as a "distributed mesh-network" kinda thing did fail. Instead we got highly centralized systems of root CAs which, evidently, everyone finds highly convenient. Given that we have a demonstrated unwillingness on part of the users to think about which certs they are willing to accept and which not to accept, why do you think a similar system with *more* complexity is going to succeed?
the users will have to
An interesting thing about the file-format I'm fiddling with is that it's both human-readable and -writable, and machine-readable and -writable. The existing format already has 95% of what's needed for the web-of-trust system, so it turns out to be easier just to improve what's already there instead of coming up with everything from scratch.
why do you think a similar system with more complexity is going to succeed?
Because it can be automated. I don't have to remember the AT commands for my 2400-baud dial-up modem - these days, the connection stuff Just Works.
I noticed that the fragility of root certificates was a problem with potentially large effects. (See Cory Doctorow's essay, The Coming War on General Purpose Computation .) I've come up with a way which, with some work, might be able to ameliorate some aspects of said problem. I'm doing the work. Maybe I'll fail. Maybe I'll succeed. I figure the odds of success are high enough that it's worth the effort.
Or, put another way - taking the time and effort to collect votes from millions of individuals is more complex than just checking for the guy in charge's firstborn. But decentralized planning offers substantial benefits over authoritarian command structures, so the time and effort is worth it. (It's also worth minimizing said time and effort, but to do so, a more complicated version of the system may initially be required in order to have actual data on how to accomplish that minimization without losing the benefits of the decentralization.)
Because it can be automated.
How will determining and assigning confidence be automated?
taking the time and effort to collect votes from millions of individuals
You are going to accept confidence values from unknowns..? What makes you think that vote is going to come from an individual and not from a bot (and it's going to be quite easy to write a script which will generate bots at a very impressive rate -- and, of course, they all can vouch for each other).
I do like decentralized systems. And I given the Snowden revelations I am pretty sure the Three Letter Agencies have private keys of root certs. But I really don't think anyone but a handful of cryptogeeks cares enough to put effort into a decentralized mesh system.
Sorry for being a cynic.
How will determining and assigning confidence be automated?
Wups, sorry; I missed answering that question by mistake.
The simple answer is to drop the phrase 'Bayesian analysis', the same as is used for spam-detection. But that's not a real answer; in fact, I don't yet have a complete answer - I'm still focusing on getting the vCard format right. I'm currently thinking along the lines of using one's social network (eg, Facebook and Twitter friends) as an initial set of seeds, with high levels of confidence, perhaps supplemented by something equivalent to key-signing parties; and from that initial set of high-CONFIDENCE connections, pull a Keven Bacon style expansion of friends-of-friends-of-friends, with each step in the chain applying Bayesian-based math to figure out the appropriate level of confidence based on the values applied by everyone else to their own various connections.
That's a bit in the future, though; I'm still just barely getting started on the outlines of adapting webfist to use identifiers other than DKIM-confirmed email addresses, let alone working out everything in the previous paragraph.
Sorry for being a cynic.
No worries. You've got your areas of expertise and your own things to work on - and this is where I think my time can be spent with the maximal expected positive outcome.
What makes you think that vote is going to come from an individual and not from a bot
I was using democracy vs monarchy more as a general example. :) But for this question - how is it remotely possible that Wikipedia is at least as good as the Brittanica? Yes, there are flaws and failure modes and trolls - but the overall mass of people of good will can, with the right infrastructure in place, work together to outweigh the few bad apples. I believe that infrastructure is vastly under-rated in its effects, and given how few people I can find actually working on infrastructure-level solutions to distributed identity assertion, even my relatively unskilled cryptogeek self has an opportunity to leverage something useful here.
And even if the whole thing crashes and burns, then I'll still have learned a good deal about building such infrastructure for my /next/ attempt. I'll consider it a net win even if I only get as far as getting my name on an RFC - that'll give me some cred to build on for such future attempts.
Yes, there are flaws and failure modes and trolls
That's not what I had in mind. I had in mind deliberate attacks on the system by malicious and highly skilled people.
Do a threat analysis -- see how your proposed systems holds up under attack from various entities (e.g. (a) script kiddies; (b) a competent black hat; (c) a bunch of competent black hats controlling large botnets; (d) government).
That's part of why I haven't gotten very far in fiddling with webfist. I may, in fact, may have to use something else as the basis of the key-exchange protocol - but, like vCard, it already does most of what I want to do, so I'm hoping I can save some time and effort by adapting the existing method instead of starting from scratch.
Looking at what I'm currently doing with vCard from that point of view, it's already possible to publish a PGP key publicly - see the various keyservers. And if a user wants to use that method, they can have their signed vCard point to it. Signed vCards simply allow for a few more options for key-publication, key-signing, and key-revocation. There doesn't seem to be any new attack-vectors outside of the ones that already exist; so the main security work is going to be hammering out the key-exchange and -verification protocols. Heck, for that, I could probably even get away with just sending signed-and-encrypted blobs with UUCP or Tor or bluetooth or QR codes, if I set my mind to it. (Traffic analysis of that last one would be something of a pain, requiring analysis of, you know, actual traffic. :) )
In short, I'm not locked into a doomed security model just yet. And as I'm writing this proto-RFC, I'm working on making contacts with enough crypto-type people to have a shot at avoiding building a security system good enough that /I/ can't break it. (Feel free to point some crypto-geeks or security experts in my direction, if you know any.)
I might argue that that's not what "Beyond reasonable doubt" means, but more concretely: Shouldn't 1:1 be 0 bits?
Maybe I'm misunderstanding what the bits map to here.
As for 'beyond a reasonable doubt', a couple of years ago I found a study had been done of court cases, and in general, this standard of proof seems to be met when people are 75% confident. That is, on average, if a jury thinks there's at least a 25% chance someone is innocent, they don't convict.
This is depressing. So assuming that juries accurately estimate the probability of guilt, up to a quarter of convicts could be innocent? I'm quite sure that's not what was intended by the original writers of the phrase.
societal evolution towards an optimal justice system
I don't see anything significant that would push society towards an optimal justice system, and the justice system does not seem as optimal as it would be if there was such a force.
Why do you think society is evolving towards an optimal justice system?
Perhaps I should have said 'local-optimal', and it was more of a retro-diction about societal evolution than a prediction about future justice systems. (Although such a prediction could still be made on this line of reasoning.)
If it's possible to convict and imprison a person on too little evidence - say, the sworn testimony of a single person - then there will be a significant number of innocent people who end up in prison, which removes them from the pool of productive workers, which reduces the overall economy of the society, which reduces the ability of that economy to support its military, which reduces the odds that that society can defend itself in wars, which increases the odds that that society will be replaced, by force, by a different society.
If it a conviction requires more evidence than is 'optimal', then a larger number of criminals will remain in society performing criminal acts, which reduces the overall economy, with similar overall effects.
As mentioned in the article I linked to, by having conviction set at 'probable cause', which in practice works out to 75% certainty; then Laplace's Sunrise Formula implies that such a conviction implies that there was at least 50% confidence that the convict would perform a criminal act in the future - and, thus, convicting at such a level of confidence could be considered 'optimal' for preventing future criminal acts, thus maximizing the economy, thus maximizing the odds that that society will be able to defend itself and continue existing.
The surface reasoning for how a justice system works may not have much to do with why that system continues to exist, any more than kissing being 'romantic' has much to do with why people started kissing at all.
You're saying that it evolves towards a local optimum because the nations that do it badly fall?
I think No Evolutions for Corporations or Nanodevices applies here.
From what I understand, the study you're referencing says that a given juror must be on average 25% certain of innocence for a defendant to not be declared guilty. However, them going to jail requires that the entire jury agree that they're guilty. Some of the jurors will need higher certainty, and there will be variations in how they interpret the evidence. As such, it sounds like someone would actually need a lot more evidence to be declared guilty.
They can be tried repeatedly until they get all guilty or all innocent, but I don't think that actually happens much. The courts are overtaxed as it is.
For one - IIRC, the 25% figure was based on the jury as a whole, rather than individual jurors.
And for another - I would actually be more surprised if my 'evolution of society' reasoning turned out to be true, then if I were mistaken. It's mainly an attempted backfill to try to figure out just how the jury system would end up using 'beyond a reasonable doubt' and resulting in getting as close as possible to convicting 'people who are more likely than not to break the law in the future'.
(I can't seem to find the study in question with some quick Googling. I have a memory that the 75% certainty figure was for low-level crimes, such as theft, and that when the sentence was higher, such as for capital crimes, then juries tend to need to have a higher level of confidence before they'll issue a guilty verdict; but that might have been a different study.)
That's a misleading way to put it. If they're right 75% of the time, they'll think their probability of being right is over 90%. Trying to convince people that it's 75% in practice will make them uncomfortable, so it might be better to choose examples where the outcomes aren't important.
1:1 is 50%. If I'm 50% certain of something, then finding out whether or not it's true would give me one bit of information. 0 bits is no information. That would be finding out something you were 100% certain of, with 1:0 odds.
I wrote the chart some time ago, so I don't have the reference handy anymore; but IIRC, the translation was that a 15/16 (93.75%) probability corresponded to 4 bits of information; a 7/8 (87.5%) probability to 3 bits; 3/4 (75%) to 2 bits; and 1/2 (50%) to 1 bit.
I notice that you start with numerical examples, go on with the table. Shouldn't the description star with something like "a deciban is 10 times the base 10 log of the odds"? As far as I can see, it nowhere says what decibans are.
I'm in the process of writing up an Internet Draft for a file-format, part of which involves assigning logarithmic confidence values measured in decibans. There's still a good ways to go before it'll be in good enough shape to even have a chance at being considered for an RFC; part of that is describing "decibans", and how to use them, to people who've never heard of the things before. I'd like to get a good introductory text for that nailed down before submitting the next revision; and since LW is where I first learned of decibans, I'd like to evoke as much constructive criticism as I can get here.
Here's my current draft of the text to replace the relevant section of the current revision:
3.1. Parameter: CONFIDENCE
Namespace:
Parameter name: CONFIDENCE
Purpose: To specify the confidence of the authority that the
information of the given parameter is accurate, measured in decibans.
Value type: A single number, usually an integer.
Description:
A CONFIDENCE value of 0 decibans indicates odds of 1:1 (ie, 50%) that
the information is correct. A change of 10 decibans changes the odds by
a factor of 10; 10 decibans means 1:10 odds (~90%), 100 decibans 1:100
odds (~99%), -10 decibans 10:1 odds against (~10%). A change of 1
deciban is roughly equivalent to changing the odds by a factor of 5:4.
Here is a table covering enough integer deciban values to allow for
easy reference.
Decibans / Level of belief / Rough Odds / notes
-127 / 0.00000000002% / 1:5 trillion
-30 / 0.1% / 1:1,000
-20 / 1.0% / 1:100
-10 / 9.9% / 1:10
-9 / 11.2% / 1:8
-8 / 13.7% / 1:6
-7 / 16.7% / 1:5
-6 / 20.0% / 1:4
-5 / 24.0% / 1:3
-4 / 28.5% / 2:5 / a reasonable doubt
-3 / 33.3% / 1:2
-2 / 38.7% / 2:3 / probable cause
-1 / 44.3% / 4:5
0 / 50.0% / 1:1 / neither belief nor disbelief; agnosticism, 1 bit
1 / 55.7% / 5:4, 1.25:1 / preponderance of the evidence
2 / 61.3% / 3:2, 1.5:1
3 / 66.6% / 2:1 / clear and convincing evidence
4 / 71.5% / 5:2, 2.5:1
5 / 76.0% / 3:1 / beyond a reasonable doubt, 1 standard deviation, 2 bits
6 / 80.0% / 4:1
7 / 83.3% / 5:1
8 / 86.3% / 6:1
9 / 88.8% / 8:1 / 3 bits
10 / 90.9% / 10:1 / one nine
11 / 92.6% / 25:2, 12.5:1
12 / 92.5% / 15:1 / 4 bits
13 / 95.2% / 20:1 / lone studies with p=0.05, 2 standard deviations
14 / 96.2% / 25:1
15 / 96.8% / 30:1 / 5 bits
16 / 97.6% / 40:1
17 / 98.0% / 50:1
18 / 98.4% / 60:1 / 6 bits
19 / 98.8% / 80:1
20 / 99.0% / 100:1 / two nines, lone studies with p=0.01
21 / 99.26% / 125:1 / 7 bits
24 / 99.62% / 250:1 / 8 bits
26 / 99.7% / 400:1 / confirmed studies with p=0.05, 3 standard deviations
27 / 99.80% / 500:1 / 9 bits
30 / 99.9% / 1,000:1 / three nines, 10 bits
40 / 99.99% / 10,000:1 / four nines, confirmed studies with p=0.01
42 / 99.993% / 16,000:1 / 4 standard deviations, 14 bits
45 / 99.9968% / 30,000:1 / 15 bits
50 / 99.999% / 100,000:1 / five nines
60 / 99.9999% / 1 million:1 / six nines, 20 bits
62 / 99.99994% / 1.5 million:1 / 5 standard deviations
70 / 99.99999% / 10 million:1 / seven nines
80 / 99.999999% / 100 million:1 / eight nines
87 / 99.9999998% / 500 million:1 / 6 standard deviations, 29 bits
90 / 99.9999999% / 1 billion:1 / nine nines, 30 bits
99 / 99.99999998% / 8 billion:1 / 33 bits
100 / 99.99999999% / 10 billion:1 / ten nines
110 / 99.999999999% / 100 billion:1 / eleven nines
116 / 99.9999999997% / 400 billion:1 / 7 standard deviations
120 / 99.9999999999% / 1 trillion:1 / twelve nines, 40 bits
127 / 99.99999999998% / 5 trillion:1
Given human factors, it is rare for hand-typed data to be able to have
a CONFIDENCE that every single bit is accurate of more than 50
decibans. Without getting into the details of recursion, and given that
at least one out of roughly ten billion people is thoroughly
disconnected from reality, it's very difficult for a human to have more
than 100 decibans of confidence in anything, even that H2O is a useful
description of water or that the subjective reality they are
experiencing is connected to the same subjective reality experienced by
other humans.
If a user wishes to manually generate signed vCards, but does not have
much experience with mathematics, then one option to get rough
estimates of what CONFIDENCE values are appropriate could be to use
Laplace's Sunrise Formula, also known as the Rule of Succession. This
takes two pieces of input: the number of times in which something might
have gone one way or the other; and the number of times it went one
way. For example, it might be used with the number of times an email
has been received from a particular address, and the number of times
that email has been from the owner of that address instead of viral
spam. The formula produces an estimate of the odds that future trials
will go the same way, by calculating:
FutureProbability = (Successes + 1) / (TotalTrials + 2)
For the example, if one has received 1,000 emails from an address, out
of which 1 was spam, then the formula says that the future probability
will be on the order of (999+1) / (1,000+2) = 1,000/1,002. This implies
that a CONFIDENCE value based on this data would be on the order of 30
decibans - but, barring other forms of evidence, it would take around
10,000 such emails before a claim of 40 decibans of confidence would be
warranted.
Note that this is an extremely simple formula, and there are many
better ones that can provide more accurate results, and take into
account more kinds of evidence. Any user who knows of a better method
to generate CONFIDENCE values should use those ways; the Sunrise
Formula is provided as a basis for users who have nothing else to
create estimates with.
More sophisticated Bayesian analyses can be used to create ad-hoc
certificate authority systems. This would involve one vCard with an
authority describing itself, and signing it; another vCard where that
authority issues a card describing a second entity and its key, using
the CONFIDENCE parameter to give its Bayesianically-generated level of
belief; and a third card where that second entity describes a third,
offering its CONFIDENCE level. A user with access to all the vCards
could then determine, based on its own trust-level of the root
authority, how much to trust the other entities. This trust of the
root authority could be generated either with the Sunrise Formula, or
with an analysis of web-of-trust data.
Examples:
BIRTHPLACE;CONFIDENCE=50:Winnipeg, Manitoba, Canada
ABNF:
confidence-param = "CONFIDENCE=" (INTEGER / FLOAT)