I think that can pretty realistically be done with Gemma or Qwen, although maybe with some delay. They run great on android in the Edge Gallery app.
Further, you could allow for voice input by running whisper STT locally, then doing a small context-aware correction pass with Gemma or Qwen to correct words it got wrong.
The issue with those solutions is that it would balloon my app size because I'd need to embed the model, or add a mechanism to download the models afterwards, for something that is essentially a note taking app. But maybe I can make it an option and word it effectively, that is an idea!
Your idea for doing a context aware correction pass on STT is very interesting and something I hadn't thought of yet.
Thank you for your thoughts!
I use libvirt, vfio pci passthrough, evdev and some other stuff and have been smoothly VM gaming for a few years. Mostly just followed the arch wiki when I set it up back then.
I get throwing in the towel with all these issues but I personally didn't encounter half of them.
From the article not everything is fully clear to me yet.
What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962.
The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof!
So, someone can do inclusion and consistency proofs. If a log presents a split view that should be noticable through gossiping. But what gossiping is implemented? I think the only gossiping that happens is in the CT Google group/mailing list that probably few people know of.
Then, what if you want to actually detect malicious or misissued certs for your domain? Ideally you want to do it yourself and not use some service. Probably you just have one server and IP. Now you have to download insane amounts of data from ~60 logs and hope that someone else is checking the consistency and correctness of those logs. And you have to scrape those logs faster than they grow. Now, what if everyone running a web server did monitor? Even static logs probably couldn't withstand that.
Next, what about the log lists? One can talk all about sovereignty but really you rely on and have to trust Apple and Google with their policies and log lists if you want to meaningfully participate in this system and by extension, the encrypted web...
CT is fully deployed to production but still has many design flaws and things that are still just theoretical. It seems many of them are addressed by MTCs. I hope it can be better.
The one thing I didn't see addressed is the gossiping thing. Couldn't a malicious CA still present a split view under this model?
And if I'll have to rely on mirrors then I still can't independently monitor.
Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised.
There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.
CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.
Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.
Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".
Okay that choice of words was a bit harsh. My struggles are partly also due to logs barely complying, that I can't even monitor as quickly as they grow from one IP (mainly looking at you, trustasia, though at least there now is a static log).
Thank you for the explanations. I think I should read the draft RFC.
The last part of your comment caught my attention, seems great if that is being worked on. Can I find more information on it somewhere?
Ah! Good question: Google's non-open-weights models (Gemini, etc) have almost always outperformed on image recognition tasks compared to any other models. I use a mix of in-house and Gemini for image classification tasks for $startup. No other models have done as well, and I had hoped that some of that would spill over into their open source models. It does to a degree - bigger Gemma models are okay.
It has certainly not been well-publicised that it is available on Mac and iOS but you are right, likely I just missed this news.
The combination of these things, though, I still think is significant. It’s a product from an old-fashioned (!) FAANG that installs as easily as Chrome, downloads a model as easily as it could be, combines a chat interface with audio and video analysis/transcription, has a customisable system prompt, MTP, agent skills support etc.
Now, it is from Google so they could kill it when they get bored!
But clearly this is local AI packaged in a really accessible format, and the model seems quite capable for its size. It is something Microsoft could do when they can really point to easy consumer hardware that can do it well. It’s certainly something Apple could do better with their distillations of Gemini under the Google deal.
I think a sane line of enquiry for a tech journalist is: 1) doesn’t this threaten the appeal of consumer-tier subscriptions to ChatGPT (which is a big part of OpenAI’s revenue plans), and 2) is it therefore not questionable that the buy-and-hold economics of DRAM, SSD and GPU products that OpenAI benefits from having provoked into causing ridiculous price increases is fundamentally anti-consumer?
reply