d-z-m

14 ms·

151.
by d-z-m 3y ago
I take a slightly different approach. I also have two profiles, but I almost never use the "just make it work" profile, because I can basically do everything I want to do with my main profile. The main profile has two extensions,
152.
by d-z-m 3y ago
> San Francisco is[...] one of the most unequal places in the universe, both socially and economically. Economically, agreed. However, to say that SF, one of the most progressive cities on the planet, is one of the most "unequal pla
153.
by d-z-m 3y ago
That's not the main issue I see with serving unencrypted HTTP. The bigger issue is that it's a vector attackers can use to deliver malware, as the entire response can be hijacked.
154.
by d-z-m 3y ago
The fact that this site doesn't serve HTTPS(correctly) remains a head-scratcher for me. The certificate isn't valid for paulgraham.com , hence the error. It is valid for *.store.turbify.com , among other SANs, which seems to in
155.
by d-z-m 3y ago
I had thought about including an additional sentence in my comment that admitted that attacks on e-voting would scale more easily, but decided against it. I'm taking issue with the way the article implies the insider threat problem is
156.
by d-z-m 3y ago
I agree, it's more easy to do at scale with e-voting. I wonder if you could mitigate this by having(in the US at least), county-local voting portals which are independently managed, and then collated into some larger vote bucket for s
157.
by d-z-m 3y ago
> > Like any internet voting system, it has inherent security vulnerabilities: if there are malicious insiders, they can corrupt the vote count Malicious insiders can always corrupt the vote count. This isn't unique to e-voting
158.
by d-z-m 3y ago
> As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice. This has always resulted in a panic[0]. [0]: https://cs.opensource.google/go/go/+
159.
by d-z-m 3y ago
You're using a different definition of "hallucination" than the one most people use when talking about LLMs. If you want to do that that's fine, but you're definitely in the minority.
160.
by d-z-m 3y ago
> Everything from LLMs are hallucinations. People use the term "hallucination" to refer to output from LLMs that is factually incorrect. So if the LLM says "Water is two parts hydrogen and one part oxygen" that is n
161.
by d-z-m 3y ago
> DJB is literally claiming the NSA is claiming something similar to "3 + 3 = 9". Nit: DJB is claiming that NIST is doing that, not NSA. > There's a paywall in front of the article turning javascript off gets around the
162.
by d-z-m 3y ago
In this case, we're using the term "cross-vendor transferable" to mean that the key material can be exported out of one vendor and imported into another. So if you could export the passkey from Windows Hello and import it in
163.
by d-z-m 3y ago
Scrollbars getting smaller was something I was noticing subconsciously, but was happening slowly enough that I was getting frog-boiled. Now they're annoying me even more than usual :^).
164.
by d-z-m 3y ago
Ironically, the style and substance of DJB's engagement with his peers and with NIST is likely to sour both against his claims[0], credible though they(might) be. DJB's impression of NIST "stonewalling" could very well
165.
by d-z-m 3y ago
To me, it's unclear what the headache is. If the argument is about the consequences of passkeys for most ordinary people, most people are signed into their google account on their mobile device. In that case, your account is compromi
166.
by d-z-m 3y ago
OP specifically mentions "cross-vendor" transferable. Which, to my understanding, is currently true.
167.
by d-z-m 3y ago
> I lost my patience to "converse curiously" with people When this happens, simply refrain from commenting until you regain that patience. This forum only remains civil if we all make our best effort to keep it that way.
168.
by d-z-m 3y ago
related: https://highassurance.rs/
169.
by d-z-m 3y ago
> Converse curiously. From the guidelines. For those interested in diving deeper on the topic of crime in California: [0]: https://www.ppic.org/publication/crime-trends-in-california/ [1]: https://da
170.
by d-z-m 3y ago
> And there are bit flags in the encoder instructions that carry header values that signal they should never be inserted into a dynamic table. My understanding is that these header values have to be known to the Qpack implementation befo
171.
by d-z-m 3y ago
I believe that qpack(like hpack) still has some sharp edges. As in...low entropy headers are still vulnerable to leakage via a CRIME[0] style attack on the HTTP/3 header compression. In practice, high entropy headers aren't vulner
172.
by d-z-m 3y ago
Darn those typo squatters!
173.
by d-z-m 3y ago
DoH makes the request look like a regular HTTPS request, therefore you'd need more sophisticated heuristics to block it. If you contend that you can match the DoH SNI with a known DoH server and block that, fair enough. However, there
174.
by d-z-m 3y ago
I'd say the data is pretty normal.
175.
by d-z-m 3y ago
> With new tech like blockchain for decentralized coordination Can you elaborate on the applicability of the blockchain to CRFD's mission? They don't seem to be in the business of decentralized coordination.
176.
by d-z-m 3y ago
> If we can't read it without privacy extensions, it doesn't work. What doesn't work?
177.
by d-z-m 3y ago
Yes it is.
178.
by d-z-m 3y ago
It's harder to block.
179.
by d-z-m 3y ago
Sounds kind of similar to [0]. TL;DR: stealth secondary DH key exchange in the nonce field of Client/Server Hello in TLS 1.3. [0]: https://eprint.iacr.org/2023/651.pdf
180.
by d-z-m 3y ago
> If it's an HTTPS connection over 443 going to a know DNS server, then it's probably a DNS request, thus I don't see added privacy here. The ISP doesn't see the DNS request, therefore added privacy(you are presumably

More ›