First, YOU CAN NEVER trust anything on the internet to be 100% true.
So it is myspace and or facebook.

If I could have a mean to be SURE that something I read on the Web is what was written (that it was not tampered with), and if the service also ensures that it was written by someone I trust, therefore I can trust something published online. Then I can gather information expressed by people trusted by people I trust. And so on. WebDSign does all this, and more.

Search for "strong authentication", "digital certificates"...

not sure the point-
for banks, there is verisign etc...
what's the specific purpose here?

I just don't see how you can verify data that is changed daily. The way it works on the internet is by looking at the source of the information. For example I trust the NYTimes website more then some blogger. There are many way to account for creditability of research.

The most you could follow is research guidelines and follow up on sources.

Maybe, you could make charts of how many mistakes in accuracy were made on the site comparison to size. Even though this would still be hard to do.

But, all data on the internet is subject to change and would be nearly impossible to check everything. I think it is a nice idea, except it is not something you could implement effectively if at all.

The point: the Web will convey some "real life" trust, enabling various services: fighting against astroturfing, keeping a proof of origin and first publication date, electronic voting, advertising claims certification (by known experts) ...

Please check http://www.makarevitch.org/webdsign/ for details, let me know if something remains blurry.

"how you can verify data that is changed daily": they are changed by human or by tools, which will have a digital certificate enabling them to seal the new version. Nothing changes for "authors": the software used to create or publish information will automagically use their private key to seal. Every browser, then, can display trustworthy replies to various questions, such as "who wrote this?", "do I read exactly what was written or was is tampered with?", "who liked (or disliked) this assertion?", "where are the reviews/evaluations/... of this?"...

"looking at the source of the information": indeed! Thanks to WebDSign you can configure your browser in order to emphasize (or even only see) information written or validated by at least a given number of people (your friends?) or entities (NYTimes?) trusted by you.

"mistakes": that's a potential application. Example: your browser, upon displaying a document, will show that it is "mildly appreciated" by 1 entity trusted by you, and that a bunch of texts criticizing it is "validated" (accepted) by 15 entities trusted by you.

The proposed logic will no check anything, it will only produce certificates (this is a common task) and gather informations about seals (to which document is it attached, where are the emitted opinions/critics...), sent by the tools used by their authors. Then part of the code, integrated to your browser, will (if you want so) let you know, for example, how people you trust judged whatever you read, for example thanks to specific background colors.
http://www.makarevit.../webdsign/#wikipedia briefly describes a potential application.

Well, thanks for your inputs! I refined the documents here and the more complete version published on my website, please let me know what you think.

Interesting concept and it does address an ever growing need as information is bounced from the original source to many other secondary references, blogs, newsletters etc. and the many clipping services around the net.

To be successful though the sealing authority would need to be regarded as a trusted source and this will take considerable resources. Also, the usage experience would have to be very simple and non-invasive to be adopted by the majority of users/publishers and i think this is your greatest challenge. PGP for example wasn't widely successfull for the average consumer user because it was not user friendly enough.

I am not totally clear having read you website how easily one could verify a snipit of an article clipped from the original web page or indeed a clipping of a clipping sitting on a blog somewhere?

Now, I think I understand more about what you want to make happen natmaka.

OK, lets say we have web page. From what I am thinking (correct me if I am wrong) this is how it works:
1. A author posts and wants to have it sealed by your service. That or the site was found by this services search spiders.
2. This site adds that page in it's index and makes a cache of the content.
3. The author gets a certificate if he submitted the site.
4. Users rate the authors content. (By means of some online application or browser plug-in)
5. User ratings are then stored in a file with the cache of that page.
6. Other users can access and see what there friends rated it, what everyone else rated it. In addition they can go back and see the past cached copy's.

There is NO guarantee of the information actually being the REAL truth. But, it can give VALUABLE feedback about what everyone else THINKS is the truth.

Except I don't think "everyone else" would be very trustworthy. Because results would be easy to manipulate. The real value of this site would be in the groups.

The application would most likely be used for writers, researchers, and educational institutions. That form groups of trusted people. So, they can work together and help each other.

This site could be done. I give it my green light.

> To be successful though the sealing authority would need to be regarded as a trusted source

Indeed! I plan to obtain this thanks to transparency (nothing pertinent will be hidden) and time (using it will convince more and more users).

Note that the site will be protected by many site-certificates issued by serious and well-known companies (their signing key are in every browser's key vault).

> the usage experience would have to be very simple and non-invasive

Indeed! That's my main problem, as I'm not able to conceive, implement and test such an interface. I was a developer, but did not realize anything with user interfaces since... err... many years. I hope to find help about this, among other matters.

> how easily one could verify a snipit of an article clipped from the original web page

With WebDSign ( "WDS" ) an author seals (and therefore signs, as PGP/GPG does it) some parts of his writings (or drawings, or sounds...). Those parts are meant to be quoted, if possible in full form. That's because no one wants distorted quotes, no one wants to be quoted off-context (you say "I agree with John when he says that the sun shines" and people quote John saying "The sky is green" then your sentence truncated to "I agree with John". Ouch!). Therefore each and every WDS snippet is coherent, it is an 'atom', created and sealed by its author. Each 'atom' can be of any length and can quote other 'atoms'. The easy (and 'default') way is to seal while publishing is to seal the whole document (web page). All the necessary signature functions are done by the authoring tool: the author selects a snippet then clicks 'sign' (he has to have his certificate on the machine and to type, once per session, his passphrase)

Any quoted snippet travels with an anchored URL (the ones with a '#' sign) pointing to the beginning of the snippet, which is closed by a comment containing the seal. The author of another document can therefore quote by copying the text (or paraphrasing it, if it is not a 'sic' quote) and associating this with an URL to the original document. All this is easily done transparently by a simple function added to any existing authoring tool.

When the text is visited any WDS-augmented browser knows how to find the seal, verify it and display, along with the web page or in a different panel displayed upon some 'inspector' action (the user points to the quote which only has a discreet mark revealing the presence of a seal and pushes the mouse right button then selects 'WebSDign' in the menu) relevant informations such as: who is the author of this quoted text? is the quote distorted in any way? does anybody I respect expressed anything about the way of quoting used, or about the what the quote asserts, or about the author of the document which quotes? where are the documents criticizing this quote? and so on.

Note that in order to avoid letting the browser fetch all documents referenced in the current web page we may devise a way to use comments, in the current web page, revealing if there is a seal on the original site. Also note that using comments this way (as pragmas) is not a very efficient way to achieve this, but if the approach is adopted a coming 'definition' (XML schema) of all involved languages (mainly, but not only, HTML and XML) will offer adequate attributes.

Let's say that a lab benchmarked products. A company thinks it shows why and how its products shine and wants to quote, on its website, an abstract of the corresponding report. The company can devise a way to express the results of the benchmark then submit it to the lab representative. This can go back and forth and when they agree on an appropriate way (words, graphics, sounds... whatever) the lab seals it. The lab can make the comp pay for this service. If the lab is populated by mercenaries (crooks?) giving only praise to paying customers many other labs will publish and seal negative opinions about the rotten report, and anyone reading the quote will know that many criticized it and will be able to read associated explanations (why is it biased?). If many competitors write negative opinions anyone reading the quote will be able to know it and to read their explanations. Tiers (users of various products?) may also comment, and so on. Any opinion/comment (atom) may be associated to appreciations, some by people you respect, or people respected by people you respect, and so on. Each atom, therefore, has a 'score' measuring its quality for [B]you[/B], calculated upon your own "network of confidence". Think of the "Web Of Trust" (PGP) combined to the usual "Karma" (or "Glory", for Cambianhouse) in a tightly-secured way.

Note that it preserves anonymity. Anyone can use a certificate to create atoms (documents, opinions...) and be appreciated (opinion atoms) thanks to this.

> or indeed a clipping of a clipping sitting on a blog somewhere?

That's the case of an atom quoting another atom. This is also the way to convey opinions thanks to WDS. For example one may write: "I agree with what you may read in the document X". This text will be sealed. 'X' is a reference (URL pointing to) to another text, and this URL is also sealed. The pointed text can also be sealed, and it can contain atoms sealed, and any documents pointed by it can be sealed. And so on. Anyone reading an atom at any 'depth' can, thanks to an inspector, read the complete zoomable graph of those relationships, and also launch an 'exploration' calculating the degree of confidence of any atom (a reply to the question: "how did people and institutions I respect 'scored' this atom?")

Please let me know what remains hidden.

Thank you!

> 1. A author posts and wants to have it sealed by your service. That or the site was found by this services search spiders.

That's correct. In fact he can seal by itself, he only needs a tier sealing if he also wants timestamping (i.e. being able to prove that the document existed at a given date)

Spidering is a way to find seals but I think that many authors will let their authoring tools inform the central site on each new seal creation. Some may want to avoid this because it enables readers to easily find documents criticizing theirs, but the confidence 'score' of such 'discreet' atoms will not be very good.

> 2. This site adds that page in it's index and makes a cache of the content.

No cache is strictly necessary, but it can be a Google-like goodie. The central site is mainly useful in order to find opinions and critics about a given sealed document, and also to detect changes in documents (which implies new seals, which implies some warning to people quoting the old version)

> 3. The author gets a certificate if he submitted the site.

Let's say that a 'certificate' (storing a public key, the corresponding private key and various informations about the owner) is used to create a seal. Each author or critic can obtain as many certificates as he wants and use it freely, but each certificates has is own "reputation" in the whole system. Every certificate will be a standard one (X.509, GPG, or anything upon those lines), it will not necessarily be emitted by the central WebDSign system (it can be a certificate integrated to a passport, this means that the central WDS system will 'recognize as good' such certificates), enabling one to use a seal associated to his real-life 'true' (government-backed) identity, and to also use various other seals, some anonymous, for other activities. He/her can even let an anon seal 'come out' by proving he detains it, therefore showing to everyone that everything sealed by "JoeSixPack" was in fact sealed by him/her.

> 4. Users rate the authors content. (By means of some online application or browser plug-in)

Indeed

> 5. User ratings are then stored in a file with the cache of that page.

Only links need to be stored, as they are sufficient. But maintaining a cache may serve various other noble (or less noble) needs.

> 6. Other users can access and see what there friends rated it, what everyone else rated it. In addition they can go back and see the past cached copy's.

Indeed

> There is NO guarantee of the information actually being the REAL truth. But, it can give VALUABLE feedback about what everyone else THINKS is the truth.

Indeed (it is not only about truth, but here lies an important added value for WebDSign)

> Except I don't think "everyone else" would be very trustworthy.

That's your choice. You may configure that only YOUR own seals are to be taken into account when calculating the score of a sealed document. You may also let it take into account your friend's seals. And even their friend's ones. Some will want to use coefficients, upon the 'depth' or for given individuals (you may respect his opinion about a topic, but not about another). Some may want to give confidence to seals of people working in universities, political parties, whatever (and their friends... or not). Some may edit official lists of trustable certificates, for you to adopt (or not). There will be a standard and sound configuration, inherited from existing models, and everyone will be able to tweak, even on-the-fly (you read something cool, you search other documents by this author, coolness is at max, you configure your trust to him at a fairly high level. Some of your friends, who decided to give trust to whoever you trust, will automatically trust him/her, maybe a in a somewhat lesser extent)

> The real value of this site would be in the groups.

Indeed!
The site will not decide what is good/true or not. It will let groups decide, just as it is now done, but in a much more secure fashion. This may, for example, end astroturfing.

> The application would most likely be used for writers, researchers, and educational institutions. That form groups of trusted people. So, they can work together and help each other.

Indeed.

> This site could be done. I give it my green light.

Thank you!

"No cache is strictly necessary, but it can be a Google-like goodie. The central site is mainly useful in order to find opinions and critics about a given sealed document, and also to detect changes in documents (which implies new seals, which implies some warning to people quoting the old version)"
OK, so how would it work without a cache of the page?

How would the site know what the changes are and what the past changes were? How will the site compare data without something to compare with?

> how would it work without a cache of the page?

Because the central site only has to detect changes, not to detail them (establish a 'diff' of them). Therefore it will only store a copy of the seal which contains (among other things) a digital 'fingerprint', sometimes called 'hash', of the data (often called 'message' in this context). This 'fingerprint' is a numeric value somewhat magically 'characteristic' to the data, produced by a given 'hash function'. Some well-known fingerprint types are MD5 and SHA1, if it doesn't ring a bell search documentation for them, if you can't find anything just let me know.

The classic problem of collisions (same fingerprint for different messages) will be dodged by using various tricks, mainly storing the data size (a collision probability is reduced if both messages have to be of the same size) and using, for the very same message, multiple and huge fingerprints, for example SHA512 along with RIPEMD-320.

Moreover the central site can detect if a document was modified without downloading the document or comparing the fingerprint it stores and the fingerprint placed in the document's seal, because if the publishing software and webserver works normally (most do) a simple 'HEAD' HTTP request is sufficient to detect that it was not modified. This enables the central site to frequently monitor for changes made without notice (either without new sealing or without sending the new seal to the central site, which are not good ways to proceed)

The user can (and prolly will) ignore those nitty-gritty details. Authors will write, some will select coherent portions and sign them by a single click on a button provided by their authoring tool. Websites visitor will see various signs revealing the 'score' of displayed information and will be able to obtain details about it. Simple and clean, just as, in real life, you class information by thinking, for example "John just said something astonishing but my brother Alex said to me that he is OK, skilled on the matter and serious, therefore I believe him".

Perhaps I should have phrased that differently. I understand how that could be done with commonly used security applications and protocols.

But, what I was getting at was the users could not look back to previous comments in the original context.

Example:
Website Page-- There are ten foxs in pet store boxs.
User Comment-- There was actually only nine foxes according to my sources: Bla Bla Bla...
But, then the page gets changed.
Website Page-- There are lots of fish in the in the tank.

Even though the site knows something has changed. It can't bring up the old version, so the user can look at what the original context of the old comments.

Unless you are simply going off what the users believe or don't believe is true. In that case then it would not matter.

> understand how that could be done

I try to be excruciatingly clear (better "boring for the uninterested" than "unclear for the serious reader" ), without any preconception upon what any reader of this forum knows. Bare with me :-)

> what I was getting at was the users could not look back to previous comments in the original context.

Any opinion expressed in an atom can be made in 'swallow' mode, which copies the contents of the criticized atom into the new ('opinion') one, instead of having a mere reference to it. This will be done, at seal-creation time, thanks to some dialog or radio-button. But this is IMHO a goodie, not used by most, for reasons explained below.

A more technically efficient way to keep old versions is to have the central site keep the contents (original text, corresponding seal, as long as opinions seals about it then opinions about those opinions...), letting all opinions seals published elsewhere only refer (URLs) to the original text (the central site can then bring the corresponding contents, for a given date therefore for a given 'opinion' atom about it, à la "version control"), but it will be, as I wrote it, a 'goodie' (i.e. users will have to pay for it) either sold to the author who wants to stand behind his thoughts to the point of recognizing his errors (in the default configuration of the routines calculating a score this behaviour may, for certain users, pump up his score but this will not be the case by default because it enhance some scores upon a strictly money-related parameter) or to the critics (who wants to prove that the original author wrote something stupid/false/whatever, even if he suppresses it from his website). The corresponding storage and process needs, for the central site, will justify the invoiced cost.

To preserve openness there is now obligation to buy this "seal-and-content-storage" service, nor to buy it from the central site, nor to not do it yourself.

As you prolly know it this is called a "non repudiation" service.

"Non-repudiation" is a goodie because most useful debates will involve serious people who recognize their mistakes, if only because they just cannot pretend not having published then suppressed what thousands of people have read on their site then cannot find anymore (it will cause a storm of negative opinions "I did read it! He suppressed it! He lies!"). This alleviates enabling non-repudiation by default.

> Even though the site knows something has changed. It can't bring up the old version, so the user can look at what the original context of the old comments.

Thanks to the "non repudiation" goodie this seems solved to me, and a service will include tools for the critics (for example a "diff" tool). There is a potential for a fair amount of paid services, I have other pertinent ideas and will elaborate at project start.

> Unless you are simply going off what the users believe or don't believe is true. In that case then it would not matter.

Indeed! Some, in some circles and at least under certain circumstances, will be happy with this.

Hi natmaka,

I happen to have some background in security and security parlance ( I participated in writing echeck for IBM at http://www.echeck.org/). I think you are on to something here...Deriving authentication of documents into authenticating of information is indeed an evolutionary idea that the Web would embrace if executed well.

However, I don't think you are going to get a whole lot of feedback unless your responses are shorter and concise. Believe me, I learned the hard way...

> you are on to something here

Thank you! Are you interested in joining the project?

> I don't think you are going to get a whole lot of feedback unless your responses are shorter and concise

English is not my mother tongue and I'm afraid of being obscure or misleading while craving for concision. Given that there is no WebDSign prototype for end-users to play with, it can only at this point benefit from the ideas of people really interested and somewhat technically informed, who are probably interested in some level of detail. I hope that some could overcome the burden and that some able to devise messages more adequate for other audience will join the project.

>>Thank you! Are you interested in joining the project?

I think it would be impolite to ignore the invitation. I will send you a PM, so that I don't steal others' bandwidth here.

>>English is not my mother tongue and I'm afraid of being obscure or misleading while craving for concision...

I think your English is excellent, but this is a challenging idea to articulate and implement.

I think an illustration would convey the concept better --no prototype is needed yet. Please have a look at slides 13, 14 and 42-44 of the following PowerPoint presentation for one example:

http://www.echeck.or...verview-security.zip

Good luck

why and how is this paid for?

ooper: thank you, I will check this!

tlyden: the central service can sell, by the usual means (credit card, Paypal...): certificates, cross-certification, timestamping, alert, layering, collaborative filtering...

Details:

* certificates

For authors wanting to be immediately recognized by the central system. They can buy one elsewhere or even create it but buying it at the central site will enable them to be recognized under their real identity (this is useful for experts, journalists...).

Technical note: we will offer all pertinent PKI-related services: centralized (default) and decentralized (sort of escrow enabling for example a company to recover/revoke a certificate misused by an ex-employee) modes, 'n of m' (certificate issued to a group of 'm' members, only usable if 'n' members agree to do so)...

* cross-certifications

Certificates issued by third parties (certification authorities, for example Verisign or an in-house PKI) will be honored by the central system as providing an identity proof

Any certificate will be recognized and used but WebDSign will not guarantee identities not certified by a certificate issued by its central system or by a cross-certified authority. Even anonymous users will Moreover users will know the central site and therefore may be more confident to buy there (through some anonymizing apparel), without disclosing their identity and at a bargain.

* timestamping

For authors wanting to be able to prove that they were the first to state something we will sell a service 'you send the atom, we add timestamp to it then sign the whole'. In fact we will use existing timestamping services, recognized by various jurisdictions

* alerts

The 'alert, something you criticized/liked/disliked/whatever changed!' service, not tied to any action/dissimulation of the information publisher. Think 'sort of RSS able to automatically alert after a modification even if the author does it discreetly, without announcing anything', if necessary with filters (distinct alerts for different modifications types/authors/...)

* layers

The 'layer' enabling users to let browsing benefit from opinions emitted by people they trust. Some basic functions, for example 'Browser, show me the list of all documents liked by my pals' will be free. The function is similar to StumbleUpon's but forbids pollution (for example astroturfing). Enhanced stuff will lay on collaborative filtering and be an invoiced option.

There are other underlying money-making projects, for example specific voting or decision-making systems, guilds of experts...

I received questions about this mysterious 'timestamping' service.

You post an idea on the web (let's say a concept description, on Cambrian house), having it signed by an authority in such a way that a judge will recognize your anteriority (precedence). This already exists, search for 'legal timestamp', and the minimal cost is $10. But this is cumbersome to use on-the-fly, there is no support for direct and easy online proof-checking, online quoting...

This service does not check for precedence but merely establishes a legal proof that YOU have submitted to the timestamping service a given document at a given date.

Before or during a trial if someone can exhibit a more aged serious timestamped document considered as equivalent by the experts, followed by the judge... you are stuck. But if you really are the first it can save your day.

Better safe than sorry.

I have an issue with browser plug-ins in general...if this can be done without another piece of software on my pc / mac / cell phone, it'd definitely be useful to me and, I think, to most people engaged in content "production."

> I have an issue with browser plug-ins

I understand and hope that the functions will be soon integrated to all browsers but , given all existing constraints, we have no other choice than develop the the first versions as plug-ins.

Thank you

I think the centralized approach is the key here. Have the documents pass through a server that "validates" them. The author would initialize the process and anytime anybody wanted to verify the contents the could connect to the verifying server and match the document key against the stored key. If the document is found to suspect by others, they could also rate it accordingly (yes, I know what I said about rating in other pitches)

No browser plug-in, no additional software to download on everyone's machine.

> I think the centralized approach is the key here. Have the documents pass through a server that "validates" them.

((...))

Your proposal is absolutely sound for a proof of concept aimed at showing how things will be done, it is would be of paramount efficiency for fueling understanding, but I rejected it to avoid major security-related problems and a too much workload for the central site.

Your proposal implies that the sealing part will be done one WebDSign's servers. For this the private part of any certificate, used to sign, will reside on WebDSign servers (centralized mode). This is not reinsuring for the user as whoever has it can do evil things (forge the user's identity, sign as him...), not easy for WebDSign as some bad guys willing to forge ID may be able to break in (even physically). Cryptographers would scorn WebDSign for this.

Moreover, thanks to the decentralized architecture proposed, many calculations are done by the browsers, who only fetch data from WebDSign's servers which can scale up more easily because they are only the usual register-selfcare website (not a big deal) and a database.
If the WebDSign central server has to calculate, especially for public key cryptography, it won't scale up or, at best, we will need fair amounts of money to cope with a growing number of users. Random-number picking, for example, implies a huge amount of generic processors or expensive specific accelerators. Constantly generating many 'good' random bignums per second is a serious task for serious hardware, and a bunch of others daunting tasks are waiting in the dark. The overpowered user's PC can do it.

Your idea shows that you understood, this is useful for me.

Thank you!

True, the users' overpowered PCs can handle the calculation, but doesn't this take away from the "trust" aspect? Controlling the documents through a centralized server gives some credibility to the process.

I think it could drive more users to the validation process if they knew that a document was "certified" and it contained accurate information. Eventually, everyone will say, "That document doesn't have a WebDSign signature, forget it, I don't trust it"

when i ask who is paying- mean how big is this?
"For every Web user who wants to enjoy online the benefits of real-life trust"

> PCs can handle the calculation, but doesn't this take away from the "trust" aspect?

No, it doesn't, because those calculations are only useful to exploit existing data for the user's benefit or to 'produce' trust associated to the user.

For example those calculations will establish the 'trust score' of a given document for the PC's user (by fetching from the central database the list of every opinion expressed about it by other users trusted by the user, and maybe users trusted by those last, and so on..., then applying rules and coefficients defined by the user). This is done for the sole user's benefit, if he distorts it he, and only he, will read gibberish.

Those calculations will also 'produce' trust associated to the user upon certificate's creation time. Some users will create certificates only associated to a nickname, or even to a false or forged identity. Apparently this takes trust away, but let's check this.

Many associate 'trust' with 'identification'. I mean: many think that not knowing the author's name makes harder to trust, to believe. It's always true in real life (albeit you may invest trust into some function, for example to a police officer you don't know but who wears all his function's attributes: uniform, insigns, weapon... this is an ID, sort of) and WebDSign maps it online by selling certificates which guarantee that the identity associated to it is its owner real-life identity. WebDSign, before delivering such certificate, will double check the requester's identity and your approach to trust, the usual one, will work with all seals made thanks to the certificate. It also works on decentralized mode, when the user's PC calculates the certificate in order forbid anyone (even WebDSign servers) to have his secret key: there is a trick enabling the server to sign (in order to say "this identity is guaranteed by WebDSign") such a locally-produced certificate.

That said let's insist upon the fact that, by default, WebDSign does not guarantee the identity associated to a certificate. Anyone can obtain/create a certificate associated to any nickname, then start to use it. WebDSign will publish the public part of those certificates but NOT sign them, therefore it is up to everyone to trust them or not. The WebDSign browser extension only checks, upon user request, that a given certificate sealed a given document (or part of it), for example in order to say "I'm the author!". Some users may be aware of the real identity hidden under the certificate and trust it, or maybe (with time) some may read all works signed thanks to the certificate then begin to trust the anonymous author.

Let's say that you read, on Cambrian house website, articles posted here by a "Joe42" account. They are cool. Month after month, there is no problem with them: useful, to the point... You declare to your WebDSign browser extension that you like things signed by his certificate. When he posts something signed, you can be alerted, you can check that 'he' wrote it... Even if our friendly Cambrian house hosts made a booboo, letting a newcomer or a pirate take this account over, and even on another website! Wherever and whenever you can check that, for sure, an information was written by the very same guy. You can be alerted of all opinions he emits about anything published on the Web, for example in order to check what he liked. You may decide to somewhat trust people trusted by this anonymous certificate owner. Some of your friends may benefit from it because they decided to trust people trusted by you, maybe to a lesser extent. When the certificates signs stupid opinions you ask your browser's WebDSign extension to ignore it, or even to 'antitrust' it ("hate what it likes"). This "Joe42" guy may one day 'come out' and reveal that he his "John Smith, 42 Blue Hill, CHICAGO", easily proving that he has the "Joe32" certificate. But he can also never 'come out'. If many 'discover' his work and like it his WebDSign reputation will skyrocket, he may be able to sell his opinions or documents...

Part of all this is already possible on a single given website. Thanks to WebDSign this becomes immediately true on the whole Web (without any websites retrofit), there is no more pollution (astroturfing, forging...), everyone can benefit from the opinions of trusted people (even in order to trust or distrust others), everyone can instantly find all opinions expressed about anything published, be alerted when something changes...

> it could drive more users to the validation process if they knew that a document was "certified" and it contained accurate information

WebDSign will never deliver, by itself, such certification. As a WebDSign user you will know that some information is trustable (or not) because people you trust (or people trusted by them...) will have expressed "it is trustable" (or "it isn't"). Upon 'reading' something (it may be a text, an image, a sound...) you will be able to select the document and right-click to obtain the usual menu where a "WebDSign" line will lead to a submenu offering, among other functions, a "Check" function. By selecting it your browser's WebDSign code will show all seals attached to the document, even opinions expressed about it, sorted their 'proximities' for you (i.e. those emitted by people you trust will be on top), by clicking on any you will check then explore its contents. You will be able to check any, in order to be sure that there is no forging. On top of all this the extension will calculate the document's 'score' for you, giving an abstract (as a numerical value, a color, a detailed text... whatever you prefer) of what it found, which for example is "1 trusted said it is OK, 4 trusted by trusted said this document is OK, 1 untrusted said it is not OK". Note that you can decide to 'trust' groups and entities, for example "any certificate issued to a professor or researcher from Stanford or the MIT". The standard way of 'calculating' this score will be sound but every user will be able to tweak or configure it. The central WebDSign servers are databases enabling the browser's WebDSign extensions to fetch all necessary material (public parts of certificates, seals and references (URLs) to seals), answering to their "questions" such as "send a copy of your public key to me as I want to check whether a certificate is signed by you (certified identity)", "where are all opinions about this document?", "send public key of the certificate signing the opinion I'm reading as I want to verify that the claimed author is the real one"...

As you see WebDSign avoids constraining the user and gives him the full power to check everything by himself. It doesn't create trust (aside from certifying identities coupled to some certificates) but references, stores and/or conveys it.

Most serious authors will buy a WebDSign-signed certificate, even if they use a pseudonym, but nobody will be obliged to do so. Even such anon can use the timestamping service (proving that he was the first to have a document, therefore that he is very probably the author)

Anyone can lose his certificate or have it stolen, potentially leading to bad guys taking an identity over. But there are solutions: hardware devices keeping it safe, for example smartcards (the card costs a few bucks and the reader device approx 50) and revocation procedures enabling the real owner to 'remotely destroy' a lost/stolen certificate thanks to secrete informations defined at creation time and only used for this purpose.

> Eventually, everyone will say, "That document doesn't have a WebDSign signature, forget it, I don't trust it"

I hope so! Then "That document has such and such favorable opinions from people trusted by me, therefore I think that it may be good", or "This is only appreciated by untrusted people, I don't trust it", or "How weird, some trustable say NO, others say YES, let's read all opinions about this and sort it out by publishing my own opinion about every dumb opinion, and my overall opinion about the document"

> when i ask who is paying- mean how big is this?

It seems pretty huge to me. And fun, too :-)

Moreover it offers tools attracting even surfers not interested in the core functions: the WebDSign website will ask them to, anonymously, enter a bunch of URLs they like. It will then find favorable 'opinions' about them then track the authors of those, for favorable opinions about other URLs, then present those to the visitor. Chances are he will like them, or at least be able to say "I like this one, not this one", leading to some refinement tour. Thanks to this simplified collaborative filtering I bet some will sign up for a free WebSDign account :-)

Sorry tlyden, I may have misunderstood your question.

I think that many professionals publishing whatever work on the Web (companies, official bodies, experts, journalists, known blogers, information brokers... maybe even politicians willing to show that they stand by their words) will be interested in a certificate certifying their identity in order to ease finding their work (wherever it is published), or to forbid misquoting or identify forging, or to seal whatever they publish (for example: is it OK to install the new driver you just obtained. Does someone inserted some dangerous program into it? You ask WDS to check the seal, it lights green, it's OK. It works even via weird pathes: some unknown guy downloaded it from a mirror via an unsure LAN and placed it on the CD you obtained(!). Or to alleviate more realistic risk (someone puts a transparent proxy between your box and the Internet, and modifies on-the-fly whatever you see. SSL/TLS (HTTPS) is OK but weaker and unusable offline). You will not pay for this, but the company sealing the driver will pay its guaranteed certificate, just as it now pays a certificate for SSL.

For similar reasons many authors (even in the scientific community) may be interested in a guaranteed identity and in timestamping, enabling them to easily and immediately publish on any site along with a solid proof of priority.

Critics will like the non-repudiation and tracking service.

All those services aren't free (gratis).

Please let me know if I didn't understand your question or replied adequately.

I guess I am still missing the audience here.
For "authors" who are published how does this add security? for a standard politician website how does it add trust?
I guess i can see a peer reviewed process for niche areas, but how is this much better than Wiki-security?

> For "authors" who are published how does this add security?

It enables the author to sign whatever he publishes, in a way establishing that he is the author and forbiding forging (other people publishing BS attributed to him, website 'defacers' modifying his site's contents...). This is only useful to the few often attacked in such a harsh way.

It enables any author to always benefit from his reputation. You, for example, can post messages signed here then post anything else elsewhere and everyone, if you want so, will immediately and easily be absolutely sure that all this is from the very same author. This is useful to many web contributors active on many sites. Note that everyone remains free to use multiple different certificates in order to maintain "local" (globally unrelated) distinct identities.

Coupled to timestamping it allows any author to prove that he was the first to write a given document. This can be useful to anyone creating something potentially new and valuable.

> for a standard politician website how does it add trust?

It enables him to explain in a clear way why he neglects answering to any misquoting of his published documents. Many quotes are deliberately distorted or made with no respect to the context. Thanks to WebDSign he will be able to say, for example, "I stand by MY word, published on my site (which can't be defaced) and will reply to every comment properly quoting it. The rest is bullshit, it does not present my thoughts, I invite everyone to ignore it and to scorn those who play this game".

> I guess i can see a peer reviewed process for niche areas, but how is this much better than Wiki-security?

I'm not aware of any "Wiki-security", what is it?

http://en.wikibooks....cience:Wiki_security

For what I understand this "Wiki security" article is not a service by itself but a mere list of various existing protocols, conventions and tools enabling a wiki maintainer to alleviate some of the problems tackled by WebDSign.

Granted, it offers solutions for problems not in WebDSign's spectrum, for example restricting server access (considered at plainly impossible for the leading program: http://www.mediawiki...e_access_restriction )

But it solves problems mainly locally (at best on a wiki 'farm' or 'group') and implies installation of various server-side softwares (some not even talking to each other or even implemented for the existing wiki server software).

WebDSign solves them globally, even for non-wiki sites, by managing trust for the whole Web without implying any modification of existing webservers (nearly all approaches described in this 'Wiki security' document imply a server's extension).

Moreover those proposals does not enable anyone to write an opinion (evaluation) linked to the document commented, nor to timestamp anything, nor to benefit from 'layers' enabling them to see mainly/only documents liked by people/bodies they trust.

I can see other differences, but all this seems pretty sufficient to me. Please let me know!

Here is a first version of a non-technical presentation, please feel free to comment

http://www.makarevit...ign/WebDSignV0.5.pdf

Congratulations, natmaka. Good Luck with moving this idea forward.

Thank you PeeJayEl! I'm willing to move it!

Keep up the good job on 'North American Food Bank Registry' :-)

Congratulations natmaka. Good luck in the future with it.

Thanks Rich! I will go on and inform right here about the whereabouts

http://zigtag.com/
...some overlap functionality, but they're less concerned with accountability and more social activity. Something to check out for ideas anyhow. Congrats on your win!

Zigtag: thank you, I'm investigating on it! There are many Stumbleupon-like sites, I could not find one really concerned accountability, webwide identity preserving anon, opinions, monitoring...

natmaka,

how is this any different than having someone become your "friend" like in facebook ? if you give someone a "seal of trust" it is no different than making them your friend, is it?

please explain (briefly!) :)

Explanation: the 'FaceBook friend' relation is only active on FaceBook (WebDSign is Web-wide) and does not enables you to automatically benefit from their opinions when you browse the Web (WebDSign does).

Among other differences, but I kept this one brief. As an exception :-)

Excellent idea and excellent thread of comments. I'm only now catching up with this, but I think it's great. For the record natmaka, I think both your idea and explanations of the details are very good.

From an infrastructure standpoint, have you considered how this is similar to the existing Firefox browser plugins that allow users to annotate other peoples' pages? There are plugins that allow you to leave comments on a page that will be viewable by other people using the same plugin. That would seem like a great starting point for your system, and you would layer filtering based on trust relationships on top of that.

From a development standpoint, you could start with an annotation system and build the social network on top of that, allowing users to filter their view of comments based on what other people thought of that comment (e.g. Slashdot forums comment ratings) and personal friend/kill lists. Once you had these user-facing basics in place, you could start building your community while you added in all the signing and non-repudiation elements on the back end.

I think many users would use the system without the security features because they either don't care enough or they don't understand what benefits they provide, but their use of the system would still help you reach critical mass. Providing all the technical details implemented correctly would only serve to expand your audience to those people who did understand and have a need.

Micco

Thank you!

Yes, I have considered many Firefox plugins and we are currently developing a first version in this very form :-)
It is suboptimal because many don't use Firefox or don't want to install plugins, but may let us prototype or even gain momentum. Betatesters will be welcome (please drop a private message to me)

I tried hard to avoid building the trust-system at first, but just can't see how make the whole system work efficiently and surely without it, especially because I want it to be open. This last argument is somewhat sufficient: in most cases it is much more cumbersome to add security to a system than to devise it with respect to security concerns.

I absolutely agree that it can be cumbersome to try to add security after the fact, but that doesn't necessarily mean you have to build the security first. If you build the interface elements with your security model in mind, then you can add security later without the drawback of it being an afterthought. That is, design security first but build security last can be a good way to move your prototype quickly. This lets you start testing a lot of functionality early while you're still implementing the behind-the-scenes security.

True, and I'm particularly interested in fact that the prototype will very probably be lighter. My problem is: I'm not sure to be able to detect the time when adding real security (I mean implementing it) will be necessary, and I'm ready to trade some prototype flexibility for being pretty sure that we will not miss this moment.