fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-12-24 01:42:10 +00:00
Code Issues Projects Releases Wiki Activity

Fix cited-work for orgs and a lack of links

Browse source
This commit is contained in:
Rohan Kumar 2024-04-05 17:47:02 -04:00
parent 97439f2a92
commit c1c3353a84
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
4 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/posts/floss-security.md
View file

@ -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 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.
{{<mention-work itemtype="TechArticle">}}<a itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher" href="https://citizenlab.ca/"><span itemprop="name">The Citizen Lab</span></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.

2
content/posts/two-types-of-privacy.md
View file

@ -251,7 +251,7 @@ Our recommendations need to take into account the fact that "privacy" means diff
Ack&shy;nowledge&shy;ments {#acknowledgements}
--------------------------
My article could be considered a "derivative work" of {{<mention-work itemtype="Article" itemprop="citation" role="doc-credit">}}{{<cited-work name="Recommending Tools" url="https://sec.eff.org/articles/recommending-tools">}} by <span itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher">the EFF</span>{{</mention-work>}}. That article laid the foundations for my thought process.
My article could be considered a "derivative work" of {{<mention-work itemtype="Article" itemprop="citation" role="doc-credit">}}{{<cited-work name="Recommending Tools" url="https://sec.eff.org/articles/recommending-tools">}} by <span itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher"><span itemprop="name">the EFF</span></span>{{</mention-work>}}. That article laid the foundations for my thought process.
This article is an expansion of the ideas I presented in the microblog entry {{<mention-work itemtype="SocialMediaPosting">}}{{<cited-work name="On tracker blocking" url="../../../../../notes/2022/06/06/on-tracker-blocking/">}}{{</mention-work>}}. That microblog entry was a response to the article {{<mention-work itemtype="Article" itemprop="citation" role="doc-credit">}}{{<cited-work name="Browser Tracking" url="https://madaidans-insecurities.github.io/browser-tracking.html">}} by {{<indieweb-person name="Madaidan" url="https://madaidans-insecurities.github.io/">}}{{</mention-work>}}; this article's coverage of TE draws from that article.

4
content/posts/website-best-practices.md
View file

@ -65,7 +65,7 @@ You can regard this article as an elaboration on existing work by the Web Access
I'll cite the <abbr>WAI's</abbr> {{<mention-work itemprop="citation" itemtype="TechArticle">}}{{<cited-work name="Techniques for WCAG 2.2" url="https://www.w3.org/WAI/WCAG22/Techniques/">}}{{</mention-work>}} a number of times. Each "Success Criterion" (requirement) of the WCAG has possible techniques. Unlike the <cite>Web Content Accessibility Guidelines</cite> (<abbr title="Web Content Accessibility Guidelines">WCAG</abbr>), the Techniques document does not list requirements; rather, it serves to non-exhaustively educate authors about _how_ to use specific technologies to comply with the WCAG. I don't find much utility in the technology-agnostic goals enumerated by the WCAG without the accompanying technology-specific techniques to meet those goals.
I'll also cite {{<mention-work itemid="https://www.w3.org/TR/coga-usable/" itemprop="citation" itemtype="TechArticle">}}{{<cited-work name="Making Content Usable for People with Cognitive and Learning Disabilities" url="https://www.w3.org/TR/coga-usable/">}}, by <span itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher">the WAI</span>{{</mention-work>}}. The document lists eight objectives. Each objective has associated personas, and can be met by several design patterns.
I'll also cite {{<mention-work itemid="https://www.w3.org/TR/coga-usable/" itemprop="citation" itemtype="TechArticle">}}{{<cited-work name="Making Content Usable for People with Cognitive and Learning Disabilities" url="https://www.w3.org/TR/coga-usable/">}}, by <span itemscope="" itemtype="https://schema.org/Organization" itemprop="publisher"><span itemprop="name">the WAI</span></span>{{</mention-work>}}. The document lists eight objectives. Each objective has associated personas, and can be met by several design patterns.
### Why this article exists
@ -845,7 +845,7 @@ Note that [the APCA isn't fully mature](https://yatil.net/blog/wcag-3-is-not-rea
Even if the APCA is much better than the WCAG's current naive contrast algorithms, it still doesn't account for all aspects of the relationship between perceptual contrast and color. [Discussion no. 74 on the SAPC-APCA repository](https://github.com/Myndex/SAPC-APCA/discussions/74) covers some shortcomings. For instance, the current APCA version does not account for [the Helmholtz–Kohlrausch effect](https://en.wikipedia.org/wiki/Helmholtz%E2%80%93Kohlrausch_effect): highly-saturated colors appear "brighter" than de-saturated colors with the same brightness. Excessive perceptual brightness against dark backgrounds can trigger halation, eye-strain, and overstimulation.
Yellow may have great contrast on dark backgrounds, but vivid yellow and red can cause problems among people who deal with overstimulation; this includes [many on the autism spectrum](https://www.experia.co.uk/blog/ultimate-guide-to-autism-friendly-colours/). {{<mention-work itemtype="BlogPosting">}}{{<indieweb-person name="Lē Silveus McNamara" url="https://medium.com/@hello_93199" itemprop="author">}} wrote about the issue on the <span itemscope="" itemprop="publisher" itemtype="https://schema.org/Organization">TPGi</span> blog: {{<cited-work url="https://www.tpgi.com/beyond-wcag-losing-spoons-online/" name="Beyond WCAG: Losing Spoons Online" extraName="headline">}}{{</mention-work>}}.[^26]
Yellow may have great contrast on dark backgrounds, but vivid yellow and red can cause problems among people who deal with overstimulation; this includes [many on the autism spectrum](https://www.experia.co.uk/blog/ultimate-guide-to-autism-friendly-colours/). {{<mention-work itemtype="BlogPosting">}}{{<indieweb-person name="Lē Silveus McNamara" url="https://medium.com/@hello_93199" itemprop="author">}} wrote about the issue on the <span itemscope="" itemprop="publisher" itemtype="https://schema.org/Organization"><span itemprop="name">TPGi</span></span> blog: {{<cited-work url="https://www.tpgi.com/beyond-wcag-losing-spoons-online/" name="Beyond WCAG: Losing Spoons Online" extraName="headline">}}{{</mention-work>}}.[^26]
If you want to use significant amounts of "emergency colors" like yellow and red, de-saturate them so their color feels muted. This site's dark theme uses very pale, washed-out yellow and violet for maximum contrast with minimal harshness.

2
layouts/shortcodes/cited-work.html
View file

@ -1 +1 @@
<cite itemprop="name{{if .Get "extraName"}} {{ .Get "extraName" }}{{end}}" class="p-name"><a class="u-url" itemprop="url" href="{{ .Get "url" }}" {{- with .Get "lang" }} lang="{{ . }}" hreflang="{{ . }}"{{ end -}} {{- with .Get "rel" }} rel="{{ . }}"{{ end }}>{{ .Get "name" }}</a></cite>
<cite itemprop="name{{if .Get "extraName"}} {{ .Get "extraName" }}{{end}}" class="p-name">{{ if .Get "url" }}<a class="u-url" itemprop="url" href="{{ .Get "url" }}" {{- with .Get "lang" }} lang="{{ . }}" hreflang="{{ . }}"{{ end -}} {{- with .Get "rel" }} rel="{{ . }}"{{ end }}>{{ end }}{{ .Get "name" }}{{ with .Get "url" }}</a>{{ end }}</cite>