Slack archive

disinfo

Month: 2019-12

2019-12-01

2019-12-02

chihao 20:01:30
@fockerlee there is a link to hangout in your google calendar 🙂
bruce 20:03:02
oh
chihao 20:05:38
@fockerlee 需要連結嗎？
bruce 20:06:34
我點了，但他顯示有錯誤，我在嘗試另外一個瀏覽器
chihao 20:06:41
OK
bruce 20:18:37
posts-10.csv

2019-12-04

pm5 11:38:31
@fockerlee @ayw255 @chihao updated db schema for FB posts & comments https://g0v.hackmd.io/lMQO37z6SbWNWo3R4-X_EA?view#%E8%B3%87%E6%96%99%E5%BA%AB%E6%9E%B6%E6%A7%8B

g0v.hackmd.io

零時檔案局技術文件 0archive Technical Spec - HackMD

主要幾個安排：FB posts & comments 都是 Article（它們都有 url），用 article_type 區分；抓下來的內容放在 FacebookPostSnapshot or FacebookCommentSnapshot；按讚數等等資料存在 reactions JSON column
看一下感覺怎麼樣？
看看
1. FacebookPostSnapshot → FbPostSnapshot 覺得讓他短一點
2. 感覺沒問題，但隱約覺得 comment 的 snapshot 好像可以綁在 article snapshot，不用獨立，不確定，想討論
comment snapshot因為有回覆哪一篇文章以及reaction等有別於article的架構, 可能獨立出來會比較好
這讓我想到我們也可以搜集大眾新聞網站下面的留言，存在類似的架構中，以及之後youtube影片下面的留言
我也覺得 comment 感覺獨立出另一個 table 比較方便。方便了解是屬於哪篇文章（post）下的留言，透過每個comment有一個 article_id，來知道屬於哪一篇article。如果comment跟article放在同一個table，感覺不容易分辨從屬關係。
我也覺得 comment snapshot 分開比較好（當然）。不過 comment snapshot 的 article_id 是這個 comment 的 id。reply_to 才是指向它回覆的那一篇。而且 FB comment 可以是回覆另一個 comment，所以 reply_to 所指向的另一個 Article 可能也是個 FB comment，要看 Article.article_type 決定
可能還是看我們蒐集資料的對象吧。假訊息主要出現在 post 還是 comment？如果 comment 也是常見傳播假訊息的管道之一，那獨立出來比較好。當然如果要 post & comment 綁在一起的，這也可以在後面的 pipeline 做。
❤️ 2
poga 16:10:05
0archive 有要爬主流新聞媒體嗎？
poga 16:10:29
因為 AILabs 這邊已經有人在爬了，看要不要合作一下
👍 1
poga 16:15:07
看到 airtable 了，看起來是有爬
嗚喔 有在爬～
目前有爬airtable上看到的那幾個site，除了蘋果新聞網（蘋果即時有，新聞網還沒）
wenyi 23:57:31
`drop_unused` merged with branch `master` — ‘init_site.py’ is dropped from repo

2019-12-05

wenyi 00:24:47
因為時常面臨找不到相關hackmd文件的窘境所以加了[NOTES.md] @ `master` 統整文件 歡迎@chihao 再補其他文件進去
🙌 1
pm5 11:24:27
@ronnywang 我們現在 db 用掉多少硬碟空間啦？
ronnywang 11:25:03
我等等中午看看，應該是還沒佔多少…如果硬碟吃到 70% 以上我會收到警告信
ronnywang 12:51:32
目前用了 20G
ronnywang 12:51:41
主要都是 ArticleSnapshot
ronnywang 12:52:51
我把 ArticleSnapshot 啟動壓縮看看
ronnywang 12:59:53
我之前 newsdiff 的 raw html 只會保留三個月，因為原始 HTML 量真的會太多，但會永久保留解出來的title 和 body 資訊
pm5 13:01:29
Snapshot 也是件麻煩事。我之前看了一下，應該有很多文章重新 snapshot 但是文章內容其實沒有改變，改變的是 sidebar 裡最新文章列表這一類的資料。
ronnywang 13:02:35
newsdiff 那邊是解出 title, body ，title, body 有變才會存新的 snapshot
ronnywang 13:02:48
但是要 title body 就要針對每個網站都要寫 parser
ronnywang 13:03:18
現在已經收集了不少 snapshot 了，可以來實驗看看 readability 解 title, body 的效果了？
pm5 13:05:30
@ayw255 這禮拜會測試看看
🙌 1
ronnywang 13:05:35
snapshot 的部份我在 newsdiff 是一個月存一個 table ，然後超過三個月就 drop table
ronnywang 13:05:47
壓縮完了，剩 5.6G
ronnywang 13:06:03
以後資料就是壓縮的資料了
2
ronnywang 13:15:20
現在的資料量也可以大概預估硬碟成長量需求了？
ronnywang 13:17:01
目前 disinfo 專案在 middle2 上面的 mysql 硬碟空間還剩 40G ，但到 80% 時我就會處理加大空間了，所以 disinfo 大概還可以多用 25G 左右是我可以先不管他的
ronnywang 13:17:32
等到用到 25G 時，我們就要討論把 disinfo 獨立一台資料庫了
pm5 13:22:31
粗估一下大約可以用到⋯⋯12 月底？
pm5 13:23:33
readability 夠好的話就可以多撐很久
ronnywang 13:24:12
snapshot 的部份也可以實驗看看戳 archive.org 讓他們那邊來存
pm5 13:24:19
不然也可以發佈兩個禮拜以上的 Article 就停止 snapshot
ronnywang 13:24:44
現在 Article 會每天都 snapshot 沒設定停止日期？
pm5 13:26:31
應該沒有。也才剛開始每天跑，一個禮拜左右
ronnywang 13:27:23
如果沒設 snapshot 日期，這樣用量不是會 O(N^2) 成長 XD
pm5 13:29:01
喔，現在一篇文章最多 snapshot 7 次
wenyi 13:29:27
我有已經寫了一版解title, body 但不是用readability，所以需要每一個site存一個css selector for main text body。readability 的部分 我有看python api (https://github.com/buriy/python-readability) 但是基本上解不出來body

GitHub

buriy/python-readability

fast python port of arc90's readability tool, updated to match latest readability.js! - buriy/python-readability

@ayw255 你遇到解不出來 body 的情況是怎麼樣？我今天試了一下，他有點 unicode 的問題，修掉以後我試了幾篇爬下來的文章，看起來可以解出還不錯的 body
@pm5 👍👍可以了，把parser更新成使用你forked的這個readability了，結果看起來不錯，明天討論一下資料要存哪裡
wenyi 13:30:19
新的code在branch `parse_article`
ronnywang 13:31:17
有的網站很討厭，會把廣告版位塞在 main text body 中，造成每次抓因為廣告不同而 main text 不同
ronnywang 13:31:23
但是其實文章沒變
ronnywang 13:40:09
另外之前 table name 好像是用第一個字大寫，像是 Article ，不過習慣上好像 table name 都會用小寫
像是 ArticleSnapshot 在 table name 會用 article_snapshot ，在程式的 class name 才用 ArticleSnapshot
😆 1
chihao 14:15:09
今晚 8pm-9pm 有 disinfo community hangout 哦（好像什麼假訊息製造的社群）忘了事先在 #general 上宣傳了 😆
chihao 14:15:22
來準備一下等一下發訊息
chihao 14:16:03
視訊工具的話，如果選 jitsi 不知道進入門檻會不會太高？
hcchien 14:47:23
@hcchien407 has joined the channel
deeper 15:14:00
@cstsai has joined the channel
yukai 17:13:25
@yukai has joined the channel
ael 17:39:48
@aelcenganda has joined the channel
kiwi 19:10:52
@auroral.13king518 has joined the channel
loooffy 19:42:45
@loooffy has joined the channel
cwkung2016 20:08:02
@cwkung2016 has joined the channel

2019-12-06

Anping 02:19:04
@zhaoanping has joined the channel

2019-12-07

fly 15:41:28
> 與真人用戶不同，假帳號可能由一個人或一個集團控制，他們通常一起行動，一部分人負責發出宣傳訊息或者假消息，其他人贊同然後轉發，合成一個消息動向，吸引真人用戶加入網絡討論。
> BotSlayer 的系統收集所有符合這些條件的推文，然後儲存到一個數據庫，以供日後偵查。此外，它還連結到 Hoaxy 系統，可以得知 Twitter 帳號在一段時間內的互動情況，辨識最有影響力以及最有可能散播假消息的帳號。
<https://www.cup.com.hk/2019/12/03/botslayer-the-system-aims-to-find-and-kill-internet-bots/>

<https://osome.iuni.iu.edu/tools/botslayer/>

*CUP

如何挖出並殲滅假帳號 - *CUP

由電腦系統操縱的假帳號（bot）干擾言論自由、帶動政治宣傳風向的普遍現象，日益引起美國互聯網研究員的關注，美國印第安納大學兩位博士生研發出 Botslayer 軟件系統，專門為媒體記者和公眾討論區服務，幫助他們找出網絡假帳號大軍，清理門戶。

1

2019-12-08

LoraC 17:36:18
@shadowcrow594 has joined the channel

2019-12-09

chihao 19:50:23
@pm5 @ayw255 @fockerlee 再十分鐘 dev meeting 😄
kiang 21:40:04
@kiang has joined the channel

2019-12-10

gugod 23:06:53
https://metacpan.org/source/GUGOD/NewsExtractor-v0.0.3/lib/NewsExtractor/Extractor.pm#L21

我開始漸漸將 CSS 規則加入自己做的爬蟲 NewsExtractor.pm 了
打算先依網址區別，一個站做一組 CSS 規則。
用來對付那些無法以 Readibility 演算法處理的網站。
gugod 23:08:11
雖然剛剛只做了一組規則 😛 不過… 歡迎拿去用。(或送 PR 來)
2
gugod 23:09:48
https://github.com/g0v/people-in-news/blob/master/etc/news-sites.txt

目標是把在這裡的列出的新聞來源都能對應完畢 (好多 orz)

GitHub

g0v/people-in-news

公眾人物新聞的追蹤. Contribute to g0v/people-in-news development by creating an account on GitHub.

2019-12-11

pei 15:11:11
@stronghead.wu has joined the channel
pofeng 16:34:39
@pofeng has joined the channel
冠陞 17:12:48
@can has joined the channel
gugod 20:11:33
剛發現 chinatimes.com 的新聞網頁 DOM 中有 JSON-LD 資料可以利用
長得像這樣

``` <script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"articleSection": "生活",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.chinatimes.com/realtimenews/20191211004429-260405"
},
"headline": "作曲、繪畫難不倒 AI也能玩藝術",
"image": {"@type": "ImageObject","url":"https://images.chinatimes.com/newsphoto/2019-12-11/900/20191211004430.jpg","height":369,"width":656},"author": {"@type": "Person","name": "王寶兒" }, "url":"https://www.chinatimes.com/realtimenews/20191211004429-260405",
"description":"王寶兒／新北報導紀錄片《AI新紀元》揭示，預計203...
....
</script>```
而且 “description” 欄基本上就是新聞全文了….
自由時報也有。但 description 不是全文，並且 “author.name” 不是記者名，而是「自由時報」四個字

view-source:https://news.ltn.com.tw/news/society/breakingnews/3006341
嗯。看來就是 Slack 抓到的這一段字。（或許 Slack 就 是抓 `script[type="application/ld+json"]` )
喔，也有可能是 og:title + og:description
ctwant.com 也有，果然是同一家的
其實 Nooho 也有。從這裡抓 datePublished 可能是個好辦法
㊙️ 3
tmonk 20:35:40
@felixtypingmonkey has joined the channel

2019-12-12

gugod 16:14:11
https://docs.rsshub.app/traditional-media.html

好像可以跟這個專案交關一下 😛

docs.rsshub.app

传统媒体 | RSSHub

:cake: 万物皆可 RSS

作者 github id 是 `DIYgod` 😆
2
chihao 19:26:19
萬物傑克 RSS
chihao 19:26:26
@gugod ++++
chihao 19:28:48
等一下 8:00 就是 disinfoRG community hangout 囉，歡迎來玩！
網址：https://meet.jit.si/disinfo
共筆：https://g0v.hackmd.io/BChGrPg-TkWsvks2ey5q6A

meet.jit.si

Jitsi Meet

Join a WebRTC video conference powered by the Jitsi Videobridge

g0v.hackmd.io

disinfoRG meeting notes - HackMD

reason1130 23:59:47
@reason1130 has joined the channel

2019-12-13

pm5 12:14:02
上次 @fockerlee 講到可以用 airtable 來釋出一些資料。因為 airtable API 確實蠻好用的，我想可以用釋出部份資料的方式來解決資料量的問題。這個「部份資料」的篩選可以想一下對資料分析比較有意義的方式，像是針對一個新聞事件，釋出事件後 3 天內所有網站的發佈文章資料，或是釋出所有內文有特定關鍵詞的發文資料
或許可以試著算出與指定關鍵詞相關的其他關鍵詞
作個詞與詞之間的 pagerank table 之類的
❤️ 3 1

2019-12-14

gugod 18:54:15
來丟個問題：先不論事實成份多少與立場問題，各位覺得一篇新聞的「製作品質」，該怎麼來定義？ (thread)
我在寫爬蟲 ( NewsExtractor / people-in-news ) 時一面也在想這個問題。但只想得一些隨意的評量標準。
比方說：

1. 要有「標題」「日期時間」「記者名」「內文」這四欄位。
2. 內文 與 標題 所闡述的主題應相符 （否則就是「名不符實」，偏向 disinfomation 那一側的寫作法）
3. 內文所闡述事件的時間不應與目前時間相距太遠。（舊聞）
4. 內文與標題不應出現「網友」兩字

粗略觀察起來，大致上用了「網友」兩字的新聞內文都是帶一點虛假成分。或是「網友表示〇〇〇」為文中主要論點的支持論點，但去搜尋又找不到網友是在哪裡表示〇〇〇。變成是一種「虛的參考來源」。
（不過是有點看狀況。如果「網友」本身是文章主題可能就不算）
感覺要參考這本書
裡面也有在探討不實訊息：
限定在新聞的話，可能寫作格式？前 3 個段落的長度、句數、全文裡驚嘆號或某些特殊符號的數量
我覺得製作品質是一個技術性的東西，與真實不真實、有沒有操控的意圖，不大有關係。可以有製作精良的假消息，也可以有透露事實的流言。另外製作品質本身也沒有好或不好的區別，只有適不適合，或者說適合在哪種消息管道裡流通的差別。
但是到了「新聞」這種特別的傳播體系裡的內容製作品質，就有一些好與不好的判準了。
> 我覺得製作品質是一個技術性的東西，與真實不真實、有沒有操控的意圖，不大有關係。
我個人的直覺與此稍有不同。 「不精良」的東西，製做過程通常不耗時力。而「事實成分低少」的新聞文字，製做起來也比較不秏時力[*]。

做事實查核很費力，但如果有方法能很快速而大致上篩選、區別出「精質」與「粗糙」的新聞文字的話，或許一定程度上可以將此方法做為轉守為攻的工具。

[*]: 這一點是我個人假設
一定程度上就像食品被要求以特定包裝、成份表，以及生產履歷那樣。
「文章配圖」這點不錯：

> 假若一篇長篇文章配圖來源不明（可能是盜圖）或是花一點小錢買來的圖庫內容（很容易辨識），這篇文章多半有問題；
至少能以圖片搜尋引擎去快速而簡單地檢查
大家覺得像這樣的新聞 品質上有什麼問題呢? https://tw.appledaily.com/new/realtime/20131022/278921/
除了「內文所述這件事情跟我基本上無關」、可能就是它很短，資訊量也很少。推測，大概也不需要多少時間與心力就可以被製作出來。

記者名有標示還可以。

再我對「今早」這個時間表示格式有點意見，我認為內文的時間也要盡可能精確。如果只是把微博發文拷貝下來，至少可以把原文的發文時間一起標出。
「網友」有時候還會被進一步縮寫成「網」，真的很煩。
🙌 2

2019-12-15

pm5