- From: Adeel Ahmad <aahmad1811@gmail.com>
- Date: Tue, 21 Jan 2020 00:01:37 +0000
- To: Sandro Hawke <sandro@w3.org>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Greg Mcverry <jgregmcverry@gmail.com>, Credible Web CG <public-credibility@w3.org>
- Message-ID: <CALpEXW1trkx_=EB8pLNLdHqbP3idN1VXf3KNtrtQj73hZJbTEw@mail.gmail.com>
Hello, And, sharing can be enabled via web annotations <https://www.w3.org/blog/news/archives/6156> effort, which is also used by hypothes.is Thanks, Adeel On Mon, 20 Jan 2020 at 23:54, Adeel Ahmad <aahmad1811@gmail.com> wrote: > Hello, > > I preferred the older spec on credibility indicators compared to the > credibility signals. Credibility Indicators was more thorough in coverage > which is what you would want out of a schema.org creativework > <https://schema.org/CreativeWork> compliant Credibility schema. > > Thanks, > > Adeel > > On Mon, 20 Jan 2020 at 23:30, Sandro Hawke <sandro@w3.org> wrote: > >> >> >> On January 20, 2020 4:45:40 PM EST, Leonard Rosenthol <lrosenth@adobe.com> >> wrote: >> >> CredWeb is aiming at a social notion of trustworthiness >> >> >> >Interesting. While that might work for web sites/pages – it won’t be >> >for the assets contained on those pages (or found elsewhere on the >> >Web). >> > >> >Is that direction locked in stone for CredWeb? Would the group >> >consider expanding its definition of “Credible” and “Web”? >> > >> >> We don't have a formally approved charter, so nothing is locked in >> stone. >> >> Can you give me a concrete example of the kind of functionality you're >> looking for? I'm not quite sure what it means for a digital asset to be >> trustworthy. >> >> What comes to mind for me is digital cameras attaching time and location >> and camera ID information to photos in a way that's potentially quite hard >> to forge (and hopefully also doesn't reveal private information). Is that >> the kind of thing you're talking about? >> >> - Sandro >> >> >> > >> >Concerning VC – I think if you forget about the specifics, the idea >> >that your claim/signal/whatever *must be* “integrity protected” is key. >> >This is especially true if/when it is separate from the people (and >> >their trust/reputations) involved. >> > >> >Leonard >> > >> >From: Sandro Hawke <sandro@w3.org> >> >Date: Monday, January 20, 2020 at 3:44 PM >> >To: Leonard Rosenthol <lrosenth@adobe.com>, Greg Mcverry >> ><jgregmcverry@gmail.com> >> >Cc: Credible Web CG <public-credibility@w3.org> >> >Subject: what do we mean by "signal", was Re: CredWeb Plans, meeting >> >tomorrow >> > >> >Mostly we've just been using the email list for announcements, but in >> >the interest of getting more discussion going, I'm going to offer a >> >substantive reply, below. Hopefully the Subject line above lets you >> >know if you want to read this. >> > >> >On 1/20/20 2:32 PM, Leonard Rosenthol wrote: >> > >> >> that "signal" has a long history in credibility research as a >> >"marker" to the consumer to indicate if a source is credible or not. >> >> >> >So that sounds like an alternative term for what I have been calling a >> >“claim” (based on the terminology from the Verifiable Claims (now >> >Credentials) WG at the W3C - >> >https://www.w3.org/2017/vc/WG/< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2Fvc%2FWG%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628061745&sdata=6OB29t8iZOP4lbjFUGeU6lwgyXqAXOxsaj7akL%2Frb%2Bk%3D&reserved=0 >> >). >> > Yes? >> > >> >Does a “signal” use any sort of technology to ensure authenticity (eg. >> >hashes or signatures)? Or is that out of scope or TBD?? >> > >> >I think the term "signal" is used somewhat loosely, a bit like >> >"information". Here's draft text from Credibility >> >Signals:< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals%2F%23h.94xsck7qz3ho&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628071751&sdata=thFM%2BN4FillMl2mcVHoLDHfwonSiD8HJJ8ODtVjwIS8%3D&reserved=0 >> > >> >Our basic model is that an entity (human and/or machine) is attempting >> >to make a credibility assessment — to predict whether something will >> >mislead them or others — by carefully examining many different >> >observable features of that thing and things connected with it, as well >> >as information provided by various related or trusted sources. >> > >> >To simplify and unify this complex situation, with its many different >> >roles, we model the situation as a set of observers, each using >> >imperfect instruments to learn about the situation and then recording >> >their observations using simple declarative statements agreed upon in >> >advance. Because those statements are inputs to a credibility >> >assessment process, we call them credibility signals. (The term >> >credibility indicators is sometimes also used.) >> >That's just draft text, and I don't know that everyone agrees with it. >> >It also intentionally glosses over several levels of meaning that could >> >have more precise terms. Some of these levels will speak more to >> >different kinds of people than others (#2 uses TCP, #4 uses RDF). For >> >example, consider: >> > >> >1. The age of an internet domain can related to its credibility. So we >> >can talk about this being a signal, maybe called "age of domain". This >> >kind of information, this "signal", is used informally in practice now, >> >and perhaps in some automated systems. It's a signal that's moderately >> >useful because it stops someone from trivially setting up hundreds of >> >websites, but it's also not all that useful because (a) attackers can >> >buy old domains on the aftermarket or buy them in advance and let them >> >sit before using them, and (b) it could penalize legitimate sources. In >> >this sense, a "signal" is general concept of a type of information. >> > >> >2. There are some protocols for finding out the age of a domain. For >> >instance, I can open a TCP connection to port 43 of >> >whois.verisign-grs.com, send "nytimes.com<CRLF>" and get back text that >> >includes the line " Creation Date: 1994-01-18T05:00:00Z". We might >> >call this "credibility data", "signal instance data", or perhaps "an >> >observation". Loosely, we could call this a signal, leaving implicit >> >that it's a signal about nytimes.com. >> > >> >3. Somewhere between these two, we might define the creation date of a >> >domain as the isodate timestamp of the moment the domain registrar >> >originally recorded as the creation of the domain, when it was most >> >recently created. Or something like that. Trying to be precise. Call >> >this a signal definition, maybe, or a signal specification. If we want >> >interoperability between multiple systems producing and consuming >> >credibility data, I think we need to get to this level. In practice, >> >for age of domain, we'd want this to line up with the available data >> >sources. No point in specifying something we can't have. >> > >> >4. Finally, there is some kind of standardized format for this data. In >> >JSON, maybe it's something like >> > >> >{"@context": >> >"https://www.w3.org/ns/cred"< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fns%2Fcred&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628071751&sdata=XmpfoIzjDNbcWs8m2fKcKx9Tbf0N%2BuUleQvoh8WPU4U%3D&reserved=0 >> >, >> > >> > "domain": "nytimes.com", >> > >> > "created": "1994-01-18T05:00:00Z" >> > >> >} >> >which might come out in Turtle as >> > >> >[] cred:domain "nytimes.com"; cred:created >> >"1994-01-18T05:00:00Z"^^xsd:dateTimeStamp. >> > >> >Alternatively, one might define the RDF mapping so we get something >> >like: >> > >> ><https://nytimes.com>< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnytimes.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628081734&sdata=%2FRKjr2onvey53G0mgZmr%2BU1UHdnAkT2QNmqOBve2kow%3D&reserved=0 >> > >> >cred:domainCreated "1994-01-18T05:00:00Z"^^xsd:dateTimeStamp >> >although to me that feels like bad modeling. >> > >> >I lean towards something like: >> > >> >[] cred:domain "nytimes.com"; cred:created >> >"1994-01-18T05:00:00Z"^^xsd:dateTimeStamp; >> > >> > a cred:Observation, a cred:DomainAgeObservation. >> > >> >So, that last bit brings us back to sense 1. I'm suggesting the object >> >which connects a domain name and its creation time is a kind of >> >observation, a domain name observation. We can also attach to it who >> >did this observation, and when, and how. Then we can say "credibility >> >signal" is a class of observations relevant to credibility assessments. >> >The observations can then be encoded in data formats like Turtle, or >> >CSV, or whatever. >> > >> >I haven't thought through exactly how the observations relate to >> >Verifiable Credentials. VCs go much deeper into a narrower use case. >> >There may also be some impedance mismatch with VC's crypto-centric view >> >of the world. I'm reminded of the Knuth quote, "Beware of bugs in the >> >above code; I have only proved it correct, not tried it." That is, >> >crypto wont help if the institutions behind it are corrupt. CredWeb is >> >aiming at a social notion of trustworthiness. (I'm by no means >> >dismissing crypto, which is incredibly useful at fending off a whole >> >range of threats. There are others it's not so useful against, >> >however.) >> > >> >Hoping this made things more clear, not less, >> > >> > -- Sandro >> > >> > >> >Leonard >> > >> >From: Greg Mcverry >> ><jgregmcverry@gmail.com><mailto:jgregmcverry@gmail.com> >> >Date: Monday, January 20, 2020 at 2:08 PM >> >To: Leonard Rosenthol <lrosenth@adobe.com><mailto:lrosenth@adobe.com> >> >Cc: Sandro Hawke <sandro@w3.org><mailto:sandro@w3.org>, Credible Web CG >> ><public-credibility@w3.org><mailto:public-credibility@w3.org> >> >Subject: Re: CredWeb Plans, meeting tomorrow >> > >> >I believe, though class schedules kept me from meetings last semester >> >and I am not a developer, that "signal" has a long history in >> >credibility research as a "marker" to the consumer to indicate if a >> >source is credible or not. >> > >> >So the RDF would be a bit of machine readable data as a vocabulary of >> >of traditional human readable and disagreeable signals of credibility. >> >For example you may have a currency "signal" that equates to an RDF >> >vocabulary for publication date. >> > >> >Please others correct any misconceptions I may have. >> > >> >Should be there tomorrow, first day of semester, never know what random >> >meetings pop up. >> > >> > >> >On Mon, Jan 20, 2020 at 12:32 PM Leonard Rosenthol >> ><lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote: >> >I apologize in advance if this is explained elsewhere – but I don’t >> >understand the difference you are making between a “signal” and the >> >“data format” that an API would use (or might be embedded in an asset). >> > >> >I realize that I am coming at this from the side of assets (image, >> >audio, video, documents) as opposed to web pages – but to me they are >> >one and the same. >> > >> >Thanks, >> >Leonard >> > >> >From: Sandro Hawke <sandro@w3.org<mailto:sandro@w3.org>> >> >Date: Monday, January 20, 2020 at 11:31 AM >> >To: Credible Web CG >> ><public-credibility@w3.org<mailto:public-credibility@w3.org>> >> >Subject: CredWeb Plans, meeting tomorrow >> >Resent-From: >> ><public-credibility@w3.org<mailto:public-credibility@w3.org>> >> >Resent-Date: Monday, January 20, 2020 at 11:30 AM >> > >> >Hey folks, >> > >> >It's a new year, and we've had some quiet weeks. I'm trying to settle >> >on some next steps for the group. Here's what I'm thinking: >> > >> >1. Let's not try to update the report right now. Let's just convert it >> >to a "final report", to make it properly archival, with a clear note >> >that it was written in 2018. Maybe a short name like "Credibility Tech >> >2018< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Freport%2F20181011&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628081734&sdata=bJRVKRcowxKvXgRj1ZzloMyAZPCADiNUmGNdrVI6d0Q%3D&reserved=0 >> >". >> >If there's sufficient interest in a revision or new reports that are >> >more focused later, that's fine, but I don't think it's the best use of >> >group time right now. >> > >> >2. Instead of Credibility >> >Signals< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals-beta%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628091733&sdata=NBEAC5VTQy45aASuw%2BXeNN8NA%2FXOnB5HEhVmDe8WWpE%3D&reserved=0 >> > >> >trying to include everything about signals while also highlighting the >> >good stuff, let's split it into three different resources: >> > >> >* Credibility APIs, a technical guide for how computers should talk to >> >other computers to exchange credibility data. Included data formats, >> >protocols, RESTful APIs, browser APIs, etc. Not a spec for any of >> >these, but an overview of options that are specified elsewhere. I'm >> >thinking we can publish a small draft and start to gather input. >> > >> >* A Credibility Data Exchange, a website for exploring all the signal >> >definitions and signal instance data people are willing to make public, >> >with clear attribution back to the sources and no endorsement from us. >> >I've made a few prototypes over the years (like >> >https://data.credweb.org< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata..credweb.org%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628091733&sdata=sKNv%2BvQwJDaJ3aJagJgW69%2FLHWwGETwKTTA8phSKt9o%3D&reserved=0 >> >) >> >but none I was happy with, yet. Maybe this should just be my thing, not >> >the group's; that's topic for discussion. (It might help if someone >> >wanted to fund this.) >> > >> >* Endorsed Credibility Signals. This would be a relatively small >> >document, describing 5-20 signals where we have consensus within the >> >group that they are pretty good. I'd expect it to change over time with >> >new data. The RDF schema for these signals would be published on >> >w3.org< >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw3.org%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628101733&sdata=YwAzXUPHvdS4qbwvGADSfeVgJzBKNz3SmEMM9A6bPPo%3D&reserved=0 >> >. >> >It would intentionally be kept small enough to be manageable, unlike >> >the Exchange as past "Signals" drafts. I think some of the NewsQ >> >highlight >> >signals< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals-beta%2F%23newsq-highlight&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628101733&sdata=BetmqRDU3LHcsL5Y5JMh2cjX2whQvhD84a%2FeAQmCBbY%3D&reserved=0 >> > >> >are good options here, and there are also some that are doable by hand >> >(like >> >these< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs..google.com%2Fdocument%2Fd%2F1ADJX57-xMHIIHrnzEycFrn4fUGQ63SD8hyEHqScYnTY%2Fedit&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628111727&sdata=NjJZSW8tQ2nw1h2T%2B13Wv4JYxL3jrm%2BT5l0jm2UjxAs%3D&reserved=0 >> >). >> > >> >So, agenda for tomorrow is to talk about this plan, and if there's >> >time, talk about the actual signals we might be ready to endorse. >> > >> >If you can't make it to the meeting and have thoughts on all this, >> >email could be helpful. >> > >> >Meeting, as usual: >> >21< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.timeanddate.com%2Fworldclock%2Ffixedtime.html%3Fmsg%3DCredWeb%26iso%3D20200121T13%26p1%3D43%26ah%3D1&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628111727&sdata=i81HaxWGSHLa9v6x7MiniqVzn6zMhuECkc%2BTZ94v524%3D&reserved=0 >> > >> >January 2020 1pm >> >ET< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.timeanddate.com%2Fworldclock%2Ffixedtime.html%3Fmsg%3DCredWeb%26iso%3D20200121T13%26p1%3D43%26ah%3D1&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628121723&sdata=aGOdMaXIjJRiSjCvWw5dbeQU2Ro1uWeQDh5iFKm%2BBF0%3D&reserved=0 >> >, >> >https://zoom.us/j/706868147< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzoom..us%2Fj%2F706868147&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628121723&sdata=SAnnA6Z2KBqkwA6tV32cvBEpLFOgMc9PgVCoI%2FqBUG8%3D&reserved=0 >> >, >> >agenda/record< >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs..google.com%2Fdocument%2Fd%2F1Zegy2ASbsRtkz8vNVYUXHopZjjXbZweJ5Co8TEW_8w0%2Fedit%23&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628131717&sdata=THJhQEUfsTGfNa0uxnvYBXSo0EymBCfj1HZaVi5TD5I%3D&reserved=0 >> > >> > >> > -- Sandro >> > >> > >> >-- >> >J. Gregory McVerry, PhD >> >Assistant Professor >> >Southern Connecticut State University >> >twitter: jgmac1106 >> >> > > -- > Thanks, > > Adeel Ahmad > m: (+44) 7721724715 > e: aahmad1811@gmail.com > > > > -- Thanks, Adeel Ahmad m: (+44) 7721724715 e: aahmad1811@gmail.com
Received on Tuesday, 21 January 2020 00:05:22 UTC