#infras
2021-05-02
tofus
09:56:43
@terry.f.wang has joined the channel
2021-05-16
patcon
06:06:08
and i recall au manages g0v.link domain, yes?
patcon
06:09:48
am thinking on how helpful it’s been to run a lightweight shortener in some other spaces, a bit like this: https://link.hypha.coop/foo
It’s editable via CSV in github (or a GSheet, depending on desired level of accessibility)
https://link.hypha.coop/shortlinks
It’s editable via CSV in github (or a GSheet, depending on desired level of accessibility)
https://link.hypha.coop/shortlinks
GitHub
Contribute to hyphacoop/configurations development by creating an account on GitHub.![]()
patcon
06:09:50
It’s nice because ppl just need to remember the “slug” to find all the important places/docs: g0v.link/foo. Would anything like this be helpful? (I tend to run it on rebrandly to start, so it’s minimal self-hosted infra to maintain)
chihao
07:39:10
@patcon don’t know if there’s already one but could be great to have one as long as it’s open source and collaborative?
patcon
09:21:25
Thanks @chihao! I'm working on getting one going for link.g0v.network (where a polis-related initiative is being hosted), so I can demo that and see if it looks good enough to reproduce for g0v.link :) :tada:
- 🙌1
2021-05-17
irvin
00:05:11
@irvin has left the channel
2021-05-19
2021-05-20
Guo-Jim
01:17:58
@guo-jim has left the channel
Guo-Jim
07:49:57
@guo-jim has joined the channel
游士鋒
12:34:28
@sfyou614 has joined the channel
2021-05-22
caasi
15:54:52
HackMD
# g0v IRC 現況 現在 g0v 主要的 IRC 頻道是 #<http://g0v.tw|g0v.tw> ,位在 freenode 這個 IRC 網路上。 ## 待處理事項 ### 是否取回 freenode 上的 IR
- 🙌1
- 👍1
1
2021-05-24
caasi
18:22:28
• 在 freenode 管理員 t-42 的協助下,拿到 IRC 頻道的 founder 權限
• 之後打算也把 founder 權限設給 gugod, kcwu 和 yhsiang (不要的話講一聲
• freenode 也有 channel grouping 機制,一樣要聯絡管理員來申請 https://freenode.net/groupreg
• 之後打算也把 founder 權限設給 gugod, kcwu 和 yhsiang (不要的話講一聲
• freenode 也有 channel grouping 機制,一樣要聯絡管理員來申請 https://freenode.net/groupreg
freenode.net
<http://freenode.net|freenode.net> - Supporting Free and Open Source Software Communities since 1998
kcwu
18:24:52
(小聲說, 我在考慮放棄使用 g0v irc) 一方面是因為有時兩邊的訊息無法很好的轉換傳遞, 一方面是 irc 只有 general channel
superbil
20:32:20
若是用 grouping 的話,可以開系列 `g0v-infras` 這樣呀~ 就不會只有 general
caasi
22:50:42
若大家決定放棄 IRC ,我也 OK ,討論一下讓子彈飛一會兒~
2021-05-26
gugod
22:51:58
用 IRC 或不用我是沒什麼意見或堅持。
我甚至覺得不必所有個討論頻道都開在這個 Slack workspace 內。如有有專案討論要開在 IRC 或 Matrix 也不錯 (雖然會讓一些事情比較難辦一些) 。基本上維持公開,有紀錄 (logbot)可查、CoC 與目標和 g0v 的有相容就好。
我甚至覺得不必所有個討論頻道都開在這個 Slack workspace 內。如有有專案討論要開在 IRC 或 Matrix 也不錯 (雖然會讓一些事情比較難辦一些) 。基本上維持公開,有紀錄 (logbot)可查、CoC 與目標和 g0v 的有相容就好。
3
4
2021-05-27
gugod
09:14:03
> CoC 與目標和 g0v 的有相容
我的原意是:“CoC 相容” 且 “目標相容”
不過「目標相容」好像十分廣泛。
我的原意是:“CoC 相容” 且 “目標相容”
不過「目標相容」好像十分廣泛。
chewei 哲瑋
09:55:04
Slack 目前開始有 Admins 與治理機制
可能這類 bridged 的服務,也要考慮,我建議是先有 Admins 與機制,並說明 bridged 服務有什麼風險,特別是成員資料送出去這樣的狀況
舉例來說 zulipchat 在剛才之前,直接是把 slack 這邊的暱稱與註冊 email 全部公開連 guest 都可以查看,一來是 slack 也不允許的事情,反而在 bridged 的服務卻被允許,也無人知曉監管,然後 想找 Admins 卻不曉得是誰,現在正在釐清這個匯出且公開 成員暱稱-註冊email 的操作發生時間點(可能是三年前)與操作者 #bridge
可能這類 bridged 的服務,也要考慮,我建議是先有 Admins 與機制,並說明 bridged 服務有什麼風險,特別是成員資料送出去這樣的狀況
舉例來說 zulipchat 在剛才之前,直接是把 slack 這邊的暱稱與註冊 email 全部公開連 guest 都可以查看,一來是 slack 也不允許的事情,反而在 bridged 的服務卻被允許,也無人知曉監管,然後 想找 Admins 卻不曉得是誰,現在正在釐清這個匯出且公開 成員暱稱-註冊email 的操作發生時間點(可能是三年前)與操作者 #bridge
chewei 哲瑋
2021-05-27 10:40:22
ronnywang
10:14:25
slack 的 export 檔本身好像不包含 email 資訊,不知道 zulipchat 那邊是怎麼抓到 email 的?
- 😵4
- 💔3
- ⚠️4
chewei 哲瑋
2021-05-27 10:58:07
要請 slack admins 幫忙確認囉
ronnywang
2021-05-27 11:33:13
應該是好幾年前我有用 slack 內建的 export 功能提供匯出檔給 @kevinliao,但我印象中預設的 export 檔是沒有 email 的,我剛剛也有試著匯出過一次裡面沒有(https://g0v-slack-archive.g0v.ronny.tw/ 裡面也沒有 email 資訊)
gugod
2021-05-27 16:00:26
看來我也是自動變成 zulip 那邊的 org owner,如果需要看什麼機密文件(?)的話可能我的畫面上有的看
gugod
2021-05-27 16:05:40
https://github.com/grundleborg/slack-advanced-exporter/blob/master/cmd_fetch_emails.go#L136
看來是有~校正回歸~事後補登 email addr. 的手段
看來是有~校正回歸~事後補登 email addr. 的手段
chewei 哲瑋
10:19:46
像是與 Telegram bridged 會有這樣的狀況嗎?
還有誰 於何時 接上了哪個服務呢?😵
還有誰 於何時 接上了哪個服務呢?😵
fly
10:48:10
chewei 哲瑋
10:58:07
Replied to a thread: 2021-05-27 10:14:25
是否要來確認 Full Slack Export 是什麼..
https://g0v-tw.slack.com/archives/C01SHPD80UD/p1622083639017300?thread_ts=1622034205.006500&channel=C01SHPD80UD&message_ts=1622083639.017300
https://g0v-tw.slack.com/archives/C01SHPD80UD/p1622083639017300?thread_ts=1622034205.006500&channel=C01SHPD80UD&message_ts=1622083639.017300
Kevin.
Roles and account information are imported over as part of the full Slack export.
- Forwarded from #bridge
- 2021-05-27 10:47:19
pm5
11:31:34
要請 slack admins 幫忙確認囉
ronnywang
11:33:13
應該是好幾年前我有用 slack 內建的 export 功能提供匯出檔給 @kevinliao,但我印象中預設的 export 檔是沒有 email 的,我剛剛也有試著匯出過一次裡面沒有(https://g0v-slack-archive.g0v.ronny.tw/ 裡面也沒有 email 資訊)
gugod
16:00:26
看來我也是自動變成 zulip 那邊的 org owner,如果需要看什麼機密文件(?)的話可能我的畫面上有的看
gugod
16:05:40
https://github.com/grundleborg/slack-advanced-exporter/blob/master/cmd_fetch_emails.go#L136
看來是有~校正回歸~事後補登 email addr. 的手段
看來是有~校正回歸~事後補登 email addr. 的手段
chihao
16:11:28
export 任何資料之前,不用有某種公告和確認嗎?
ronnywang
16:15:44
當初執行 export 的應該是我,我先道歉當時未進行公告,但我印象中我當時有確認過 export 檔裡面並不包含 private channel 資料以及個人隱私資料,只是我這邊已經沒有保留當時的匯出檔了
chihao
16:20:42
原來如此
chihao
16:20:59
ronny ++ 感謝說明
chihao
16:21:26
這是個有趣的案例呢 😛
ronnywang
16:22:10
https://g0v-slack-archive.g0v.ronny.tw/index/channel/C02G2SXKX/2018-12#ts-1544236915.148600
時間的話應該是 2018 年 10 月
時間的話應該是 2018 年 10 月
- 🙌1
gugod
16:30:33
web ui 上看來 zulip 那邊大部分使用者的建立日期是2018/12/17
gugod
16:30:44
那可能是實際執行匯入的日期
ronnywang
16:31:14
g0v-slack-archive 的 import script 也是在 2018 年 10 月寫的,可能也是用同一份 export 檔匯入的,但是我剛檢查 g0v-slack-archive 裡面的資料並不包含 email 個資
- 🙌1
ronnywang
16:31:20
``` <?php include(__DIR__ . '/../init.inc.php'); $dir = $_SERVER['argv'][1]; if (!$dir) { throw new Exception("Usage: php import-directory.php [slack export directory]"); } else if (!is_dir($dir)) { throw new Exception("{$dir} is not a directory"); } try { Message::createTable(); Channel::createTable(); User::createTable(); ChannelUser::createTable(); } catch (Exception $e) { } // import channels if (!file_exists($dir . '/channels.json')) { throw new Exception("channels.json not found in {$dir}"); } $channel_info = json_decode(file_get_contents($dir . '/channels.json')); $channel_id_to_name = array(); $channel_name_to_id = array(); $db = Message::getDb(); $max_ts = 0; Message::getDb()->query("CREATE TEMP TABLE message_temp (LIKE message)"); $terms = array(); $c = 0; foreach ($channel_info as $channel) { try { $channel_id_to_name[$channel->id] = $channel->name; $channel_name_to_id[$channel->name] = $channel->id; Channel::insert(array( 'id' => $channel->id, 'name' => $channel->name, 'data' => json_encode($channel), )); } catch (Pix_Table_DuplicateException $e) { if (Channel::find($channel->id)->name != $channel->name) { // TODO: 看哪邊新... //throw new Exception("id = {$channel->id} 的頻道名稱是 " . Channel::find($channel->id)->name . ", 與 {$channel->name} 不吻合"); } } foreach (glob($dir . '/' . $channel->name . '/*.json') as $message_json) { $messages = json_decode(file_get_contents($message_json)); foreach ($messages as $message) { $max_ts = max($max_ts, $message->ts); $terms[] = sprintf("(%lf,%s,%s)", floatval($message->ts), $db->quoteWithColumn('data', $channel_name_to_id[$channel->name]), $db->quoteWithColumn('data', json_encode($message)) ); $c ++; if (count($terms) >= 1000) { $db->query("INSERT INTO message_temp (ts, channel_id, data) VALUES " . implode(',', $terms)); $terms = array(); error_log("insert {$c} records"); } } } } if (count($terms)) { $db->query("INSERT INTO message_temp (ts, channel_id, data) VALUES " . implode(',', $terms)); $terms = array(); } $sql = "UPDATE message SET data = message_temp.data FROM message_temp WHERE message.ts = message_temp.ts AND message.channel_id= message_temp.channel_id AND (message.data)::text != (message_temp.data)::text RETURNING message.ts"; $res = $db->query($sql); $u = 0; while ($row = $res->fetch_array()) { $u ++; } error_log("一共變更 {$u} 筆訊息"); $sql = "INSERT INTO message SELECT * FROM message_temp WHERE (ts, channel_id) IN (SELECT ts, channel_id FROM message_temp EXCEPT SELECT ts, channel_id FROM message) RETURNING message.ts"; $res = $db->query($sql); $insert = 0; while ($row = $res->fetch_array()) { $insert ++; } error_log("一共新增 {$insert} 訊息"); foreach ($channel_info as $channel) { $c = Channel::find($channel->id); if ($max_ts > $c->last_fetched_at) { $c->update(array( 'last_fetched_at' => $max_ts, 'last_updated_at' => $max_ts, )); } } ```
chihao
16:47:50
Zulip 事件紀錄,可以用在檢討(?)和治理機制討論 https://g0v.hackmd.io/KCnJ7hgbRke19j_-UfYsrQ
1- 👍1
ichieh
2021-05-27 16:48:53
@kevinliao 這邊
chihao
2021-05-27 16:56:56
kcjl 似乎也在增加內容 ++
kjcl
2021-05-27 16:59:04
我跟 Zulip 的通訊完全上傳到 Slack 了。
kjcl
2021-05-27 16:59:34
我把我個人的電子郵件,名字刪掉了。也把 Zulip 員工的名字也刪掉了
kjcl
2021-05-27 16:59:50
也把 API Key刪掉了
chihao
2021-05-27 17:01:12
@kevinliao 不太好讀,建議每一封 email 一個 `##` h2 如何?
kjcl
2021-05-27 17:01:42
先放那裡帶一會兒在整理我先寫一些其他的必要的東西
kjcl
2021-05-27 17:06:00
@ronnywang API Key 現在還有人在用嗎?
kjcl
2021-05-27 17:06:14
可以把他直接刪除掉把
ronnywang
2021-05-27 17:06:39
API Key 目前已經不能使用了
ronnywang
2021-05-27 17:06:49
應該是上週前不能使用的
kjcl
2021-05-27 17:07:41
是因為什麼原因而被禁止的? 想要把它放在 報告裡
ronnywang
2021-05-27 17:08:48
因為上週三開始 #g0v-slack 在討論 slack 治理機制,然後我看到 Slack API Tester 這個 app 我覺得應該沒有人在使用,我就把他刪除掉了,應該就會影響到當初的 API Key
kjcl
2021-05-27 17:09:08
了解,謝謝!
ichieh
16:48:53
@kevinliao 這邊
kjcl
16:48:58
@kevinliao has joined the channel
kjcl
16:50:24
我犯了大錯了。。。那時候我把 API key 直接發給他們了。不好意思大家。我把我全部跟他們的 e-mail 記錄放到共筆
isabelhou
2021-05-27 17:47:41
無法完全看懂技術細節,但感謝發現立刻補救和開誠布公共筆。尤其是@kevinliao 提供了email紀錄。也許可以約個時間線上討論一下。
kjcl
2021-05-27 17:50:06
非常願意參與檢討會議。我也可以想辦法解讀一下技術細節
kjcl
2021-05-27 17:51:06
任何問題先歡迎在共筆裡以下的問答部分詢問。我會儘快回答
kjcl
2021-05-27 18:17:19
英翻中完畢。拜託修正!
chihao
16:56:56
kcjl 似乎也在增加內容 ++
kjcl
16:59:04
我跟 Zulip 的通訊完全上傳到 Slack 了。
kjcl
16:59:34
我把我個人的電子郵件,名字刪掉了。也把 Zulip 員工的名字也刪掉了
kjcl
16:59:50
也把 API Key刪掉了
chihao
17:01:12
@kevinliao 不太好讀,建議每一封 email 一個 `##` h2 如何?
kjcl
17:01:42
先放那裡帶一會兒在整理我先寫一些其他的必要的東西
ronnywang
17:02:17
API key 好像不是我提供的,應該是 @kevinliao 自行產生的,當初 slack 的設定是人人都可以自行申請 API key ,去年才改成要 admin 同意才能申請
- 1
- 👍2
kjcl
17:06:00
@ronnywang API Key 現在還有人在用嗎?
kjcl
17:06:14
可以把他直接刪除掉把
ronnywang
17:06:39
API Key 目前已經不能使用了
ronnywang
17:06:49
應該是上週前不能使用的
kjcl
17:07:41
是因為什麼原因而被禁止的? 想要把它放在 報告裡
ronnywang
17:08:48
因為上週三開始 #g0v-slack 在討論 slack 治理機制,然後我看到 Slack API Tester 這個 app 我覺得應該沒有人在使用,我就把他刪除掉了,應該就會影響到當初的 API Key
kjcl
17:09:08
了解,謝謝!
isabelhou
17:47:41
無法完全看懂技術細節,但感謝發現立刻補救和開誠布公共筆。尤其是@kevinliao 提供了email紀錄。也許可以約個時間線上討論一下。
kjcl
17:50:06
非常願意參與檢討會議。我也可以想辦法解讀一下技術細節
kjcl
17:51:06
任何問題先歡迎在共筆裡以下的問答部分詢問。我會儘快回答
kjcl
18:20:48
好。我補充一下工筆
kjcl
18:25:33
我都可以。如果等明天的話也許可以找 Zulip 團體的工程師參與
pm5
19:23:03
題外話發 security bounty +1
kjcl
20:07:30
討論的結果好像是
1. 應該deactivate Zulip instance
2. 應該去找 Zulip 支援團隊的確認數據已經刪除掉。
3. 我們重新做一個沒有 import 的 Zulip service 然後開通 bridge
在我刪除之前,有沒有 Zulip 上面為了檢討報告而還需要的資料? 我個人覺得沒有了
So it appears, from the discussion, next steps to mitigate:
1. Deactivate the Zulip instance
2. Confirm with the Zulip team that the data from the instance was deleted.
3. Kevin will set up a new Zulip instance with open source plan, and we will set up a bridge with *no data import**
Is there any data on the instance I need to move off before deleting?
1. 應該deactivate Zulip instance
2. 應該去找 Zulip 支援團隊的確認數據已經刪除掉。
3. 我們重新做一個沒有 import 的 Zulip service 然後開通 bridge
在我刪除之前,有沒有 Zulip 上面為了檢討報告而還需要的資料? 我個人覺得沒有了
So it appears, from the discussion, next steps to mitigate:
1. Deactivate the Zulip instance
2. Confirm with the Zulip team that the data from the instance was deleted.
3. Kevin will set up a new Zulip instance with open source plan, and we will set up a bridge with *no data import**
Is there any data on the instance I need to move off before deleting?
2
1
Chris Bobbe
20:08:10
@csbobbe has joined the channel
kjcl
20:23:05
同意
kjcl
20:23:29
設治理機制的治理機制是什麼? 😛
isabelhou
2021-05-27 20:56:32
你已經開啟一個機制了XD
chihao
2021-05-28 10:53:10
我以為現在還是在事件後續處理?— 「發生時間的處理方式」技術上也是個機制沒錯,但我想要有「怎麼決定可以蓋一座橋」的機制 XD
chihao
2021-05-28 10:53:37
許願是錯誤示範,先道歉 XD
isabelhou
2021-05-28 10:55:53
我指的開啟是問「設治理機制的治理機制是什麼?」這句話。事件後續處理和機制討論不衝突吧。
chihao
2021-05-28 10:56:32
完全不衝突,而且是機制的一部分,如上所述 😛
isabelhou
20:56:32
你已經開啟一個機制了XD
2021-05-28
chihao
10:53:10
我以為現在還是在事件後續處理?— 「發生時間的處理方式」技術上也是個機制沒錯,但我想要有「怎麼決定可以蓋一座橋」的機制 XD
chihao
10:53:37
許願是錯誤示範,先道歉 XD
isabelhou
10:55:53
我指的開啟是問「設治理機制的治理機制是什麼?」這句話。事件後續處理和機制討論不衝突吧。
chihao
10:56:32
完全不衝突,而且是機制的一部分,如上所述 😛
kjcl
15:15:55
嗨大家,開了一個 whenisgood 決定檢討會議時間! http://whenisgood.net/9h55m9x
Chris 願意從加州跟我們大家視訊,代表他自己(而不是他的公司)了解一下以後流程能夠怎麼改善。因此我設的時間都是台灣早上,美國西岸傍晚。如果大家無法參與的話,我在儘量找其他時間
Hi everyone, I've started a whenisgood to settle on a time for incident review.
@csbobbe has agreed to join us from California (just as himself a g0v participant, not representing his company) to understand how processes can be improved in the future. As such, I've set times to be evenings on the American West Coast, and mornings in Taiwan. If none of these times work, please let me know.
Chris 願意從加州跟我們大家視訊,代表他自己(而不是他的公司)了解一下以後流程能夠怎麼改善。因此我設的時間都是台灣早上,美國西岸傍晚。如果大家無法參與的話,我在儘量找其他時間
Hi everyone, I've started a whenisgood to settle on a time for incident review.
@csbobbe has agreed to join us from California (just as himself a g0v participant, not representing his company) to understand how processes can be improved in the future. As such, I've set times to be evenings on the American West Coast, and mornings in Taiwan. If none of these times work, please let me know.
whenisgood.net
Plan the time to have your meeting or event by co-ordinating availability with all the particpants using this fuss-free online tool.
3
2
Chris Bobbe
2021-05-29 02:34:05
> just as himself a g0v participant, not representing his company
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".
The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).
One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.
Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.
While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂
As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".
The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).
One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.
Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.
While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂
As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.
Chris Bobbe
2021-05-29 02:36:17
> 代表他自己(而不是他的公司)
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。
我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)
我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。
此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。
雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂
對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。
我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)
我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。
此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。
雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂
對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
2021-05-29
Chris Bobbe
02:34:05
Replied to a thread: 2021-05-28 15:15:55
> just as himself a g0v participant, not representing his company
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".
The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).
One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.
Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.
While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂
As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".
The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).
One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.
Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.
While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂
As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.
When <https://zulip.com/help/import-from-slack|importing data from Slack>, Zulip should respect the <https://slack.com/help/articles/228020667-Manage-email-display|Slack workspace's setting> of who can see email addresses, instead of defaulting to showing email addresses to any user (that default setting is applied to all projects, with or without a Slack import; see the <https://g0v.zulipchat.com/help/restrict-visibility-of-email-addresses#restrict-visibility-of-email-addresses_1|doc> on the setting). The setting should be applied before any users are imported. A large open-source org reports that the delay in getting the right setting applied was multiple years; the Zulip Cloud org was created from a Slack import, there was a long period of inactivity, and then when it regained activity, users saw email addresses they considered private and an owner applied the "nobody" setting.
- ❤️2
Chris Bobbe
02:36:17
Replied to a thread: 2021-05-28 15:15:55
> 代表他自己(而不是他的公司)
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。
我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)
我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。
此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。
雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂
對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。
我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)
我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。
此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。
雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂
對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
- ❤️5
pinshan.yuan
19:01:58
@pinshan.yuan has joined the channel