Hacker Newsnew | past | comments | ask | show | jobs | submit | elliottinvent's commentslogin

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.

1. https://www.domainverification.org

2. https://news.ycombinator.com/item?id=35827952

3. https://www.num.uk

4. https://www.numprotocol.com


Wait til you see the Twitter account:

https://twitter.com/htmx_org


> all it does is do simple things by adding attributes to html elements

It’s extending html to make the most of http by adding some simple attributes.

Like all great things - the building blocks are simple, but the possibilities of what you can build with them is vast.

I think this is really well dealt with in the “opportunities” to extend html in this chapter of the Hypermedia Systems book: https://hypermedia.systems/extending-html-as-hypermedia/


Very active, helpful community on Discord [1] and a #htmx-2-dev channel for discussion on this very topic

1. https://htmx.org/discord


It was recently explained to me:

Introverts charge their battery in solitude and discharge it socialising. Extroverts the opposite.


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.

1. “Balance not batteries” https://www.vipshek.com/blog/interaction#balance-not-batteri...


If only all properties were pitched expertly by the vendor, like the “never ending property” [1]

With high end 70s chintz and cheese production values.

1. https://m.youtube.com/watch?v=kynbFDou6GI&feature=youtu.be&c...


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.

In the meantime, you can see the spec here: https://gitlab.com/NUMTechnology/Domain-Verification/docs/-/...


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 :)

[0]: https://github.com/philc/vimium

[1]: https://github.com/DoodlesEpic/VimiumDark


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.

It stood up pretty well to the traffic last time.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: