Cloudflare 正在開發新的 DNS 查詢機制，讓 DNS 無法識別查詢人的身份與來源。
現有的 DNS 加密機制 DoH (DNS-over-HTTPS) 是端對端加密，確保第三方無法取得原始查詢內容，但 DNS 營運方還是能夠知道查詢人的來源與查詢目標，Cloudflare 新的 ODoH (Oblivious DoH) 機制是在用戶端與 DNS 中間插入一個中介主機，來自用戶端的查詢會進入中介主機而不直接發送給 DNS，DNS 也只會收到來自中介主機的查詢，因此它無法知道在中介主機後面究竟是誰在做這筆查詢，當然這個機制要能成立的前提是中介主機的角色以及營運方，必須確保中介主機的營運方不會洩漏查詢者的隱私。
安全研究人員發現傳訊 app 的連結預覽功能可能會帶來資安風險。傳訊 app 裡面常看到的連結預覽功能，一般有幾種做法：
由發訊端載入連結產生預覽圖片與文字，把預覽圖片與文字傳送給收訊端，收訊端可以不用訪問連結就可以得到預覽內容，這種做法較安全，如果是惡意連結，那麼這個機制下收訊端不用因為要產出預覽內容而去訪問那個惡意連結，這樣設計的 app 有 iMessage、WhatsApp、TikTok、Wechat、Telegram。
由收訊端載入連結產生預覽圖片與文字，這種設計不安全，如果是惡意連結，那收訊端會因為要得到預覽內容而自動的把連結打開，手機可能因此而被感染，這樣設計的 app 有 Reddit。
由 app 自己設立的外部主機去開連結產生預覽圖片與文字，再傳給發訊端與收訊端，這對惡意連結的例子是安全的，但如果連結內容是機密的，傳訊 app 可能會因此意外的存取到機密內容，並且外部主機也有可能有其它的漏洞導致機密外洩。這樣設計的 app 有 Discord、Facebook Messenger、Google Hangouts、Instagram、LinkedIn、Slack、Twitter、Zoom、LINE。
一款名為 Cellmate 的男性貞操鎖，具有聯網與 app 控制的能力，而因為 app 設計上的缺陷，有可能被遠端入侵，並接管你的老二，除了軟體上的缺陷外，貞操鎖本身也沒有任何的備用解鎖機制，一旦被惡意上鎖，就只能用切割工具物理破壞或是想辦法破壞內部的電路等粗暴手法才有可能解開。
看這新聞荒唐之餘，不禁讓人聯想，供電給貞操鎖的鋰電池是否有爆炸的可能性？
最後把這產品推薦給才幹過人的丁允恭，他值得來一管。
在高併發的場景下，應該是唯一值的訂單號重複問題，即使以毫秒或亂數器做為參數取號，也有機會產生出重複的單號，再加上多實例的場景，不同實例間很有可能在同一時間又產生同樣的單號，這篇文章除了優化取號參數外，針對多實例的部份也把實例的 IP 列入取號參數內，確保同時間不同實例也可以產生不同的單號，最後在資料庫端，也要對單號的欄位設定 unique 的屬性，確保不允許重複的單號，並在程式端做出相對應的錯誤處理機制。
介紹密碼加密儲存的一些考量，總之就是能加鹽就加鹽，能雜湊就雜湊。
安全防護服務，特色是直接與 app 做整合。
Sqreen 有兩項重要特色：runtime application self-protection 與 in-app WAF，具體的機制是把 Sqreen 提供的套件直接整合進專案內，它會分析進來的請求，並阻擋 XSS 或 SQL 注入等攻擊。
CDN 除了幫我們分散流量，也有隱藏主機真實 IP 的好處，不讓 IP 直接暴露在外可以避免掉一些有針對性的攻擊，但因為凡走過必留下痕跡，在啟用 CDN 前的 DNS 紀錄或 TLS 憑證一旦被紀錄了，那就有可能透過這些舊紀錄來挖出主機的真實 IP，所以比較好的作法是在啟用 CDN 後換一次 IP，或者從架構面思考，改以 serverless 的服務來建構自己的服務，前端也是託管在服務商的靜態空間，這些服務有說 AWS Lambda、Google Cloud Functions、Azure Functions 等等，除了既有的雲服務大廠外，新興的 CloudFlare Workers、Vercel、Netlify 也都是這樣的架構。