877 karma · joined November 5, 2023
As long as they are marked as being synthetic, why not?
If you mark them with a "this is a synthetic event" bit, the compositor/windowmanager has all the information it needs to decide whether or not to ignore the event (because, for example, the pointer moved out of one window and into another).
The driver generates the synthetic events, the compositor/windowmanager decides whether or not to drop them. Done.
However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community
Wait what?
I'm pretty sure Hutterer was the one who pushed it into the App layer. He's the maintainer of libinput, and refused to do kinetic scroll within libinput (like the libsynapse driver did for X11). If he wanted to do it centrally in libinput there's nobody else to block him from doing that -- he can just do it.
It's why you can only buy pseudoephedrine from pharmacists.
All the median-priced-cars from these brands, which are instantly totaled by anything other than cosmetic damage, are still driving up everybody else's rates.
The US said "you need to stop selling this without a prescription system". So Mexico stopped selling it entirely.
And the world has not imploded.
There's a lot of chicken-little-ism around the prescription system
There are no prescriptions in Mexico.
Medications which are scheduled controlled substances (amphetamines, codiene, morphine, etc) are sold directly by hospitals. There really aren't many of these, and hospitals already have to stock most of them for surgical use.
Everything else is cash over the counter.
And pseudoephedrine is illegal because of pressure from the US.
https://www.goodreads.com/book/show/9319468-kingpin
Especially liked the part where he is asked "so why do you keep your piles of cash in Pelican cases"? "Because they float."
No, they aren't messy, they're fully defined. Integer overflow in safe Rust works just like Java: the numbers wrap around. It's totally defined.
You can, optionally, also enable a runtime check for this wraparound. This is usually enabled for debug builds. There is of course a performance cost to doing this.
Note the dates the Huawei CE12808 was put into and taken out of service. Less than one year.
Then why don't they just ask for ID if you want port 25 unblocked?
Doesn't add up.
None of those have anything to do with demanding that customers expose themselves to identity theft risk.
https://eprint.iacr.org/2008/475
It's already in use by the Lightning Network.
The "modernized" Internet got addicted to low-latency interactive protocols. It's basically impossible to protect these from a global passive adversary. All the cool research results (mixnets) produced protections for protocols that have been proclaimed to be extremely uncool these days (like email and bitcoin tx broadcast).
> TOR is the successor to these efforts (despite the fact that it seems controlled by the NSA).
It would be smart for a global passive adversary to invest in technologies that protect people against everybody except them and then give the results away for free.
If I were a supervillian, I would definitely do that. Then I would kill people based on metadata. I'd also be more careful about letting my minions do the kind of dumb shit that gets them multi-year conference attendance bans and 11:30pm (not a typo) speaking slots.
Damn, I should become a supervillian.
> the DS record is signed by an RRSIG record that has an expiration
You've just contradicted yourself.
> No need to worry about expiration
If that were true, which it isn't, a MITM could keep feeding old signatures to the victim.
You seem to have little idea what you're talking about.
Sourcehut users unaffected.
Bankruptcy courts don't claw back payments to vendors who are legitimately attempting to assist with an orderly wind-down. From the perspective of a bankruptcy judge that would just be them shooting themselves in the foot.
This is the whole point of title insurance. You aren't paying for the answer. You're paying somebody to accept massive liability if the answer is wrong.
There is something called the "Torrens Title System" where the government does accept some part of this liability, subject to a huge raft of weird terms and conditions that the legislature can change unilaterally after the fact. It has only been successful in countries lacking constitutional limits on eminent domain, since in those places landowners are already subject to legislative whims anyways:
https://en.wikipedia.org/wiki/Torrens_title
It has been a flop in every US jurisdiction that has tried it.
When given a choice between transferring responsibility to somebody who can be sued (states can't) and gives you a contract, vs someone who can't and won't, it turns out people prefer the former.
I wouldn't buy a house based on a mere estimate of the availability of something this critical.
It's a gigantic clusterfuck.
The realtors know they can't fix this, but they can't exactly let it impede the source of their paycheck either. I absolutely would not take advice of any kind on internet access from a realtor.
Character is what you are in the dark.
The term you are searching for is confabulating.
If I want to be sure that an email came from a certain person, I ask for a PGP signature on it.
Unfortunately the public suffix list has serious security implications, so it isn't safe to distribute it via unauthenticated DNS.
It also has very serious availability implications, so if you sign it with the WebPKI-maximum validity of 90 days and somehow and those signatures expire, you either get major vulnerabilities if you fail open or else an entire TLD (like ".com") breaks if you fail closed. You get to play this game every 90 days. Sounds like fun. https://www.digicert.com/blog/chromes-proposed-90-day-certif...
This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): signature revocation is Byzantine-Generals-complete, which means that you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. Nonrenewal-as-revocation sorta works for signing single domains; if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high.
This is why DNSSEC will never displace unauthenticated DNS.
The choices are to stick with unauthenticated DNS, or maintain both systems in parallel forever. There is no third option where unsigned DNS records just go away.
There is: RFC7686: https://datatracker.ietf.org/doc/html/rfc7686
As Will Emerson says in Margin Call:
"Jesus, Seth. Listen, if you really wanna do this with your life you have to believe you're necessary and you are. People wanna live like this in their cars and big fuckin' houses they can't even pay for, then you're necessary. The only reason that they all get to continue living like kings is cause we got our fingers on the scales in their favor. I take my hand off and then the whole world gets really fuckin' fair really fuckin' quickly and nobody actually wants that. They say they do but they don't."
https://news.ycombinator.com/item?id=31300922
...right up until the Nixon Shock https://en.wikipedia.org/wiki/Nixon_shock
So few people appreciate why Bittorrent (Mainline) and DNS have been world-conquering successes while everything else (cough IPFS cough) struggles. Be stateless, be sessionless -- send only packets, allocate no state. Nothing else in the computing world scales the way the Mainline bootstrap nodes and DNS root servers do. Until recently the DNS root servers were just a handful of decent workstations at universities; Mainline's bootstrap nodes still are. None of the heavyweight cloudtech can match that kind of efficiency.
You should publish a spec for Pkarr -- the layer below did-dht -- first. Right now Pkarr is a software program/library, not a specification. I think this will help you simplify and articulate your work more clearly to people who aren't immersed in it. I think it will also be extremely useful to people who don't need the incredible complexity of w3c DIDs.
The choice to sign an entire DNS packet seems very strange and probably hasn't been through through properly.
Why use DNS packets? Presumably because you want to leverage the existing infrastrucure of recursive DNS resolvers. However these resolvers do not preserve packets!. If I send a query to my recursive resolver, and it makes a query to the authoritative server, it can (and almost always does) modify the resulting packet from the authoritative before returning a reply to me. The upshot here is: if you're signing packets, almost all recursive resolvers will destroy your signatures. This is why DNSSEC signs individual resource records instead of packets. I think that's what you want to be doing: sign an RR, not a packet. If you absolutely need to sign multiple RRs, you'll need to specify a canonical way to assemble the RRs (i.e. sort them).
I really think you want to sign an RR (which might include the hash of other RRs), not an entire DNS packet.
Lastly, please take this issue more seriously: https://github.com/TBD54566975/did-dht-method/issues/80#issu... the only response given was that "the DHT-DID [spec] uses Pkarr [a piece of software]" which makes no sense... specs depend on specs, not implementations. Then the issue derailed (as unthreaded discussions always do; github is why we can't have nice things) into some side tangent about KRPC and CBOR instead of answering the issue's question "why DNS?". Pretty sure the answer is "to leverage existing recursive resolver infrastructure" but you should state that clearly -- and then think through the consequences.