New note: Borrowing from big players

content/notes/borrowing-from-big-players.md

@@ -0,0 +1,12 @@
+---
+title: "Borrowing from big players"
+date: 2022-11-02T15:02:18-07:00
+replyURI: "https://adrianroselli.com/2020/03/i-dont-care-what-google-or-apple-or-whomever-did.html"
+replyTitle: "I Don’t Care What Google or Apple or Whoever Did"
+replyType: "BlogPosting"
+replyAuthor: "Adrian Roselli"
+replyAuthorURI: "https://adrianroselli.com/posts"
+---
+Large organizations' choices influence my decisions in only one way: by telling me what users are familiar with. For instance: when building a search-results page, it might make sense to borrow the basic semantics of existing search engines (Google, Bing, etc.) so the interface is familiar.
+
+It doesn't make sense to blatantly violate WCAG (especially at the "A" level!) just because big companies do. The companies you cite know they won't get sued over link underlines, even though removing them without replacement is an accessibility hazard. Every time someone jumps onto Flutter because Google said it's accessible, I feel tempted to file [yet another accessibility issue](https://github.com/flutter/flutter/issues/94965).

content/notes/website-security-scanners.md

@@ -0,0 +1,13 @@
+---
+title: "Website security scanners"
+date: 2022-11-02T11:56:02-07:00
+replyURI: "https://plem.sapphic.site/notice/APB6VSqinvWjm1yHgW"
+replyTitle: "why does hardenize still check for Expect-CT when the header is deprecated"
+replyType: "SocialMediaPosting"
+replyAuthor: "r3g_5z"
+replyAuthorURI: "https://blog.terezi.dev/"
+---
+
+Speaking generally: I think most website security scanners (Webbkoll, Observatory, et al) lend themselves to cargo-cults. You don't need [most Content Security Policy directives](https://w3c.github.io/webappsec-csp/#csp-directives) for a PNG file, for instance. Warning against a missing `X-Frame-Options` feels wrong: even the latest version of iOS 9---the oldest iOS release to support secure TLS 1.2 <abbr>ECDSA</abbr> ciphers---seems to support `frame-ancestors` (correct me if I'm wrong).
+
+[Internet.nl](https://internet.nl/) is a bit better: it doesn't penalize you for not using security headers. Instead, it just educates you about why you should consider them. Internet.nl only penalizes you for lacking features that universally apply, like proper TLS. I also like the approach of [ssh-audit](https://github.com/jtesta/ssh-audit): it lets you set a policy that works for your endpoint, and validate against that policy.