New note: problems with BIMI

content/notes/problems-with-bimi.md

@@ -0,0 +1,16 @@
+---
+title: "Problems with BIMI"
+date: 2023-06-09T22:15:51-07:00
+syndicatedCopies:
+    - title: 'The Fediverse'
+      url: 'https://pleroma.envs.net/notice/AWXQqaIGDQl0Jf0JOq'
+---
+Everything about [Brand Indicators for Message Identification](https://bimigroup.org/) (<abbr>BIMI</abbr>) feels so half-baked.
+
+Lukewarm take: <abbr>BIMI</abbr> should mandate <abbr title="Domain-based Message Authentication, Reporting and Conformance">DMARC</abbr> with <abbr title="DomainKeys Identified Mail">DKIM</abbr> and just ignore <abbr title="Sender Policy Framework">SPF</abbr>. It could also require supporting TLS 1.3+. After all, one of the stated goals of <abbr>BIMI</abbr> was to increase adoption of better email standards like <abbr>DMARC</abbr>. This could have [entirely prevented recent spoofing issues](https://infosec.exchange/@titanous/110481616735600044).
+
+Putting the <abbr>HTTPS</abbr> <abbr>URL</abbr> of an <abbr>SVG</abbr> icon in a new <abbr>DNS</abbr> <abbr>TXT</abbr> record to associate a whole domain with a logo makes no sense. _Several_ better standards exist for associating a `user@domain` with an image, allowing different logos for different emails at the same domain. [Webfinger](https://webfinger.net/) and [Libravatar](https://www.libravatar.org/) come to mind.
+
+Hell, even its special <abbr>SVG</abbr> Tiny Portable/Secure standard could be simplified further. [usvg](https://github.com/RazrFalcon/resvg/tree/6be2f2d396e539ddfcf022dc67f304d307c1211a/crates/usvg) can convert nearly any <abbr>SVG</abbr> to a tiny subset of the <abbr>SVG</abbr> Tiny P/S standard while preserving their appearance.
+
+Of course, none of this is too relevant to the <abbr>BIMI</abbr> group. The real purpose of <abbr>BIMI</abbr> was always to give certificate authorities a new source of income after their losses from Let's Encrypt's (lack of) pricing, the rise of ACME-based automation, and browsers' deprecation of EV features.