Slack archive

cofacts

Month: 2019-03

2019-03-05

Relax 13:23:40
@healthya2776 has joined the channel

2019-03-06

2019-03-09

mrorz 10:29:00
今天 Cofacts 真的假的、我愛家我解惑的協作資訊在這裡唷：
https://beta.hackfoldr.org/cofacts/
bil 12:57:06
@jcjiang42
https://g0v.hackmd.io/c/B1iHBvVPQ/%2FmrsydmcAQkGasHYtWTLsGQ
https://g0v.hackmd.io/c/B1iHBvVPQ/%2F6j4BIcRSSdm7s-h9qS9_dg

HackMD

《我愛家我解惑》資料庫 - HackMD

這裡蒐集了近期網路上的反平權、反性平訊息，分析傳播熱度、拆解為爭議點，並且嘗試做出回應。

HackMD

《我愛家我解惑》資料庫 - HackMD

這裡蒐集了近期網路上的反平權、反性平訊息，分析傳播熱度、拆解為爭議點，並且嘗試做出回應。

leannechen 13:18:57
@lianchennnn has joined the channel
hyhsu 13:31:11
@hyhsu has joined the channel
CRW 13:59:33
@u01120033 has joined the channel
jc 15:16:56
https://www.patheos.com/blogs/crossexamined/2018/11/20-arguments-against-same-sex-marriage-rebutted/

http://gayagenda.net/marriage.html

Cross Examined

20 Arguments Against Same-Sex Marriage, Rebutted

Same-sex marriage is in place in America, but anti-gay arguments remain a siren song to many conservatives. Let’s critique their arguments.

gayagenda.net

The Canonical List of Rebuttals to Anti-gay Arguments Against Gay Marriage Rights

The canonical list of rebuttals to the tired and irrational arguments commonly made against gays securing the right to marry their partners by the anti-gay hate industry. Complete with convenient anchors for easy linking.

mrorz 18:38:39
I’m curious about the domain name “gay http://agenda.net|agenda.net”. It’s said that “gay agenda” is actually a term invented by anti-gay conspiracy theorists. (the first time i read this term is here: https://www.thenewslens.com/article/65203 )

Is the website owner just being sarcastic on the term?
jc 15:32:06
https://www.tandfonline.com/doi/abs/10.1080/14681811.2015.1042573 study on increased perception of safety and lowered bullying when LGBTQ issues are included in education
mrorz 18:41:36
added to https://g0v.hackmd.io/c/B1iHBvVPQ/%2FFySWZdlKTZyrLnHaL8a7KQ. This info come in handy just in time! anti-gay parent groups are protesting tomorrow.

2019-03-11

2019-03-12

shesee 10:58:08
@shesee has joined the channel

2019-03-13

2019-03-14

shesee 09:59:57
美玉姨是可以算群組的，只要收集一下群組 id 至少曾經有在講話的群組我會知道有哪些 XD <- 只是這樣就超過了不儲存任何資料的聲明了
也分享一下另外一種可以預測可能是假新聞的論文（非常的中國，就是計算那些偏見媒體和偏見轉傳者的分數來當作文章的偏見…假指數）https://www.public.asu.edu/~skai2/files/wsdm_2019_fake_news.pdf
mrorz 11:16:26
其實西方也搞這一套呢 orz

看網域來源的有 Adblock 的 https://trusted-news.com/ ，學術研究可以參考這裡：

[2018-3-3] Facebook的假新聞問題……已經病入膏肓／Frederic Filloux
https://medium.com/@smokingtuna/facebook-reliability-problem-51456eafbfa3

他們的 methodology 是看一個網域過去的 fact check 紀錄，來計算「某個網域」的可信度分數。也就是說，他們論文裡面嫌那種單篇單篇查核速度太慢，但他們的看網域這件事情其實還是仰賴過去累積的內容查核這樣。

研究謊言在 social media connection 的傳播模式這件事情，過去也有上過 nature
https://www.nature.com/articles/d41586-018-02934-x

用一則訊息在社群網站上的傳播模式，來偵測這個訊息是不是很有可能是假的，這件事情其實好像滿有趣的——只要它不要涉及「懲罰轉傳的人」，而只是標出「這則傳播模式跟過去的謠言很像」、讓有需要的人去看看是否需要另外澄清，那我就覺得是個不錯的系統。

（當然在中國的話應該是另一種玩法囧）
shesee 11:18:12
> 「懲罰轉傳的人」
對，這才是真的中國風的部分哈哈哈哈
mrorz 11:19:36
https://arxiv.org/abs/1810.11663 日本好像單純用 NLP 硬幹，似乎沒考量到傳播的模型。但用來偵測、減少人工判讀，是有一些幫助的
mrorz 11:19:51
（ 日本 work 的介紹：https://www.feja.org.tw/44289 ）
mrorz 11:07:25
嗯嗯開會的時候就有說如果記了的話有隱私疑慮，所以 @bil 的意思是指計算直接傳給美玉姨的部分～
shesee 11:17:00
也可以不用加特別的 endpoint, 就我多埋一點特殊的 headers 之類的會比較輕鬆（嗎）
mrorz 11:18:16
我自己本身是比較希望自己的 analytics 自己埋，互相分享～

例如美玉姨這裏自己有個 google analytics，然後 cofacts 與美玉咦的 google analytics 上互相加對方為協作者，這樣就能在 google data studio
mrorz 11:18:54
一起繪製
shesee 11:19:11
我其實有寫了一個埋 analytics 的 PR, 但是因為隱私的問題遲遲沒有 merge
shesee 11:19:22
不過不是 google analytics 好像是 chatbase 之類的
shesee 11:20:08
因為美玉姨不真的有網站，也沒有 db
mrorz 11:20:32
其實我覺得如果是個人私訊給美玉姨的話應該還好～
mrorz 11:22:25
不過如果美玉姨在群組裡面回傳了內容，那如果紀錄「這個文章在這個時間點裡、於某個群組裡面被搜到了」這件事情，到底會不會有隱私疑慮，其實我也不太清楚
mrorz 11:22:38
我覺得因為是 cofacts content，理論上應該還好？
shesee 11:24:40
我也是覺得還好所以寫了，但是又覺得這樣有點那個所以還沒有下定決心 merge 進去（主要是還沒有想好怎麼做）
不過我認為那個評分機制有助於減少人工判讀 <- 或是 highlight 哪些應該優先人工判讀
mrorz 11:25:11
嗯嗯，其實主要是希望知道「這則訊息有在被查詢」這樣
mrorz 11:25:30
Cofacts 的困境是分不出哪些訊息是「某人一時興起，拿一則訊息來問」
bil 11:25:37
如果有隱私疑慮的話，可能還是先不做比較好。想以盡量嚴格的標準避免carol收到隱私疑慮的質疑。
mrorz 11:25:37
還是「真的有在被轉傳」
mrorz 11:26:32
對於 Cofacts 與美玉姨來說，要分辨這兩者的方式是得知「到底一則訊息有沒有被傳進來 2 次以上」
shesee 11:27:16
我先要去忙一下，晚一點再進來回覆 :wave:
mrorz 11:28:27
以 cofacts 為例，我們在 LINE 使用者選擇某個查詢結果的時候，會傳送一個 google analytics 的 article select event，以及被選擇的 article id

所以可以畫出像是這樣的圖，一看就知道這則訊息很常被轉傳（然後 cofacts 各個使用者很常來問）：
https://datastudio.google.com/reporting/18J8jZYumsoaCPBk9bdRd97GKvi_W5v-r/page/NrUQ?config=%7B%22df7%22:%22include%25EE%2580%25800%25EE%2580%2580IN%25EE%2580%25805479897696031-rumor%22%7D

Google Data Studio

Cofacts analytics

Google Data Studio turns your data into informative dashboards and reports that are easy to read, easy to share, and fully customizable.

mrorz 11:29:59
要畫出這樣的圖，不用紀錄使用者實際上傳了什麼文字，而是紀錄哪篇（已經被公開上網了的）cofacts 文章被選擇了，這樣應該可以把隱私疑慮降到最少
mrorz 11:31:01
當然這麼做的 trade-off 就會是，如果一則訊息在 cofacts 裡面還沒建檔（zero-day rumor?）是無法偵測到的

還是得仰賴 Cofacts 使用者熱心回報訊息～
shesee 12:48:00
我在 chatbase 裡面做差不多的事情，但是打算看看使用者的行為所以裡面會把 line user id 跟 article_id mapping 起來
shesee 12:48:16
然後預測哪一些使用者傾向於轉傳可能的假訊息
shesee 12:48:55
這樣等到有新回報出現的時候可以 highlight 出可能是高度被轉傳的假訊息的可能性高低
shesee 12:49:29
但是因為這就覺得微有疑慮，還沒有心理準備好 merge 它 :sweat_smile:
mrorz 15:42:51
喔喔喔這確實就有點像前面那篇論文 XD”
mrorz 15:44:06
Cofacts 也有紀錄哪個 userId 轉傳了訊息給 Cofacts，但這是為了避免訊息被轉傳兩次，Cofacts user 應該都不是傳遞謠言之人。而且 Cofacts user 都是有意識地私訊 Cofacts，所以比較沒有疑慮。
mrorz 18:10:24
@lucien 關於 ui lib 我覺得我跟 material-ui 越來越熟了，就用它吧 XDDD

CSS 方面我最近滿喜歡 emotion
https://material-ui.com/guides/interoperability/#emotion

material-ui.com

Style Library Interoperability - Material-UI

While it is simple to use the JSS based styling solution provided by Material-UI to style your application, it is possible to use any styling solution you prefer, from plain CSS to any number of CSS-in-JS libraries.

lucien 19:16:12
不換一個嗎哈哈，覺得很無趣
mrorz 10:50:47
對 material-ui 厭煩嗎
有比 bootstrap 厭煩嗎
lucien 18:57:06
只好來魔改他惹
mrorz 18:59:38
就設計的時候用 material component 就好了吧 XD

2019-03-15

chyuaner 21:45:58
@chyuaner has joined the channel

2019-03-20

2019-03-23

mrorz 14:57:44
http://mol.mcu.edu.tw/%E9%98%B2%E6%AD%A2%E5%81%87%E8%A8%8A%E6%81%AF%E8%BD%89%E5%82%B3-%E5%B9%B4%E9%95%B7%E8%80%85%E5%AD%B8%E7%BF%92%E6%9F%A5%E8%AD%89/

銘報即時新聞

防止假訊息轉傳 年長者學習查證 - 銘報即時新聞

「臺北市立圖書館樂齡中心」邀請台灣媒體觀察教育基金會擔任2019年春季巡迴講座講師，15日於大同分館舉行「假新聞大揭密」講座，帶領近30位年長者學習辨別訊息的真假，並透過互動教學的方式，實際操作社群軟體LINE的查證工具。

2019-03-24

jimhorng 14:08:08
@jimhorng has joined the channel
jimhorng 14:15:03
各位大大，想請教用LINE帳號查詢假訊息後出現的相似度分數是用什麼技術判斷的（e.g. elasticsearch）？

剛好我最近在研究NLP相關，想知道對於被部分改寫的假訊息 能辨識的程度

感謝 ：）
Screenshot_20190324-141255~2.png
mrorz 15:29:36
LINE bot 回傳的部分分 2 個 pass
1. retrieval (決定要顯示哪些)
2. 以及相似度評分 (0%~100%)

前面 retrieval 是 elasticsearch 決定的，只有被 elasticsearch 找到的訊息，會列出來，然後由 LINE bot 這裡計算相似度
mrorz 15:32:58
具體來說，elasticsearch retrieval 這裡使用的是 `more_like_this` query
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html

他會先從 query 的句子（`like`）挑出幾個具有分辨力的 term（預設 25 個，就是 `max_query_terms` 參數的預設值），然後去查哪些 document 有 match 這個 term
mrorz 15:34:59
然後 LINE bot 這裡設定 retrieval「有中」的門檻（也就是 `minimim_should_match` 參數）預設是：
mrorz 15:35:19
若 document 在 10 個 term 以內，那必須全中；否則，需要 match 70% 的 term （也就是 document 裡必須要有 25 * 70% ~= 18 個具有分辨力的 term）
mrorz 15:36:44
這是個滿高的門檻，確實可以討論。
mrorz 15:37:18
elasticsearch 這裏的斷詞是，中文為 bigram，英文就是 by word ～
mrorz 15:41:59
再來，有關 LINE bot 的相似度評分

雖然 elasticsearch 其實會給一個分數，但那個分數其實是各個 matching item 的總分，是從各個 matching term 的 tf-idf 等數值算出來的，沒有一個「滿分」，所以無法直接轉換為百分比。

使用者比較能理解「百分比」分數，所以變成是我們在 LINE bot 端來把 elasticsearch 列出的 item，跟使用者轉傳的實際訊息相比，再計算一個相似度分數。

具體來說，計算分數時我們用的是 string-similarity 這個套件，他背後用的是 Dice’s Coefficient。
https://www.npmjs.com/package/string-similarity
mrorz 15:42:10
（我也不知道那是啥，但感覺很厲害）
mrorz 15:43:20
@jimhorng 以上就是 retrieval 與相似度的定義～
jimhorng 16:59:50
感謝大大，我來好好消化一下...XD
jimhorng 14:19:42
另外發現opendata中有一些格式問題，先開成issue。
https://github.com/cofacts/opendata/issues/13

請教用來產生這些csv的script放哪邊？或許我可幫忙看一下 ：）

GitHub

some fields are not properly double-quoted in csv · Issue #13 · cofacts/opendata

e.g. in <https://github.com/cofacts/opendata/blob/master/data/articles.csv.zip> text field not double-quoted but contain newline char was: AV6yLoz4yCdS-nWhuglc,LINE,dd6282f4a3d6da926bd62131faf6886284...

mrorz 15:45:09
mrorz 15:59:05
我回在票裡了
感謝感謝
jimhorng 16:55:54
感謝大大~