… when it works. And if you never have to change camera or microphone settings.
> and calendar integration.
The little notification that pops up telling you your meeting is about to start based on your calendar? The one you better not click in the first 5 or so seconds it's there, because then you'll end up with an error message that tells you absolutely nothing, have to go back to the chat, and try again?
No, installing apps is just genuinely bad UX, at least for me, because my password manager doesn't work in apps, and I have to manually generate and copy and paste password. If creators of the app are extra stupid, they make it so that you cannot paste into the password input, so I have to enter the generated password character by character.
And why is it broken? Is there a way for a password manager app to somehow inspect other apps and identify forms within them and interact with the forms?
...yes? I can't tell if you're trolling at this point or genuinely unaware.
Both iOS and Android have APIs for this, you (as the app developer) just mark the relevant fields in the app as login/password/etc, and the OS will interact with your chosen password manager to autofill and/or save them.
If you've never seen this work on your device, then you might have something configured incorrectly — many app developers are incompetent and bad at this; but not _all_ of them.
It works for filling an existing password, but not for creating a new one, iOS still prompts me to fill existing even though I'm on the sign up page. On the web 1Password can also automatically generate a Fastmail masked email address, but I doubt there's any hope for that to work in a native app.
I've flown with many European budget carriers and have never once seen this requirement. Sure, they might charge for or not provide printed boarding passes, but they've always sent me a PDF or PNG boarding pass by e-mail or provided one through their website. That, in my book, is a non-issue. Forcing an app is a huge issue, and shouldn't be legal if the only reasonable way to get the app is agreeing to the draconian conditions of one of two gatekeeping companies subject to foreign jurisdictions.
This is an insane take. Apple and Google both reserve the right to deny accounts to people without any legal appeal at worst. At best, a legal dispute would have to be resolved in US courts. How other countries (including my own) accept that as a condition to use public services is beyond belief, and pointing this out is not an overreaction.
Why are we willingly placing private companies – private companies subject to foreign jurisdictions, even! – in the role of gatekeepers of public services? We have surely completely lost our minds!
You can literally just use the online form. Have you actually tried using your search engine to query applying, and seeing just how easy it is to optionally apply online?
Over half of the world’s population is using an Android or iOS device. Most people visiting a country in the UK or have the means to afford a trip, most likely have a functioning mobile phone.
I find it somewhat amusing you think I’m “insane” for suggesting most of the modern world has a relatively accessible Android or iOS device to apply for a visa.
> You can literally just use the online form. Have you actually tried using your search engine to query applying, and seeing just how easy it is to optionally apply online?
This whole story is about how they're trying to pressure you into using the app.
> Over half of the world’s population is using an Android or iOS device. Most people visiting a country like the UK or have the means to afford a trip, most likely have a functioning mobile phone.
That does not in any way affect any of what I wrote. I'll try to write it differently: Do you think it's OK that Google and Apple decide (at worst on their very own without oversight, at best with the oversight of a foreign country that isn't the one you're travelling to or from) who gets to do these things and under what conditions?
> I find it someone amusing you think I’m “insane” for suggesting most of the modern world has a relatively accessible android or iOS device to apply for a visa.
I find it insane that you think that because Google and Apple happen to grace most people with access to Android and iOS, then it's fine that we all live by their mercy.
I’m sorry but I can’t respond further, conversation is going nowhere. You clearly have it out for Apple and Google, and you are not being “pressured” into doing anything.
Critical reading and thinking would lead you through the flow to click on the “continue application online” form.
I thought so too, but if you follow the 'start now' link you get a page full of trying to push you to use the app, then if you say you cannot all the way at the bottom, then you get another page trying to help you with installing the app, then you actually get the form. I'm quite disappointed, usually the UK government digital services are not quite so user-hostile.
There is also a new UK government requirement to verify your identity if you are a director or significant shareholder in a UK company.
The online route for that goes through a couple of pages then says "now switch to the app on your smartphone". In theory you can also go to a Post Office to get your documents checked but it didn't work for me.
It's insane that multi trillion government would rely on a foreign private entity for something so simple yet critical. The only sane answer here is corruption.
I do believe you, but I have to ask: what are these incredibly tedious "easy, time consuming parts of projects" everyone seems to bring up? Refactoring I can see, but I have a sense that's not what you mean here.
That's actually a great point. I feel like unless you know for sure that you will never need something again, nothing is disposable. I find myself diving into places I thought I would never care about again ALL the time.
Every single time I have vibe coded a project I cared about, letting the AI rip with mild code review and rigorous testing has bit me in the ass, without fail. It doesn't extend it in the taste that I want, things are clearly spiraling out of control, etc. Just satisfying some specs at the time of creation isn't enough. These things evolve, they're a living being.
In a simple text based game I'm vibe coding for fun, I created skills that help the specs evolve.
I started with chatgpt, I told it to make me a road map of game features.
Then I use that road map to guide my LLM (I use codex 5.3), with the specification — when working on tasks, if you learn anything that may be out of scope, add it to the road map.
There's a bit more to it than that, but so far I've got a playable game, and at some point the requirement of adding an admin dashboard for experiments got added to the road map, and that got implemented pretty well too.
At first I did review a lot of its code, but now I just let it rip and I've been happy with it thus far.
At work I use AI heavily but obviously since I'm responsible for whatever code I push I do actually review and test and understand, but mostly I just need to tweak some small things before it's good enough to ship.
For me, the answer to this question is: parts that involve no architectural decisions, and that won't need to be extended or built upon significantly in the future.
When I'm working on a greenfield project that I intend to build out further (which is what I am currently doing), I find that there's not a lot of work that fits those criteria. I expect that can change drastically when you're working on something that is either more mature, or more narrowly scoped (and thus won't need to be extended too much, meaning poor architectural decisions are not a big issue).
Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".
From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here.
Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc.
They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer protocol serialization semantics, you can't confuse a state machine, you can't have a concurrency bug[1] etc.
C memory safety vulnerabilities arise from trying to handle these dynamic things which rustls fixes.
(Also, there are third party crypto providers implemented in Rust)
[1] from memory safety pov; for side channels rust doesn't have advantages anyway
My point is that the article this thread is attached to starts out with how BoringSSL and AWS-LC won't cut it. And when rustls is suggested as an alternative, it's important to point out that it requires precisely those two (either one of them).
The article is about TLS. The arguments against those libs don't apply if using them just for the low level crypto algorithms. (Also of course rustls can use other crypto providers besides those)
Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".
The primitives aren't a problem. You can't write them in any vaguely modern high level language. And when I say "High level" I mean that the way K&R does when they describe their new C programming language as high level. The reason you can't write cryptographic primitives in a high level language is that optimising compilers love clever tricks which offer data dependent performance, across every layer of their design - but in cryptography we want constant execution time regardless of either the plaintext or keys used.
The problem with OpenSSL isn't these cryptographic primitives, that's why you will see basically the same primitives re-used in lots of different places. It's like finding out that the guy who was just arrested for murder also eats pizza. Yeah, people do that. The problem wasn't the pizza, it was the murder. OpenSSL's implementation of the AES cipher isn't broken, the problem is elsewhere.
Also, even if rustls is using aws-lc-rs, you still get the TLS parts from the rustls project, and aws-lc-rs is just lower-level crypto. That means there's less places for Amazon to say no; they either implement an algorithm or don't.
… when it works. And if you never have to change camera or microphone settings.
> and calendar integration.
The little notification that pops up telling you your meeting is about to start based on your calendar? The one you better not click in the first 5 or so seconds it's there, because then you'll end up with an error message that tells you absolutely nothing, have to go back to the chat, and try again?
No, it's not usable. For anything.
reply