any notes or pointers on how to get comfortable with k8? For a simple nodejs app I was looking down the pm2 route but I wonder of learning k8 is just more future proof.
Use K3s in cluster mode, start doing. Cluster mode uses etcd instead of kine, kine is not good.
Configure the init flags to disable all controllers and other doodads, deploy them yourself with Helm. Helm sucks to work with but someone has already gone through the pain for you.
AI is GREAT at K8s since K8s has GREAT docs which has been trained on.
A good mental model is good: It's an API with a bunch of control loops
Definitely a big barrier to entry, my way was watching a friend spin up a cluster from scratch using yaml files and then copying his work. Nowadays you have claude next to you to guide you along, and you can even manage the entire cluster via claude code (risky, but not _that_ risky if you're careful). Get a VPS or dedicated box and spin up microk8s and give it a whirl! The effort you put in will pay off in the long run, in my humble opinion.
Use k9s (not a misspelling) and headlamp to observe your cluster if you need a gui.
if you are on a Zoom/video call, does anyone know if you would have to declare that your "recording" it? I'm thinking more from the legal perspective of wiretapping/consent laws. If you have live transcripts/subtitles does that change any legal requirement.
Yes, in my state it's generally illegal to take a screenshot of a zoom call without announcing you are recording the conversation. I'm not certain, but I think the issue is the storage of the 1fps video, not the AI summary.
regarding data collection, both android and ios provide multiple ways to review, approve/deny, and manage access to data. it's certainly not perfect but is being constantly improved. And for the HN crowd, you can always run mobile security/privacy tools like mobSF to inspect the app. I'm not suggesting we should have to do this but we can and frankly browser fingerprinting is opaque, also constantly evolving and quite good at tracking and data collection. i'm not sure avoid the better ux of a native app is much worse and given the privacy tools and data available, I generally prefer the native app
If you want to be alerted to new/updated SEC cybersecurity filings, you can subscribe to my free alerts [1] or see the full index of cybersecurity incidents [2] on my tracker (I check SEC EDGAR every 5 mins).
Jonathan Sawday’s 2023 book “Blanks, Print, Space, and Void in English Renaissance Literature: An Archaeology of Absence.” [1] explores this phenomenon as well across multiple mediums.
It also won the Modern Language Association's top award — the James Russell Lowell Prize for the most outstanding book published in 2023.
This is exactly how we built viaForensics in 2009. For the first five years, we performed mobile forensic investigations and gave trainings based on the Android and iOS forensic books we wrote. We were able to self fund software development for the first five years. When we moved from forensics to mobile app security, we required more capital to build our automated software which led to our Series A.
Having an established business with customers in revenue, obviously significantly helps in the fundraising process and evaluation. The other huge advantage is you can benefit significantly from the Qualified Small Business Stock statute which provide an exemption/shield on federal taxes when you sell that is the _greater of_ either $10m or 10x times your valuation at the time of funding.
We analyzed the iOS app[1] and observed similar traffic as well as a number of basic security issues (hardcoded encryption keys, use of 3DES and some traffic over HTTP).
Thanks for writing this article! I quite enjoyed it.
question: does the DeepSeek's app use of hardcoded encryption keys rise beyond just their attempt to obfuscate and protect their app's private API endpoints? I believe this an attempt to make abusing their mobile app's private web APIs more difficult since even with cert-pinning disabled and HTTPS MITM'd you still can't observe the real traffic and replicate their requests.
If all its doing is obfuscation though, then I don't understand why pointing out that the keys are hardcoded is meaningful. It certainly doesn't engender trust. But if the app's binary is ultimately decoding some encrypted data, it needs the key, meaning it's ultimately available to the reverse engineer. Whether it's hardcoded or not doesn't matter.
It's a bad look, but if the app used the latest tech and assigned each client its own symmetric encryption key for a session, wouldn't you still be able to access the same data? What would be meaningfully different from a security perspective if they had done this obfuscation better?
Apple disallowed HTTP by default, you can flip a bit in the config to allowlist some/all endpoints to HTTP. Not clear what the App Store actually does when reviewing this info when you submit.
Despite their goal of enforcing in 2017, it is still not a hard requirement. Back then, about 80% of the apps we tested disabled ATS either partially or fully [1]. It’s rare to see Apple walk something back [2], but here is a blog at the time that talked about it [3].
Yes, the Android app has multiple vulnerabilities but we focused this report on iOS (it took nearly 40 hours to write the report). Our recommendation is people avoid using the mobile apps. If you want to test the model, I'd suggest Hugging Face/ollama or a hosted solution (multiple companies are now offering that).
