Notices by Jeff Martin (cuchaz@gladtech.social)

It's 2025 and somehow getting the correct local time in a multi-threaded #Rust / #RustLang program just isn't possible.

Like ... seriously?

Yes, there are workarounds. You can get non-local times, or (sometimes) incorrect local times.

But the correct local time is always displayed on my screen 100% of the time already. Because clocks are a thing! And my code can't just ... get that somehow? This is pretty nuts.

@varx Haha, yeah. It's nuts. Let me see if I can dig up that explainer again. There was a good reddit thread somewhere ...

Ah, here it is:

https://old.reddit.com/r/rust/comments/qs7l6p/psa_the_time_crate_once_again_supports_obtaining/hkcqesv/

@varx Right! But that only works if the timezone doesn't change on you while the program is running. Which happens (at least) twice a year in many places on Earth.

There's hope tho.

In Mozilla's earlier days, they jettisoned a totally new web browser project called Servo. It's sort of a ground-up effort to build a browser using the latest safety tech, like the Rust programming language.

https://servo.org

And the best part is, Servo is totally independent from Mozilla now and they have * independent funding * !

Meaning, Google isn't bankrolling Servo as anti-trust insurance (*cough* Firefox *cough*), so there's a chance it might actually take a real stance against adtech on the web.

Servo is faaaar from ready for general use yet, but it's picking up development speed. Definitely an option to keep an eye on for the future. :blobcatthumbsup:

Yup, it's true. Firefox 128 includes new adtech features that are opt-in by default and announced with very little fanfare, so most people might not even know they're there. :blobcatverysad:

Well, this is me telling you they're there. You might want to go ahead and take a minute to opt out.

Here's the little helpful explainer from Mozilla about how it all works:

https://support.mozilla.org/en-US/kb/privacy-preserving-attribution

My read seems to be: Mozilla says website surveillance is generally bad and should be defended against. Cool. No notes. Firefox actually has a lot of nice anti-tracking and privacy features there and that's the main reason why I like Firefox.

But, and I swear I'm not even joking a little bit here, Mozilla goes on to say that advertisers might be happier if Firefox itself just tracked you directly and sent activity reports back to them.

Doesn't that sound great?

Now, to Mozilla's credit, they claim to anonymize the activity reports. And you can still meaningfully opt out of the whole system.

But WTF, mate?! I use Firefox *because* it fights against adtech. Or at least it used to. Now, Mozilla just lets adtech right in the front door and hopes you won't notice? :blobcat_thisisfine:

Well, we noticed. Mozilla is damage and we need to route around it.

Just installed a brand new Firefox on a brand new Linux computer (Linux Mint if you must know) and oof! I forgot how many "sponsored" things you need to turn off now.

I really wish Mozilla could figure their shit out and be financially independent without resorting to adtech. Seriously, where's the option to just donate to Firefox development?! And only Firefox development.

@me Oooh, a snac user! I've heard about snac, but never met anyone using it before. Good luck! I feel like there's definitely a lot of room for more lightweight instance software out there.

I ended up taking into a dive into the state of #Rust on the web this morning. Looks like lots of progress has been made since the last time I checked!

You can call browser APIs from Rust now thanks to efforts like wasm-bindgen and web-sys. It looks a bit clunky, but it's effective. And I wonder about the wasm->jsvm->native pipeline (and back) and its effect on performance. Seems like that jsvm layer doesn't need to be there, but we haven't gotten rid of it just yet.

So if you want to make a regular front-end web app in Rust? Go nuts, it'll probably work well enough. And things like Yew and Trunk even make it rather nice in DX terms.

But for my own projects mostly building privacy-respecting-apps-as-browser-extensions, it looks like Rust isn't quite ready yet, but it's close. The key missing piece seems to be access to browser extension APIs. There's a web-extensions-sys project, but it's only targeting manifest V3 for some reason, which means FireFox support is completely out.

Although I'd love to switch my front-end work to use Rust, looks like I'm stuck with javascript (and jsdoc) for now.

I've been writing #Rust for this many years now and today is the day I finally learned about Option.and_then().

I've always wanted a thing like flat_map() but for Option types, and apparently the stdlib has always had one, but I never found it until now.

The stdlib is a big place! :blobcatbook:

Not all new businesses are startups!

"Startup" only refers to new businesses that depend on investment and hyper-growth to eventually sell out to someone with even deeper pockets. In a startup, the company itself is the product. Customers are just part of the sale.

I like a term I heard from @aral for the other kind of small business though: stayup.

https://mastodon.ar.al/@aral/110916819655456408

A stayup isn't looking for an exit and may not even need investors. The product is the product, and a stayup just wants to keep existing so the product can keep existing for its customers too.

Howdy #cryptography friends,

Let's say I have 1000 friends (haha, I know, right?) and I want to send each of them a number. If I put all the numbers into a list and send the list to all my friends, that sort of works, but each friend won't know which number is theirs.

So I'd like some way to tag each number in the list so each friend can quickly tell which number is theirs, but no one else can. ie, something faster than linear time search through the list would be ideal, but I'd settle for something linear if the constants are small. Maybe something like string equality as the match operation, but not a decryption.

And if someone who isn't my friend sees the list with all the tagged numbers, they shouldn't be able to tell who any of my friends are by using the tags somehow.

Me and all my 1000 friends (lol, it's still funny) all have asymmetric keypairs, so we can use those.

Is this a well-studied problem that has a name I don't know about yet? Maybe there are special-purpose tools that are a good fit for this?

Or maybe there's some clever scheme using encryption that solves this? I feel like a deterministic encryption of some well-known message for each friend gets pretty close. Then add a list-level nonce to make it randomized for each list, but not each friend. Then a friend can do the deterministic encryption using the nonce and scan through the list pretty quickly to find their number. But my asymmetric encryption primitive is randomized, so I can't quite make it work that way unless I use a different primitive.

Although, if the message to be encrypted deterministically is well-known, and the goal is not actually to protect the message, that kind of suggests encryption is the wrong tool here. I'm looking for some kind of tag that is only recognizable by the holder of the private key.

Thoughts?

@varx yeah, it's a tricky problem. I'm currently looking into using k-anonymity to probabilistically anonymize the list. Ie, each recipient will have to do O(log(n)) checks to confirm their number, but an attacker will never be able to get an exact match.

Or set up some kind of shared secret or other anonymized id to use instead of the real id. This is actually a much simpler approach, but due do where the API layers land wrt ecapsulation, it's harder to design the software so each API layer makes sense.

Ugh, why is everything so difficult? :blobcat_thisisfine:

@varx Btw, another option is dropping support for RSA entirely which would give me access to ECDH. Getting a shared secret from two keypairs for free feels like a superpower and I don't know how to do that with RSA. It might be the most compelling reason I've seen yet for why ECC is better than RSA.

@varx ECC has a few quality-of-life improvements over RSA for sure. But if I tailor my schemes too closely to how ECC works, then my high-level stuff is less likely be compatible with the new post-quantum thing, or whatever the future best primitives end up being. The hope was that by supporting RSA and ECC at first, the high-level stuff would be more likely to survive future developments without breaking backwards compatibility. Ie, people with different key types should still be able to talk to each other. It's easy to forget to make that happen when there's only one key type.

@varx Oh snap. I think I poked a huge hole in my contact graph anonymity scheme. :blobcatverysad:

The senders can't be anonymous for ... reasons. But the hope was at least the recipients can be anonymous and that would be enough to prevent eavesdroppers from harvesting contact graphs.

Turns out I can anonymize message recipient lists all I want, but as soon as a recipient ever responds, their signature is on the response. A simple signature verification operation using a list of all known identities could very quickly reveal the responder's (and therefore the recipient's) identity.

I mean sure, I could setup shared secrets for every pair of identities to hide identity info from eavesdroppers, but managing that many secrets would be a huge pain in the ass. Do not want!

Ugh. Privacy is hard. I'm not sure contact graph anonymity is worth it anymore.

@varx oh for sure, those are definitely risks. No way to really know though. I'll just design it the best way I can think of and hope for the best. I'm betting that sticking to really basic applications like authenticated encryption and signing will get me pretty far. I was doing pretty great until I tried to do anonymous multi-recipient encryption. Think I've about got it though.

@silverpill Sorry, the documentation is practically non-existent at the moment.

But the way the extension works is: You generate your identity in the extension, which takes care of creating all the keys and such. Then you unlock your identity by entering your passphrase. While the identity is unlocked, you can send signing/encryption requests to it. They're all automatically approved while the identity is unlocked. If the identity is locked again, the requests are all denied.

The actual format of the ciphertexts and signed messages is probably unique to burger identities. It's designed so that both sender and recipient should be using libraries that implement the standard for burger identities. ie, having the sender write ciphertexts and signed messages according to some other non-burger standard is not supported.

The burger identity standard hasn't been written yet though. Right now, there are just two implementations of the library (JS and Rust) that have been written with standardization in mind, but that's as far as I've gotten.

Hope that helps!

@silverpill Awesome! That sounds really great. Let me know what I can do to help.

@silverpill Yes! The browser extension will be need to be updated, but it's lagging behind the identity implementation at the moment.

My short term plan is to work more on my P2P network using the new "App" identities which is all server stuff (in Rust) rather than client stuff. After that's done, I'll go back and update the browser side of things and work on more end-user facing stuff.

Ooof! I think I'm finally done with the big refactor/rewrite of the JS side of Burger Identities! :blobcatcheer: 🍔

Hopefully the high-level APIs should be damn near impossible to misuse now. And anything not high-level is hidden away (to the extent JS even allows), or otherwise clearly marked as not intended for applications to use.

Also, Domain Separation for All The Things! :allthethings:

Plus, Identities are separated into two different types now. "Personal" identities are for ... you know, people. "App" identities are for software and automated systems. They have different ways of protecting the private keys. Keys for personal identities are protected with passphrases. Keys for app identities need to be protected by access controls, since passphrases aren't a good fit there.

And finally, Identities get a kind of sibling called an "Anonym". An anonym is kind of like a symmetric version of an Identity, but without any of the identity metadata, like a name. An anonym lets anyone who has a copy of it communicate securely with each other. Anoynms are also extremely compact (about 36 bytes), so they can be easily transmitted over just about any channel, like a URL, a QR code, or even a phone call! Just send someone an anonym (securely), keep a copy for yourself, and boom! Instant secure messaging channel. Useful for bootstrapping initial identity exchanges, or for anonymizing communications between identities.

Now I just need to get the Rust side of the equation up to parity. Then I can finally use this stuff in my next project. :blobcatscience: