mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2025-02-25 07:50:04 +00:00
Compare commits
2 commits
edfe941af5
...
eb0ca616c6
Author | SHA1 | Date | |
---|---|---|---|
![]() |
eb0ca616c6 | ||
![]() |
491ba7a48e |
2 changed files with 22 additions and 1 deletions
21
content/notes/overriding-default-font-size.md
Normal file
21
content/notes/overriding-default-font-size.md
Normal file
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: "Overriding default font size"
|
||||
date: 2022-10-27T11:18:25-07:00
|
||||
replyURI: "https://mastodon.social/@mathew/109236592585774225"
|
||||
replyTitle: "why override the user's choice of base font size?"
|
||||
replyType: "SocialMediaPosting"
|
||||
replyAuthor: "mathew"
|
||||
replyAuthorURI: "https://meta.ath0.com/"
|
||||
---
|
||||
Three reasons to declare a font size in a page's CSS:
|
||||
|
||||
1. Not all browsers support all types of zoom (standard, pinch-to-zoom, and text-only zoom). Some mobile browsers still don't support _any_ type of zoom.
|
||||
|
||||
2. Different use-cases call for different sizes. Long-form text should be bigger than text in user-interface controls.
|
||||
|
||||
3. WCAG guidelines recommend sizing tap-targets to at least 44-by-44 CSS pixels, with the exception of inline links. Google recommends 48-by-48 CSS pixels, with no overlap across a 56-by-56 pixel range. Increasing my root font size makes non-inline links and buttons bigger.
|
||||
|
||||
Combining the first and second points, we see that the base font size on the Web is not a "one-size-fits-all" solution. It's now a reference point for relative font sizes (e.g. `em`, `rem`, percents). Relative font sizes scale with the base font instead of "overriding" it.
|
||||
|
||||
My browser's default size is perfect for a typical Fediverse microblog or information-dense discussion-forum, not for reading an article. My website's stylesheet defines a font that is 9.375% larger than default, whatever that may be.
|
||||
|
|
@ -114,7 +114,7 @@ For more information, we turn to [**core dumps**](https://en.wikipedia.org/wiki/
|
|||
|
||||
In 2020, Zoom Video Communications came under scrutiny for marketing its "Zoom" software as a secure, end-to-end encrypted solution for video conferencing. Zoom's documentation claimed that it used "AES-256" encryption. Without source code, did we have to take the docs at their word?
|
||||
|
||||
{{<mention-work itemtype="TechArticle">}}<a itemtype="https://schema.org/Organization" itemprop="publisher" href="https://citizenlab.ca/">The Citizen Lab</a> didn't. On <time class="dt-published published" itemprop="datePublished">2020-04-03</time>, it published {{<cited-work url="https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/" name="Move Fast and Roll Your Own Crypto" extraName="headline">}} (<span itemprop="encodingFormat">application/pdf</span>){{</mention-work>}} revealing critical flaws in Zoom's encryption. It utilized Wireshark and [mitmproxy](https://mitmproxy.org/) to analyze networking activity, and inspected core dumps to learn about its encryption implementation. The Citizen Lab's researchers found that Zoom actually used an incredibly flawed implementation of a weak version of AES-128 (ECB mode), and easily bypassed it.
|
||||
{{<mention-work itemtype="TechArticle">}}<a itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher" href="https://citizenlab.ca/">The Citizen Lab</a> didn't. On <time class="dt-published published" itemprop="datePublished">2020-04-03</time>, it published {{<cited-work url="https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/" name="Move Fast and Roll Your Own Crypto" extraName="headline">}} (<span itemprop="encodingFormat">application/pdf</span>){{</mention-work>}} revealing critical flaws in Zoom's encryption. It utilized Wireshark and [mitmproxy](https://mitmproxy.org/) to analyze networking activity, and inspected core dumps to learn about its encryption implementation. The Citizen Lab's researchers found that Zoom actually used an incredibly flawed implementation of a weak version of AES-128 (ECB mode), and easily bypassed it.
|
||||
|
||||
Syscall tracing, packet sniffing, and core dumps are great, but they rely on manual execution which might not hit all the desired code paths. Fortunately, there are other forms of analysis available.
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue