Readit Newsmtud commented on Show HN: ShellAI – Local Terminal Assistance with SLM github.com/micrictor/shel... · Posted by u/mtud
This is really cool - so it uses Gemma SLM? Why can't you just package that here into GitHub?
And why is `ptrace` needed?
The model file is small enough to have in Git (safetensors is only 600MB) but the Gemma TOS make me unsure if I’m required to have the same “Read and accept the Gemma TOS” limitation that they have on their public huggingface model.
As for ptrace, I use it to inject code into the users shell to present the command in a way that doesn’t require further interaction to run. I wanted it to be more like the “AI terminal” experience without requiring the user to copy-paste the recommended command back into their shell prompt.
If your browser is online on an unrestricted network, then the tree heads will be kept up to date, and this will leak nothing. If you had your laptop closer for a weekend, open it up immediately and visit a website before your browser had a chance to update, well, you leak for maybe a minute or two you had your laptop closed for a weekend. So it's not that much. But we'll want to see how we can reduce this as much as possible.
It can't possibly be updating continuously in real time, can it? Especially for battery devices, a constant background thread polling for updates seems untenable.
> During the TLS handshake, the client tells the server which treeheads it has.
I don’t love the idea of giving every server I connect to via TLS the ability to fingerprint me by how recently (or not) I’ve fetched MTC treeheads. Even worse if this is in client hello, where anyone on the network path can view it either per connection or for my DoH requests to bootstrap encrypted client hello.
Using The Approved Set™ from your browser or OS carries no privacy issues: it's just another little bit of data your machine pulls down from some mothership periodically, along with everyone else. There's nothing distinguishing you from anyone else there.
You may want to pull landmarks from CAs outside of The Approved Set™ for inclusion in what your machine trusts, and this means you'll need data from somewhere else periodically. All the usual privacy concerns over how you get what from where apply; if you're doing a web transaction a third party may be able to see your DNS lookup, your connection to port 443, and the amount of traffic you exchange, but they shouldn't be able to see what you asked for or what you go. Your OS or browser can snitch on you as normal, though.
I don't personally see any new privacy threats, but I may not have considered all angles.
Different machines will need to have variations in when they grab updates to avoid thundering herd problems.
I could see the list of client-supplied available roots being added to client fingerprinting code for passive monitoring (e.g. JA4) if it’s in the client hello, or for the benefit of just the server if it’s encrypted in transit.
mtud commented on Show HN: An Almost Free, Open Source TURN Server github.com/lvidgen/WebRTC... · Posted by u/cookie_monsta
Authentication still requires the client to have access to the password, where you can just take it and use it for any other purpose.
Unless you're asking every user to manually input a TURN password and they promise not to give it out, you're basically forced to reveal it to every visitor of your site.
You can generate short-lived and single-use credentials for users.
mtud commented on Show HN: An Almost Free, Open Source TURN Server github.com/lvidgen/WebRTC... · Posted by u/cookie_monsta
Oh I thought TURN was mainly about the NAT traversal. Can you elaborate on the other points? Especially security and privacy?
Without TURN, two clients that want to do streaming communication connect directly to each other, letting both ends know things like IP addresses, supported protocols, and other fingerprintable features. This was the norm for a long time - “I got your IP, I know where you live”
mtud commented on Alphabet spins out Taara – Internet over lasers x.company/blog/posts/taar... · Posted by u/tadeegan
I'm low key afraid that this stuff is gonna get popular for .mil usage.
Line of sight free space optics can be immune to many many forms of jamming. Its usage dots the sci books I've read over the years, but almost always for scary reasons.
Here's the Navy today announcing work on AirBorne System for Optical Relay and Broadcast (ABSORB), a (for now) low-cost prototype one-to-many (I maybe mis-inferring what multi-access means?) relayable free space system, https://defence-blog.com/us-navy-plans-to-revolutionize-nava...
The U.S. Naval Research Lab (NRL) has been deploying this tech - free space optics (FSO) - for about a decade.
https://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=555...
Spitballing here, would it still meet the needs of the protocol if the client offered which MTCAs it has (no version information), the server sends back some “typical” depth (say, 3 levels up the tree), then the client can decide to either: * Accept the MTC * Request a deeper traversal, following some super linear growth like fib numbers. In that case, they’d communicate “give me up to 5 nodes above your leaf” * Reject the MTC * Request the full certificate for “traditional” validation
The server still has a side channel for “how recently updated is this client” by knowing how many levels of inclusion proofs needed to be shared, but this is much less signal than knowing exactly which landmarks a client has.