I'm working on a couple of projects that are along these lines:
- Domain Verification Protocol [1][2] – proving authority over a domain. This is an application of our broader technology (still in development) where the domain can represent any thing (not just a company, e.g. an asset).
- NUM [3][4] a way to store structured data in DNS so that the domain name is the unique key to make a telephone call, GPS locate, make a payment, etc
The usual response to concepts for storing anything in DNS is MITM attacks but these can be mitigated. See DNSSEC, DNS over HTTPs, DNS over TLS.
Email in my profile, you're welcome to reach out to discuss.
The author talks about how he dislikes this characterization exactly because it's so binary and doesn't seem to be accurate for most people who fall into the "ambivert" center of the bell curve. The whole article is a beautiful breakdown of how social interaction is much more multi-faceted than this. You should read it.
Admittedly I didn’t get that [1] far, thanks for pointing it out. I read the first half but he lost me at conversational dynamics (I mainly come here for the comments).
The battery analogy was a good way for me to understand my own experience and seemed like progress from the traditional definitions of introvert and extrovert.
Thanks for the heads up and I'm sorry about that, I can't seem to recreate it in Firefox at the moment but I'll get to the bottom of it. Are you in automatic/dark/light mode? Your Firefox version would be a big help too if you were happy to share that.
Sooo, apparently in a clean browser without extensions this does not happen. I tracked down this to a problem with Vimium [0], when I disable it the webpage displays correctly.
Essentially, the issue is that Vimium's stylesheet also set the --fg variable. While your website sets it to #000000 or something like that, Vimium sets it to #FFFFFF and for some reason that interferes with the webpage. Alas, one more reason for me to stay with SCSS haha.
Even more interesting is that the same issue does not happen on a Chromium browser with Vimium with the exact same stylesheet, meaning the global stylesheet pollution only happens on Firefox.
Anyway, I would say this is not a problem with your website but rather with my (beautiful) Vimium stylesheet [1]. Still, you could fix this issue by converting these CSS variables to SCSS ones, so they are hard-coded variables on runtime, or perhaps by using !important to make sure it's not overwritten.
The stylesheet I'm using is not the default but rather a fork of a pretty specific one, so I'll also make the changes there to stop using CSS variables.
By the way, since you asked I'm running Firefox 112.0.2 (64-bit), Red Hat fedora - 1.0 build, although it's not related to Firefox at all.
edit: just prefixed all css variables in the stylesheet with an identifier and everything is working now :)
Thanks for the heads up, home page or any page in particular?
It’s ok for me but I’ll check the logs.
It’s just a basic fly.io setup at the moment but it should be more than capable of dealing with the traffic - just html (and htmx) front end and Sinatra back end.
Oh and to prevent what happened last time (the post getting flagged as an overheated discussion), I'm going to close the laptop and come back to this in a few hours! So if you ask a question, I'm not ignoring you – I'll respond later.
Thanks for this really interesting feedback – especially that the subdomain method could create more opportunities for cache poisoning.
Interested to explore how a cache poisoning attack might be easier on a Domain Verification protocol TXT record compared to a DNS-01 TXT record.
Given the scenario: an attacker is attempting to claim a domain (example.com) with service provider (SP1) who uses a DNS revolver (DR1) I don’t immediately see how the subdomain approach makes a cache poisoning attack easier.
Couldn’t the attacker similarly keep asking DR1 for <rand>._acme-challenge.example.com and spam back NS delegation answers for _acme-challenge.example.com, with the goal that upon cache poisoning success, they could fraudulently claim example.com with SP1?
I may have overlooked something here, if so please explain.
With either method, DNSSEC would definitely seem the solution as you’ve suggested.
I'm not well versed in ACME but in DNS, unfortunately. Yes, it would have the same issue if it works as described. I've read a whitepaper on the subject I described and the time to poison cache goes way, way down. Basically, anyone could pull it off.
I think a solution here in the validation space is just avoiding the caching server altogether. If the validating server does something like dig +trace, it avoids this problem, especially if it prefers TCP.
- Domain Verification Protocol [1][2] – proving authority over a domain. This is an application of our broader technology (still in development) where the domain can represent any thing (not just a company, e.g. an asset).
- NUM [3][4] a way to store structured data in DNS so that the domain name is the unique key to make a telephone call, GPS locate, make a payment, etc
The usual response to concepts for storing anything in DNS is MITM attacks but these can be mitigated. See DNSSEC, DNS over HTTPs, DNS over TLS.
Email in my profile, you're welcome to reach out to discuss.
1. https://www.domainverification.org
2. https://news.ycombinator.com/item?id=35827952
3. https://www.num.uk
4. https://www.numprotocol.com