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 :slightly_smiling_face:
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

pm5 11:42:43
主要幾個安排:FB posts & comments 都是 Article(它們都有 url),用 article_type 區分;抓下來的內容放在 FacebookPostSnapshot or FacebookCommentSnapshot;按讚數等等資料存在 reactions JSON column
pm5 11:43:05
看一下感覺怎麼樣?
chihao 11:54:22
看看
chihao 11:59:39
1. FacebookPostSnapshot → FbPostSnapshot 覺得讓他短一點
2. 感覺沒問題,但隱約覺得 comment 的 snapshot 好像可以綁在 article snapshot,不用獨立,不確定,想討論
wenyi 00:14:33
comment snapshot因為有回覆哪一篇文章以及reaction等有別於article的架構, 可能獨立出來會比較好
這讓我想到我們也可以搜集大眾新聞網站下面的留言,存在類似的架構中,以及之後youtube影片下面的留言
bruce 02:12:20
我也覺得 comment 感覺獨立出另一個 table 比較方便。方便了解是屬於哪篇文章(post)下的留言,透過每個comment有一個 article_id,來知道屬於哪一篇article。如果comment跟article放在同一個table,感覺不容易分辨從屬關係。
pm5 09:08:15
我也覺得 comment snapshot 分開比較好(當然)。不過 comment snapshot 的 article_id 是這個 comment 的 id。reply_to 才是指向它回覆的那一篇。而且 FB comment 可以是回覆另一個 comment,所以 reply_to 所指向的另一個 Article 可能也是個 FB comment,要看 Article.article_type 決定
pm5 11:17:18
可能還是看我們蒐集資料的對象吧。假訊息主要出現在 post 還是 comment?如果 comment 也是常見傳播假訊息的管道之一,那獨立出來比較好。當然如果要 post & comment 綁在一起的,這也可以在後面的 pipeline 做。
poga 16:10:05
0archive 有要爬主流新聞媒體嗎?
poga 16:10:29
因為 AILabs 這邊已經有人在爬了,看要不要合作一下
poga 16:15:07
看到 airtable 了,看起來是有爬
wenyi 23:58:22
嗚喔 有在爬~
wenyi 23:59:14
目前有爬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 再補其他文件進去
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 這禮拜會測試看看
ronnywang 13:05:35
snapshot 的部份我在 newsdiff 是一個月存一個 table ,然後超過三個月就 drop table
ronnywang 13:05:47
壓縮完了,剩 5.6G
ronnywang 13:06:03
以後資料就是壓縮的資料了
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 的部份也可以實驗看看戳 http://archive.org|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

pm5 22:25:17
@ayw255 你遇到解不出來 body 的情況是怎麼樣?我今天試了一下,他有點 unicode 的問題,修掉以後我試了幾篇爬下來的文章,看起來可以解出還不錯的 body
wenyi 08:01:15
@pm5 :+1::+1:可以了,把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
chihao 14:15:09
今晚 8pm-9pm 有 disinfo community hangout 哦(好像什麼假訊息製造的社群)忘了事先在 #general 上宣傳了 :laughing:
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 軟件系統,專門為媒體記者和公眾討論區服務,幫助他們找出網絡假帳號大軍,清理門戶。

2019-12-08

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

2019-12-09

chihao 19:50:23
@pm5 @ayw255 @fockerlee 再十分鐘 dev meeting :smile:
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 規則加入自己做的爬蟲 http://NewsExtractor.pm|NewsExtractor.pm
打算先依網址區別,一個站做一組 CSS 規則。
用來對付那些無法以 Readibility 演算法處理的網站。
gugod 23:08:11
雖然剛剛只做了一組規則 :stuck_out_tongue: 不過… 歡迎拿去用。(或送 PR 來)
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
can 17:12:48
@can has joined the channel
gugod 20:11:33
剛發現 http://chinatimes.com|chinatimes.com 的新聞網頁 DOM 中有 JSON-LD 資料可以利用
gugod 20:12:19
長得像這樣

``` <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>```
gugod 20:12:38
而且 “description” 欄基本上就是新聞全文了….
gugod 08:20:30
自由時報也有。但 description 不是全文,並且 “author.name” 不是記者名,而是「自由時報」四個字

view-source:https://news.ltn.com.tw/news/society/breakingnews/3006341
gugod 08:21:50
嗯。看來就是 Slack 抓到的這一段字。(或許 Slack 就 是抓 `script[type="application/ld+json"]` )
gugod 08:22:21
喔,也有可能是 og:title + og:description
pm5 08:37:47
http://ctwant.com|ctwant.com 也有,果然是同一家的
pm5 08:42:11
其實 Nooho 也有。從這裡抓 datePublished 可能是個好辦法
tmonk 20:35:40
@felixtypingmonkey has joined the channel

2019-12-12

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

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

docs.rsshub.app

传统媒体 | RSSHub

:cake: 万物皆可 RSS

chihao 19:40:31
作者 github id 是 `DIYgod` :laughing:
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 天內所有網站的發佈文章資料,或是釋出所有內文有特定關鍵詞的發文資料
gugod 12:36:46
或許可以試著算出與指定關鍵詞相關的其他關鍵詞
gugod 12:37:52
作個詞與詞之間的 pagerank table 之類的

2019-12-14

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

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

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

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

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

> 假若一篇長篇文章配圖來源不明(可能是盜圖)或是花一點小錢買來的圖庫內容(很容易辨識),這篇文章多半有問題;
gugod 12:21:03
至少能以圖片搜尋引擎去快速而簡單地檢查
gugod 22:36:52
除了「內文所述這件事情跟我基本上無關」、可能就是它很短,資訊量也很少。推測,大概也不需要多少時間與心力就可以被製作出來。

記者名有標示還可以。

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

2019-12-15

pm5 09:56:27
@ayw255 how is it going? After some thoughts I believe it'd be better if we put parsers in the same git repo, at least for the current stage of the project.
pm5 09:59:57
We can probably add a `ArticleParser` dir under project root for the parsers. They can have their own db settings and migrations there. We can also just rename `codes` dir to `NewsScrapper` to better reflect its functions, and move news db settings and migrations to some subdir.
pm5 10:04:55
This "semi-gigantic repo" project structure would make it easier to deploy to middle2.
wenyi 10:13:31
@pm5 parser is almost done now in branch ‘parser’ in codes/parser.py. waiting for @chihao for new db and/or elasticsearch for it to be fully functional.
wenyi 10:13:51
Umm the code structure sounds fine to me
wenyi 10:15:42
But, I wonder why parser needs a sub dir, why don’t we just put env settings in the same .env folder and maybe named them as, for example, ‘PARSER_DB_URL’
wenyi 10:16:24
Since parser only has need 1 code? Unless we are looking to develop more codes for post-processing the parsed results (and decided to put them in the same repo)
pm5 10:29:12
oh we can use `PARSER_DB_URL` and shared `.env` and Python dependencies. It's just that I am anticipating more post-processing code for FB, Twitter, maybe YouTube etc.
pm5 10:41:11
chihao 17:03:46
@ayw255 sorry I’m lagging behind on the middle2 front. Will pick that up!
pm5