content/notes/re-debunking-myths-about-https.md

@@ -1,22 +0,0 @@
----
-title: "Re: debunking myths about HTTPS"
-date: 2022-09-19T14:39:08-07:00
-replyURI: "https://blog.julien-maury.dev/en/snippets/https-myths/"
-replyTitle: "Debunking myths about HTTPS"
-replyType: "Article"
-replyAuthor: "Julien Maury"
-replyAuthorURI: "https://julien-maury.dev/#about"
----
-> A "more sophisticated" scenario can consist of manually routing all the victim's traffic to an external server. The attackers can also create fake networks or routers. In other words, it's possible to act as a proxy under certain conditions without any knowledge from the victims who wouldn't change their behavior, as nothing would look wrong.
-
-This attack allows intercepting cleartext communication. However, simply proxying traffic does not allow decryption.
-
-Decryption as you describe requires compromising the host <abbr>OS</abbr>, which would allow an attacker to do anything a user can. A compromised OS has no expectation of security, regardless of which measures you put in place.
-
-A better attack would be to add an additional CA to the OS and browser CA bundles. This would let an attacker add their own TLS certificates to sites without getting rejected by the browser. However, once again, this requires an attacker to compromise the host OS.
-
-The only convincing HTTPS-compromise mentioned is interception of an unencrypted initial connection before it's upgraded to HTTPS; this is a valid concern for sites not on the HSTS-Preload lists or lacking [HTTPS service-binding DNS records](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/).
-
-A better argument would be that TLS doesn't normally encrypt Server Name Indication (<abbr>SNI</abbr>) or obfuscate record sizes; <abbr>SNI</abbr>-sniffing or traffic analysis could reveal domain names or pages, respectively.
-
-I'd say that HTTPS combined with random record padding and Encrypted Client Hello (TLS 1.3 extensions) and a form of encrypted DNS (<abbr title="DNS-over-TLS">DoT</abbr>, <abbr title="DNS-over-HTTPS">DoH</abbr>, <abbr title="DNS-over-QUIC">DoQ</abbr>) can offer pretty good privacy protections against a <abbr title="Machine in the Middle">MITM</abbr>: the only reliable information leakage with these measures in place is at the <abbr title="Internet Protocol">IP</abbr> layer. <abbr>IP</abbr> addresses are less specific than hostnames, since one <abbr>IP</abbr> can correspond to multiple hostnames.

content/notes/state-of-the-tor-uplift.md

@@ -1,11 +0,0 @@
----
-title: "State of the Tor Uplift"
-date: 2022-09-19T20:15:05-07:00
----
-Currently, the Tor Browser is based on Firefox Extended Support Release (<abbr title="Extended Support Release">ESR</abbr>); it lags behind stable releases by up to <time datetime="P390D">13 months</time> and only receives the subset of security backports deemed to be a high-enough priority.
-
-The [Tor Uplift project](https://wiki.mozilla.org/Security/Tor_Uplift) is an initiative to upstream all the Tor Browser's patches into Firefox. Its goal is to make re-basing the Tor browser patches easy enough for the Tor Browser to track Firefox's stable release channel. The Tor Uplift has been in progress for <time datetime="P2357D">seven years</time>, with several of the Tor Browser's biggest modifications successfully upstreamed (first-party isolation, fingerprinting resistance, and more robust proxy support).
-
-On <time datetime="2022-06-28">2022-06-28</time>, Firefox 102 ESR was released. Today, on <time datetime="2022-09-20">2022-09-20</time>, Firefox 91 ESR will lose support. That gave a window of about three months (the duration of three Firefox stable releases) to re-base Tor Browser patches.
-
-The first stable release of the Tor Browser based on ESR 102 hasn't yet shipped (it's close; [an alpha version is available](https://blog.torproject.org/new-alpha-release-tor-browser-120a2/)). Seven years into the Tor uplift, the Tor Project isn't able to keep up with the Firefox ESR release calendar. I don't think the Tor Uplift will succeed at getting the Tor Browser to track Firefox's stable channel; at best, it's keeping the Tor Browser from falling too far behind ESR.

layouts/partials/webmentions.html

@@ -59,8 +59,7 @@
 								{{ if $webmention.author_name -}}
 									<span itemprop="agent" itemscope="" itemtype="https://schema.org/Person" class="h-card p-author vcard"><span itemprop="name" class="p-name fn n">{{ $webmention.author_name }}</span></span>
 								{{ else if $webmention.title -}}
-									<span itemprop="name" class="p-name">{{ $webmention.title | replaceRE ` \n` `
-` -}}</span>
+									<span itemprop="name" class="p-name">{{ $webmention.title -}}</span>
 								{{ else -}}
 									{{ $webmention.source | strings.TrimPrefix "https://" | strings.TrimPrefix "www." | strings.TrimRight "/" | truncate 35 -}}
 								{{ end -}}
@@ -69,8 +68,7 @@
 								<a class="u-url" itemprop="url" href="{{ $src }}" rel="nofollow ugc">
 									<span itemprop="name" class="p-name">
 										{{ if $webmention.title -}}
-											{{ $title | truncate 200 | replaceRE ` \n` `
-` -}}
+											{{ $title | truncate 200 -}}
 										{{ else -}}
 											{{- $webmention.source | strings.TrimPrefix "https://" | strings.TrimPrefix "www." | strings.TrimRight "/" | truncate 35 -}}
 										{{ end -}}