cofacts

Month: 2024-11

2024-11-02

cai 14:35:29
https://cofacts.tw/article/QOSe6JIBd8PNbJEMfa84
冒用名義貸款廣告,繼郵局跟財政部後,這次換勞動部被冒用,還跟上颱風時事
好新喔

但它錯字好明顯 XDDD
看起來使用者沒有傳送搭配的轉傳訊息
直接靜態圖做成影片嗎
是不是覺得 TikTok 使用者比較容易上當 (咦
cai 14:35:29
https://cofacts.tw/article/QOSe6JIBd8PNbJEMfa84
冒用名義貸款廣告,繼郵局跟財政部後,這次換勞動部被冒用,還跟上颱風時事
好新喔

但它錯字好明顯 XDDD
看起來使用者沒有傳送搭配的轉傳訊息
直接靜態圖做成影片嗎
是不是覺得 TikTok 使用者比較容易上當 (咦
👀 1
Bin Chang 20:31:42
@idforbin has joined the channel

2024-11-03

2024-11-04

mrorz 11:14:57

Today was the first day of `Hack the Disinfo 2024`, a hackathon hosted by Code for Japan. @りょーま(Yuki Kawabe) san presented `BirdXplorer` at the hackathon. Here is an [NHK](<https://www3.nhk.or.jp/news/html/20241103/k10014628211000.html>) report about the event :slightly_smiling_face: <https://g0v-tw.slack.com/archives/C01Q8THBQG6/p1730639202726989|View original message>

mrorz 11:14:57

Today was the first day of `Hack the Disinfo 2024`, a hackathon hosted by Code for Japan. @りょーま(Yuki Kawabe) san presented `BirdXplorer` at the hackathon. Here is an [NHK](<https://www3.nhk.or.jp/news/html/20241103/k10014628211000.html>) report about the event :slightly_smiling_face: <https://g0v-tw.slack.com/archives/C01Q8THBQG6/p1730639202726989|View original message>

mrorz 19:47:25
今日議程:https://g0v.hackmd.io/@cofacts/meetings/%2FPq1xffBaQW69lGyrp7JFng

HackMD

Cofacts 會議記錄 - HackMD

# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -

Follow-up on migrating to GCE: 我發現 Container-Optimized OS 沒有 package manager、不能執行非 dockerized 的 script,也沒有內建的 dcoker-compose 感覺用起來很 hardcore

我還是用普通的 debian 好了……XD
mrorz 19:47:25
今日議程:https://g0v.hackmd.io/@cofacts/meetings/%2FPq1xffBaQW69lGyrp7JFng
Follow-up on migrating to GCE: 我發現 Container-Optimized OS 沒有 package manager、不能執行非 dockerized 的 script,也沒有內建的 dcoker-compose 感覺用起來很 hardcore

我還是用普通的 debian 好了……XD

2024-11-06

cai 19:44:19
https://cofacts.tw/article/_-QE95IBd8PNbJEMM8U7 路倒假車禍告肇事逃逸這個好多人問
搭配的訊息是「警察局告知的」
Whisper 辨識得不錯耶,感謝 murmur 幫修逐字稿
先寫了一版
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB

寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知:提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動:提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞,讓讀者知道社會還是有正義在 (?)
這要感謝 MyGoPen 過往對類似案例的查核報告,替這個回應提供了非常強健的基礎 m(_ _)m
讚讚,感謝
cai 19:44:19
https://cofacts.tw/article/_-QE95IBd8PNbJEMM8U7 路倒假車禍告肇事逃逸這個好多人問
搭配的訊息是「警察局告知的」
Whisper 辨識得不錯耶,感謝 murmur 幫修逐字稿
先寫了一版
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB

寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知:提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動:提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞,讓讀者知道社會還是有正義在 (?)
這要感謝 MyGoPen 過往對類似案例的查核報告,替這個回應提供了非常強健的基礎 m(_ _)m
讚讚,感謝
cai 22:00:51
為什麼可疑訊息那邊用日期篩選器篩選今天的,最早只能看到早上八點後的?
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
因為主機是 UTC+0 XD
不知道 elasticsearch 那裡是否有啥設定可以指定時區
cai 22:00:51
為什麼可疑訊息那邊用日期篩選器篩選今天的,最早只能看到早上八點後的?
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
因為主機是 UTC+0 XD
不知道 elasticsearch 那裡是否有啥設定可以指定時區

2024-11-07

mrorz 11:43:26
Wayback Machine 存檔功能在 11/4 的時候修好了,但我們所使用的 Save Page Now API 似乎還沒有
昨天寫的回應裡的網址,今天還沒存起來,看打 API 後留存的 log,也顯示 Save Page Now API 沒有正常運作 QQ
mrorz 11:43:26
Wayback Machine 存檔功能在 11/4 的時候修好了,但我們所使用的 Save Page Now API 似乎還沒有
昨天寫的回應裡的網址,今天還沒存起來,看打 API 後留存的 log,也顯示 Save Page Now API 沒有正常運作 QQ

2024-11-08

YuJen 00:28:23
@belongbelong223 has joined the channel
mrorz 15:05:53
最近 Cofacts 有兩個與外部整合的功能:自動 spam 移除 以及 Badge 發送功能,會需要「只有特定人能存取」的 API 需求
本來自動 spam 移除的「封鎖某使用者」功能,是打算用 Google Pub/Sub 來避免開外部 API,使用 Google 帳號來管理誰能下該指令,但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式:
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API,都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來,必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取(之前對 Cloudflare Zero Trust 的研究:https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法,想說先做在新的 endpoint 上試點,等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint,好像也是個不錯的路徑。

這裡想聽聽 @acerxp511 @jhk482001 的意見~

HackMD

Cofacts reasearch &amp; design docs - HackMD

# Cofacts reasearch &amp; design docs :::info - Design docs: Implementation documents with requiremen

FETS

Home (FETS)

Build and consume REST APIs with ease. No more compromises on type safety in client-server communication. All thanks to TypeScript and OpenAPI.

也好奇 @datvithanhdat20 有沒有使用 Cloudflare Zero Trust 的經驗
有喔 我公司的staging和develop 放公網 但藏在我們Workspace的SSO後面(Saml)
我好像有看到會議記錄你想要用zero trust的ServiceKey?
badge 部分 可以來pilot這個沒問題 🙏
對呀想用的是 service token
我會偏好OpenAPI 這樣在ZeroTrust設特定endpoint需要service token會比較簡潔
Okok
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.twadmin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
> 在ZeroTrust設特定endpoint需要service token會比較簡潔
我覺得 admin endpoint 大概會有
• Badge 相關 API:新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
但因為也不是正規的api shield (要enterprise) 所以權限管理上可能要用比較奇怪的方法 把application當成access group概念 有token就可以過
是ㄉ
@jhk482001 增加 Admin API 的架構 PR 已發:
https://github.com/cofacts/rumors-api/pull/337

加一支 API 的 PR 大概會像這樣:
https://github.com/cofacts/rumors-api/pull/352

今晚開會的時候我也會講一次
晚上見~~
感謝! 🙏
今天開會時間是?
8pm 唷
歡迎來參加
👀 1 1
mrorz 15:05:53
最近 Cofacts 有兩個與外部整合的功能:自動 spam 移除 以及 Badge 發送功能,會需要「只有特定人能存取」的 API 需求
本來自動 spam 移除的「封鎖某使用者」功能,是打算用 Google Pub/Sub 來避免開外部 API,使用 Google 帳號來管理誰能下該指令,但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式:
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API,都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來,必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取(之前對 Cloudflare Zero Trust 的研究:https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法,想說先做在新的 endpoint 上試點,等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint,好像也是個不錯的路徑。

這裡想聽聽 @acerxp511 @jhk482001 的意見~
也好奇 @datvithanhdat20 有沒有使用 Cloudflare Zero Trust 的經驗
有喔 我公司的staging和develop 放公網 但藏在我們Workspace的SSO後面(Saml)
我好像有看到會議記錄你想要用zero trust的ServiceKey?
badge 部分 可以來pilot這個沒問題 🙏
對呀想用的是 service token
我會偏好OpenAPI 這樣在ZeroTrust設特定endpoint需要service token會比較簡潔
Okok
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.twadmin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
> 在ZeroTrust設特定endpoint需要service token會比較簡潔
我覺得 admin endpoint 大概會有
• Badge 相關 API:新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
但因為也不是正規的api shield (要enterprise) 所以權限管理上可能要用比較奇怪的方法 把application當成access group概念 有token就可以過
是ㄉ
@jhk482001 增加 Admin API 的架構 PR 已發:
https://github.com/cofacts/rumors-api/pull/337

加一支 API 的 PR 大概會像這樣:
https://github.com/cofacts/rumors-api/pull/352

今晚開會的時候我也會講一次
晚上見~~
感謝! 🙏
今天開會時間是?
8pm 唷
歡迎來參加
cai 20:10:13
行人優先區有幾篇誇大的影片,真的有縣市已經開始實行了嗎?
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
10/22 高雄這篇寫還沒,要等明年
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」,新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
滿奇妙的,這種影片都是在抖音
像這個
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
根本是在花蓮拍的
> 行人優先區,以行人步行為優先,*行人可於道路全寬通行*,於區內之車輛及行人應遵守道路交通安全規則之規定
所以這個地方根本就是步行區呀,像西門町那種吧
都已經是步行區了還超速
根本想殺人吧
之前在 Cofacts 也看到滿多反路權影片都是做這種形式
啊,寫還回應忘記引 @iacmai 的高雄的例子
但好懶惰

是不是該寫個修改回應之後一鍵刪除重貼的功能
想 propose 一個網站上「修改重發」回應的功能。

過去針對「編輯回應」有這些討論:https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 (天啊 2020 年)
還開了一張票想要改 API,不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下,此狀況下什麼樣的編輯算合理?
• 編輯後,針對舊文字的 feedback 怎麼辦?
因此,現在的 status quo 就是請使用者刪掉重發,這樣最單純。

我覺得比起「編輯」,其實更容易做的是把「修改重發」自動化,也就是針對現有回應做出「更動」後,系統其實不會動原有的回應,而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上(僅限作者自己加的)
• 把原有回應刪除(僅限作者自己加的)
也就是現在查核協作者可以自行操作的動作,改成一鍵完成這樣。UX 細節如下:
• 回應作者在任何自己撰寫的回應上點擊「修改重發」,會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式,可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」,前面說明文字簡述說,修改後的文案會同時套用到自己所連結的可疑訊息,也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中,由自己加的那些。
• 按下「修改重發」後,跳出彈窗列出那些會被套用的網傳訊息,以及確認按鈕。
• 按下確認後,彈窗顯示套用的進度,以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到,不用開新的欄位,只要改 rumors-site。
cai 20:10:13
行人優先區有幾篇誇大的影片,真的有縣市已經開始實行了嗎?
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
10/22 高雄這篇寫還沒,要等明年
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」,新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
滿奇妙的,這種影片都是在抖音
像這個
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
根本是在花蓮拍的
> 行人優先區,以行人步行為優先,*行人可於道路全寬通行*,於區內之車輛及行人應遵守道路交通安全規則之規定
所以這個地方根本就是步行區呀,像西門町那種吧
都已經是步行區了還超速
根本想殺人吧
之前在 Cofacts 也看到滿多反路權影片都是做這種形式
啊,寫還回應忘記引 @iacmai 的高雄的例子
但好懶惰

是不是該寫個修改回應之後一鍵刪除重貼的功能
想 propose 一個網站上「修改重發」回應的功能。

過去針對「編輯回應」有這些討論:https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 (天啊 2020 年)
還開了一張票想要改 API,不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下,此狀況下什麼樣的編輯算合理?
• 編輯後,針對舊文字的 feedback 怎麼辦?
因此,現在的 status quo 就是請使用者刪掉重發,這樣最單純。

我覺得比起「編輯」,其實更容易做的是把「修改重發」自動化,也就是針對現有回應做出「更動」後,系統其實不會動原有的回應,而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上(僅限作者自己加的)
• 把原有回應刪除(僅限作者自己加的)
也就是現在查核協作者可以自行操作的動作,改成一鍵完成這樣。UX 細節如下:
• 回應作者在任何自己撰寫的回應上點擊「修改重發」,會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式,可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」,前面說明文字簡述說,修改後的文案會同時套用到自己所連結的可疑訊息,也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中,由自己加的那些。
• 按下「修改重發」後,跳出彈窗列出那些會被套用的網傳訊息,以及確認按鈕。
• 按下確認後,彈窗顯示套用的進度,以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到,不用開新的欄位,只要改 rumors-site。

2024-11-09

mrorz 15:34:21
Cofacts 上新聞 (?
https://today.line.me/tw/v2/article/kE3EWPZ

LINE TODAY

美籍狼來台35天行蹤成謎!AIT示警 移民署急尋人:找到就驅逐出境 | 太報 | LINE TODAY

一名曾在美國犯下未成年猥褻罪的43歲美籍男子,上月2日入境來台後行蹤不明,經美國在台協會通報後,移民署列管並不予許可居留,並發出公文提醒教育部等單位,協尋行蹤。 男子名叫Levi Forrest Wallace,23年前在俄勒岡州犯下對未成年性猥褻案,被判處有期徒刑90天、緩刑2年,並未遭到通緝,但他10月2日清晨入境來台後,卻未按照登記地址居住,行蹤不明。 為避免他停留間害台灣利益,或妨害善良風俗,美國在台協會進行通報,移民署得知後,即將Wallace列管,並不予許可居留。 移民署也在10月11日向警政署、外交部、勞動部及教育部發出密件公文,請各單位協尋男子行蹤,若有查獲或知悉立即通報。 由

📰 2
mrorz 16:14:00
想 propose 一個網站上「修改重發」回應的功能。

過去針對「編輯回應」有這些討論:https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 (天啊 2020 年)
還開了一張票想要改 API,不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下,此狀況下什麼樣的編輯算合理?
• 編輯後,針對舊文字的 feedback 怎麼辦?
因此,現在的 status quo 就是請使用者刪掉重發,這樣最單純。

我覺得比起「編輯」,其實更容易做的是把「修改重發」自動化,也就是針對現有回應做出「更動」後,系統其實不會動原有的回應,而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上(僅限作者自己加的)
• 把原有回應刪除(僅限作者自己加的)
也就是現在查核協作者可以自行操作的動作,改成一鍵完成這樣。UX 細節如下:
• 回應作者在任何自己撰寫的回應上點擊「修改重發」,會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式,可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」,前面說明文字簡述說,修改後的文案會同時套用到自己所連結的可疑訊息,也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中,由自己加的那些。
• 按下「修改重發」後,跳出彈窗列出那些會被套用的網傳訊息,以及確認按鈕。
• 按下確認後,彈窗顯示套用的進度,以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到,不用開新的欄位,只要改 rumors-site。

g0v.hackmd.io

20200715 會議記錄 - HackMD

#184 UpdateReply API and replyUpdateBlocker field for reply

As discussed in <https://g0v.hackmd.io/@mrorz/cofacts-meeting-notes/%2F%40mrorz%2Fr1dQQZbmU|20200212 meeting>, we want to allow editor to edit their reply when • The reply is only used by the editor itself (the author should know the impact of the edit) • The reply has not yet received any feedback (the edit should now invalidate user's feedbacks) We plan to add 1 mutation API, and one new field to `Reply` type for this: """ The reason why the editor cannot edit """ enum ReplyUpdateBlocker { NOT_AUTHORIZED # Not logged in or not the author of reply HAS_FEEDBACK USED_BY_OTHER_EDITORS } type Reply { """ The reason why the current user cannot edit this reply. null if the current user can edit. The blockers are determined in the following order: (1) current user is the author or not (2) `positiveFeedbackCount` and `negativeFeedbackCount` are both 0 or not (3) all normal article-reply to this article are by the current author or not """ updateBlocker: ReplyUpdateBlocker } mutation { """ Updates reply text, type & reference when (1) current user is the author (2) `positiveFeedbackCount` and `negativeFeedbackCount` are both 0 (3) all normal article-reply to this article are by the current author """ UpdateReply( replyId: String! text: String type: ReplyTypeEnum reference: String waitForHyperlinks: Boolean = false ) { ""' The reply after update. `null` when update is not successful """ reply: Reply """ The reason why update fails. null when can update. """ blocker: ReplyUpdateBlocker } } "all normal article-reply to this article are by the current author" can be achieved by loading article-reply of a reply using <https://github.com/cofacts/rumors-api/blob/master/src/graphql/dataLoaders/articleRepliesByReplyIdLoaderFactory.js|`articleRepliesByReplyIdLoader`> and check each article-reply's author ID.

2024-11-11

mrorz 15:42:40
今日議程
https://g0v.hackmd.io/@cofacts/meetings/%2F_e0nyj04SoCzxdM38CzuYQ

HackMD

Cofacts 會議記錄 - HackMD

# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -

2024-11-13

mrorz 13:49:40
現在 Cofacts staging 機器上有兩個 docker-compose 跑起來的服務,不透過 nginx 而是直接走 cloudflared & Cloudflare tunnel 對應到兩個網域。
我看了一下 Cofacts 的 nginx config,其實所有東西都能用 Cloudflare 設定。這樣一來,是不是就可以把 nginx 關掉,然後通通都用 nginx 就好? XD
image.png
@datvithanhdat20 聊的之後得到的經驗筆記
• 單台的時候,這種 tunnel 接到非公開 server 的方式非常好,因為不用對外開放一個 IP 接進來,而且 deploy 到哪裡都可以直接上線(在只有一台的狀況)
• 缺點:tunnel 只能有一個,要 load balance 的話要其他處理

2024-11-14

mrorz 14:22:36
Cofacts 這裡的圖與影片是用 signed url ,不確定這樣還會不會遇到 ihower 遇到的這種事情
https://www.facebook.com/share/p/18HpYzXc1Q/
signed url 不是一樣會被計算流量嗎?如果惡意使用者故意重覆下載同一隻影片 N 百次應該就會燒到 cofacts 的荷包了?
以前 s3 還有個 bug ,就是連 404 都會計量跟收費,所以你不用知道他有什麼檔案,你只要狂去 access 他的 bucket 就會害對方帳單爆表了
mrorz 14:22:36
Cofacts 這裡的圖與影片是用 signed url ,不確定這樣還會不會遇到 ihower 遇到的這種事情
https://www.facebook.com/share/p/18HpYzXc1Q/

facebook.com

張文鈿

(被 DDoS 攻擊收到鉅額 GCP 帳單的經驗分享和求助) 網路上看到過幾次網站被 DDoS 而收到鉅額流量帳單的故事,沒想到這次的受害人是我自己 :tired_face: 大約半年前,我客戶網站上的一張放在 Google Cloud Storage (台灣 asia-east1 區) 的圖片,被 DDoS 攻擊,持續下載同一張圖片(500MiB/s,每秒 8k requests 來自歐美的七個 IP 位址)...

signed url 不是一樣會被計算流量嗎?如果惡意使用者故意重覆下載同一隻影片 N 百次應該就會燒到 cofacts 的荷包了?
以前 s3 還有個 bug ,就是連 404 都會計量跟收費,所以你不用知道他有什麼檔案,你只要狂去 access 他的 bucket 就會害對方帳單爆表了

2024-11-18

mrorz 11:32:37
@jhk482001 增加 Admin API 的架構 PR 已發:
https://github.com/cofacts/rumors-api/pull/337

加一支 API 的 PR 大概會像這樣:
https://github.com/cofacts/rumors-api/pull/352

今晚開會的時候我也會講一次
晚上見~~

#337 Implement Admin API

#352 Move blockUser to under admin API

mrorz 15:16:55
今日議程
https://g0v.hackmd.io/@cofacts/meetings/%2FGxzR0adaS8uNuaP7Vq7pfA

HackMD

Cofacts 會議記錄 - HackMD

# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -

2024-11-19

mrorz 19:19:55
感謝 @jhk482001 的 PR,昨天有 review xji
今天想到一個可能會影響 schema 的東西:如果未來有複數個 Badge manager,要怎麼區分「A 組織能發的 badge」與「B 組織能發的 badge」。

目前我的想法是

• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID,從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge,同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說,要發的 badge 是不是跟 create badge 的人是同一個
cc/ @jhk482001 @chunlin
現在 admin API 的各個 endpoint 的 `request` 都有 `userId` 可以判斷現在打 API 的人是誰~
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86

不過要注意的是,用 web 登入的人會跟 service token 視為不同人這樣
mrorz 19:19:55
感謝 @jhk482001 的 PR,昨天有 review 囉 https://github.com/cofacts/rumors-db/pull/74

#74 init for badges schema

> Design doc: <https://g0v.hackmd.io/@cofacts/rd/%2Fzx_Au6iiRN601tnMK7gx3A|https://g0v.hackmd.io/@cofacts/rd/%2Fzx_Au6iiRN601tnMK7gx3A> • Add 'badges' schema for maintain supported badges infromation • Add 'badges' to 'users' schema for maintain user obtained badge list

今天想到一個可能會影響 schema 的東西:如果未來有複數個 Badge manager,要怎麼區分「A 組織能發的 badge」與「B 組織能發的 badge」。

目前我的想法是

• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID,從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge,同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說,要發的 badge 是不是跟 create badge 的人是同一個
cc/ @jhk482001 @chunlin
現在 admin API 的各個 endpoint 的 `request` 都有 `userId` 可以判斷現在打 API 的人是誰~
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86

不過要注意的是,用 web 登入的人會跟 service token 視為不同人這樣

2024-11-21

th Chu 15:36:41
@thchu649 has joined the channel

2024-11-23

mrorz 14:54:24
@datvithanhdat20 聊的之後得到的經驗筆記
• 單台的時候,這種 tunnel 接到非公開 server 的方式非常好,因為不用對外開放一個 IP 接進來,而且 deploy 到哪裡都可以直接上線(在只有一台的狀況)
• 缺點:tunnel 只能有一個,要 load balance 的話要其他處理
❤️ 1

2024-11-24

aigaten 14:27:30
@aigaten has joined the channel
aigaten 14:36:06
歌詞:
aigaten 14:36:06
歌詞:

當收到可疑的訊息時怎麼辦

當收到可疑的訊息時找 Cofacts

疑似假新聞 假訊息 先不急

長按回傳訊息給Line bot處理



最新詐欺手法 無啥物

政治新聞的謠言 一次搞定

靠大家的團結力 打敗惡勢力

由 Cofacts 來照你
🙌 2
aigaten 14:37:00
Cofacts.mp3
@null 17:23:43

Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 09:23:34 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:24:24

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:24:09 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:25:26

Health Check Name: line-bot.cofacts.tw
Health Check ID: 43bacff73e318b0ee85fdcda1f7d8627
Time : 2024-11-24 09:25:10 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:29:26

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:29:09 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:33:49

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:33:30 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:37:15

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:37:00 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:41:07

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:40:50 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
看起來 API、網站、 LINE bot 在 11/24 17:23~18:50 不明原因倒站(served by origin 驟降)
但沒看到奇怪的攻擊 spike
@null 17:46:13

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:46:00 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 17:52:28

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:52:10 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:05:58

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:05:41 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:08:26

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:08:11 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:14:47

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:14:31 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:19:37

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:19:21 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:24:31

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:24:12 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:37:51

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:37:32 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:39:10

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:38:55 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:47:03

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:46:42 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:50:51

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:50:33 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 18:54:41

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:54:23 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 19:01:21

Health Check Name: line-bot.cofacts.tw
Health Check ID: 43bacff73e318b0ee85fdcda1f7d8627
Time : 2024-11-24 11:01:11 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred

2024-11-25

@null 03:35:07

Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 19:34:49 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 03:35:12

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 19:34:53 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 03:46:22

Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 19:46:05 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
@null 03:49:23

Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 19:49:07 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
mrorz 11:31:08
咦,原來昨天有被打
mrorz 11:31:08
咦,原來昨天有被打
mrorz 11:38:10
看起來 API、網站、 LINE bot 在 11/24 17:23~18:50 不明原因倒站(served by origin 驟降)
但沒看到奇怪的攻擊 spike
image.png
@null 14:24:26

Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-25 06:24:16 +0000 UTC
Status: Unhealthy
Failure reason: Response code mismatch error
Expected codes: [200]
Received code: 502
mrorz 14:28:45
LINE bot server 好像死翹翹好一陣子,剛才我要更新 API 時才發現
mrorz 14:28:45
LINE bot server 好像死翹翹好一陣子,剛才我要更新 API 時才發現
mrorz 14:52:31
今日議程:
https://g0v.hackmd.io/@cofacts/meetings/%2FJqg-lecyRhKtFDnbxnx_ZA

HackMD

Cofacts 會議記錄 - HackMD

# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -