geogriffin's comments

FWIW, you can write the conditional compilation example like so:

  fn read_keys(#[cfg(feature = "splitapple")]
               port: nrf52840_hal::pac::P1,
               #[cfg(feature = "keytron")]
               port: nrf52833_hal::pac::P0) -> Packet {}

I suppose the compiler could try to suggest that as a fix.

Answering my own question.. A cryptographer friend offered an answer to this question: The network operator may be the same as or colluding with the target resolver, defeating the anonymization of the proxy.

Once we say we need encryption on the first hop, then I can see the logic in using a stateless protocol instead of TLS for the second hop, to avoid TLS-in-TLS and all the round trips associated with that.

Side note: It'd be cool if these new protocols used the more generic Noise Protocol Framework [1] instead of a custom, more specialized protocol they just came up with like HPKE [2].

[1] http://noiseprotocol.org/noise.html [2] https://www.ietf.org/id/draft-irtf-cfrg-hpke-06.txt

Why encrypt the first hop? Why isn't this just plain DoH with a simple CONNECT forward proxy to 1.1.1.1, like Signal's Giphy proxy [1]?

[1] https://signal.org/blog/signal-and-giphy-update/

The Plundervolt [1] paper is one study in what exactly goes haywire when a processor is undervolted. They found that the computation errors induced are quite consistent and reproducible. MUL and DIV are vulnerable, and AES-NI happened to be particularly badly broken in the face of undervolting.

[1] https://plundervolt.com/

I think it's just more clear that they are listing pronouns, especially if someone isn't familiar with the practice or in verbal speech. Also note that some people use two sets of pronouns, with equal weight, and may list them such as "she/they".

well.. there is CONFIG_PREEMPT and the even broader CONFIG_PREEMPT_RT in linux [1].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> After our investigation, we immediately made a number of changes to this endpoint so that it could no longer return specific account names in response to queries.

Does anyone know what this actually means? If the contact discovery API doesn't return a username, what does it do? If the answer is that it returns a user ID now instead of username, then presumably that can then be freely queried for the corresponding username..

Phone numbers are useful for exactly the reasons you find them frustrating: stability -- as you said, everyone and everything you associate with can and will store and contact you via your phone number indefinitely -- and portability -- everyone accepts and understands phone numbers, modulo international dialing.

Sure, something could and maybe should replace phone numbers, as the system is definitely messy wrt international dialing and countries changing numbering plans.. But the thing that replaces phone numbers in their usefulness will bring the same frustrations you express.

Email has mostly the same characteristics, especially for non-computer-people. My parents were paying $10/mo for dialup up to ten years after switching to DSL and Gmail, just to keep their old email address. I bring that up not to point out the extortion -- email could theoretically have had address providers decoupled from hosting provider through DNS, if it had been made user-friendly -- but to point out the value in the stable identifier. I know this is an anecdote, but the story of AOL email is similar, that 2.5 million people [1] were still paying $20/mo for their dialup and bundled email when "some of whom" (sorry there's no better information on this) had since switched to a different ISP, but kept paying AOL to keep the email.

> I even had to send them a government issued photo ID recently so I could keep the number.

Governments will always want to link users to their stable identifiers. It's in their policing interest, for better or worse. Switching away from phone numbers will just shift the problem.

[1] https://consumerist.com/2013/08/08/believe-it-or-not-2-58-mi...

> ... do not make it explicitly clear that the final solution sends a hash-prefixed password

I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs."

IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).

> 2. It is regularly carried on - not really, there's only one .org domain so one can't regularly sell it.

You're right. I misread #2 as the inverse so misunderstood what UBI was.

> 3. It is not substantially related to furthering the exempt purpose of the organization - that one would be the toughest to prove...

Kinda a moot point given #2, but the IRS elaborates (emphasis mine), "... only when the conduct of the business activities has causal relationship to achieving exempt purposes (_other than through the production of income_)"

Well, reading the IRS guidelines on what qualifies as UBI, it seems like it might fall under that category, but I'm also not an expert, which is why I'm asking for a more qualified opinion. However, assuming it's UBI, it's pretty clear to me that having a large percentage of their income this year being UBI would be a red flag to the IRS.

I agree. Becoming and staying a non-profit is harder than you'd think. The IRS's rules are vague and subjective. This is specifically what I'm talking about: "If unrelated business income comprises a 'substantial' portion of an exempt organization's income, loss of tax-exempt status may result" [1].

[1] https://www.hurwitassociates.com/taxation-of-unrelated-busin...

Does anyone have a clue if they'll manage to keep their 501(c)(3) status with $1.1 billion in profit for 2019? My understanding is that profits like this unrelated to their normal business activies are taxable, and may also cause the IRS to reconsider their non-profit status and/or levy penalties [1].

[1] https://www.irs.gov/charities-non-profits/unrelated-business...

I see your point. Especially since cost-based KDFs rely on the predicted characteristics of future hardware.

I think if my password is worth 17.5 trillion CPU seconds then I'm a very lucky person...

Exactly, 1000 guesses per second is probably a reasonable target to tune your KDF's difficulty to, depending on of course the application and the amount of resources you're willing to dedicate to running the KDF on every login..

If passphrases are easier to remember, then it may be possible for a human to be able to recall many such passphrases at the same time. If these passphrases are used for services with any sort of auth rate-limiting, and they aren't reused between services, then the difficulty of reversing their hashes isn't really a problem.

Am I missing something, or is the reason most of the queries observed have low TTL because, well, they have a low TTL? IOW, the higher TTL responses would be cached downstream and so you'd see them less often. If that is the case, the distribution shown is not all that surprising.

Doesn't something like jemalloc basically give you this, but without pauses? Thread-local freelists for quick recycling of small allocations without synchronization.. funnily enough, jemalloc even uses some garbage collection mechanisms internally.

True, and it seems as though to avoid this kind of litigation Ticketmaster simply had to disclose more information about the purpose and intent of the fees in the fine print. I also remember them changing the name "processing fee" to "convenience charge" maybe 10 years ago as result of (maybe this) lawsuit, but I can't find anything about that now.