I always think about the Samsung SyncMaster 173P I used to have once. It was good for its time, but not usable with any kind of subpixel antialiasing (even on Gnome which allowed to you to choose between horizontal and vertical RGB and BGR): the subpixel grid on it was diagonal. Absolutely tractable as far as the signal-processing math, yet would be unlikely to fit in any reasonable protocol.
There are 2^32 multipliers; call them m. For a bit in m*x to be useful, it must be zero for 16 symbols and one for 16 symbols. Call those bits "useful bits." Try every multiplier; for each multiplier, compute all the useful bits (usually not many) and try all masks with 5 useful bits.
Seriously though, can a ESP32-S3 Reverse TFT Feather[1] (dual-core Xtensa @ 240 MHz, 512KB built-in RAM, 2MB external PSRAM, 4MB Flash) play Doom? As usual with these microcontroller-type things, it looks like storage poses a harder limit than compute, but maybe just a bit of Doom could be crammed in?
I’m tempted to emulate a conventional SIMD solution and go with a small lookup table:
uint8_t classify(uint8_t c) {
return c - (0x5F45452B2B210000ULL >> ((c & 0x70) >> 1));
}
The AND-then-shift sequence on the right is annoying and it feels like one should be able to avoid it, but I don’t see how. Overall, this is more expensive than it looks—neither a full 64-bit constant nor a variable 64-bit shift are exactly free. So I’m probably missing something here.
Unfortunately, modern cryptographers refuse to design systems for confidentiality of store-and-forward communications, motivated by the fact that one can provide better security in instant messaging[1] (which in most cases implies vendor lock-in). Age is one of the few systems that could accomodate email, and its author’s “solution”[2] is for the user do ASCII armor/dearmor like a caveman, which handily loses to PGP/MIME in just about every email client that supports the latter. So, until somebody does better, PGP email it is.
I don’t really want to make a moral argument about PGP. Yes, the design of PGP is bad even if we hold its problem statement fixed. The thing is, the people I would trust to design something better consider that problem not worth solving. So if I as a user do want a solution to that problem[1], I’m stuck with PGP, which is bad. But at least it makes an attempt.
[1] Because I need to be in areas with bad connectivity often enough that I don’t want my every communication method to require a Internet connection to be available continuously (or even daily). Because Signal’s refusal to issue me an account without a phone number (which I cannot legally obtain without tying it to my government ID) is a real risk to my personal safety, given my particular situation. Because Signal’s stance on alternative implementations and the like is a hair’s breadth away from my refusing to use it. Some of these you could call moral arguments, but none of them are about PGP, as such.
The basic thesis of that post (the original of which I wrote) is that if messages are important enough that they need to be protected from state-level adversaries, then they're important enough that you shouldn't care about all the other reasons you like SMTP. If any of SMTP's affordances trump message security, you're LARPing the security part: you're protecting them in a threat model that doesn't correspond to a real-world attacker.
With email, you necessarily leak the triple (to, from, date): no matter how good your cryptosystem is, that information can be pulled from the mailserver logs (and if you don't leak that triple, spam deluge is unsolvable). As a practical matter, you generally need to leak the mail headers as well, which contains a decent amount of useful metadata as well. Now I'm not an expert on how spy agencies do their analysis, but my understanding is that the set of information that has to be leaked by email is already the most useful information for them. And that's part of tptacek's point: if your main threat adversary is state-level actors, you've already lost if you're using email simply because you're using email.
What if your threat model isn't state-level actors? Well, the baseline of email these days is that your communication and your recipient's communication to the mail servers are both encrypted with TLS. The mail servers themselves may or may not communicate with each other using TLS, but if you really care about security, you can choose a mail server which will be using TLS. In other words, email is already at a baseline state of the only people aware of the message being the sender, the recipient, and their mail admins (and whomever these people choose to leak the message to, perhaps unwillingly). Encrypting email will only remove the mail admins from the list, and even then, they can still tell anybody whom you talked about.
So the use case of encrypted email boils down to wanting to hide the contents of communication but not hiding the fact of communication itself. Which isn't a broad use case; the best examples I've found in my own life is something like financial statements, but even in those cases, there's a pretty decent workaround: send an email saying "hi, we have a document for you online in our usual secure file repository" (protected by modern, useful standards for secure files). I don't like that only because I can't automate saving those files off to my own storage for my own purposes, but that is such a niche desire that I can understand why the bank doesn't bother.
The original version of this post also mentioned, and was in fact motivated by, a fatal flaw in encrypted email that everyone who has used it at scale has experienced, which is that participants will reply to encrypted messages with unencrypted responses that quote the original (whether or not a reply quotes the original doesn't change how devastating this problem is, but sort of highlights how insane the system is).
So I think the metadata argument is dispositive. I agree with you that it's difficult to compose a coherent threat model that leaves metadata exposed the way SMTP does.
But the core argument of the piece is that encrypted email makes security concessions nobody would make if e.g. the wire for the down payment on their house was at stake, or if they were organizing against an oppressive state-level adversary. If encrypted email is unsuitable for those scenarios, then it seems more important to keep it from being used there than it does to accommodate the interests of people who using it for other reasons.
I once encountered a podcast’s Atom feed that included an <?xml-stylesheet ?> reference to an XSLT stylesheet, so when opened in a browser the feed became a decently laid out list of episodes, complete with <audio> tags to listen to them in place. And there’s nothing even the slightest bit hackish about it, in contrast to the usual polyglots like the one in TFA, but somehow it had never occurred to me that you could do that. Your reference to JSON-LD feels similar.
(In general, XML stylesheets leave me conflicted. It’s a nice idea, in principle, but I do not really see a way it could fit into a frontend with more than the slightest amount of interactivity. Also, I’ve lived through the absolute misery that was rebuilding the hefty Nixpkgs manual on every system update using the—quadratic—DocBook stylesheets, and I don’t want to go back to that.)
It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second necessary to get smooth touch scrolling at these screen resolutions.
The demos only show a very limited array of shapes. Precompute the refraction, store the result in a texture, and the gist should be sample(blur(background), sample(refraction, point)). Probably a bit more complicated than this—I’m no magician of the kind that’s needed to devise cheap graphics tricks like this—but the computational effort should be in that ballpark. Compared to on-device language models and such, I wouldn’t be worried.
(Also, do I need to remind you of the absolute disdain directed by 95/98/Me/2000 users at the “toy” default theme of XP? And it was a bit silly, to be honest. It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness.)
> It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness
Great observation! We need some of that sillyness back. Everything is all serious and corporate nowadays, even 'fun' stuff like social media or games. Even movies can't be silly anymore.
Not sure about 'serious and corporate', the big corps like to appear cute, folksy etc. and recently we even saw new Google Material Design advertised as judged more "rebellious" by focus groups. Maybe bland and toothless is just a general direction of contemporary culture and style that they follow.
Myself, I can appreciate corporate stuff presenting corporate. More truthful, feels a little less manipulative.
>It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second
Okay, but what about the battery connected to the GPU? The battery in my iPhone has already degraded below 80% health in the 2.7 years I've had it, so I'd rather not waste its charge on low-contrast glass effects.
Compiler errors won’t cause as many funny consequences with
gcc "$0" -o "$@".out && exec ./"$@".out || exit $? # I'd use ${0%.c} not $@
Love this trick too, but the difference, as far as I understand, is that it only works with a Bourne(-compatible) shell, whereas shebangs or binfmt_misc also work with exec().
Quite expensive, but it should only ever be a last resort after your local backups have all failed in some way or another. For $1/mo/TB you purchase the opportunity to pay an exorbitant amount to recover from an otherwise catastrophic situation.
> We really need to do something about social security numbers.
Get everybody to realize that identifiers and credentials are pretty much polar opposites in design space? Sounds like one of the many impossible infosec literacy crusades, unfortunately.
Meanwhile Switzerland is implementing e-ID which gives citizens private and public keys so they can sign and prove things without leaking their whole identity.
The USPS, with their existing delivery infrastructure and massive presence, would be a great fit for doing this in the US. Think like DoD CAC cards, but for ordinary citizens.
reply