It does when I log in. You click "Try another way" and then it brings up a menu of options you have for 2FA. For some reason they have designed the account recovery flow to be different.
So, if you are used to the "Try another way" flow on login, it can be confusing to see an entirely different "Try another way" flow on account recovery.
The time is ripening to disrupt Android/iOS. The place to start would be to rethink the device around AI. No need for apps or messy integrations with third-party crap. Just a simple device with a great new UX (not typing on a touchpad!) that is slick and does a few things very well (personal agent, coordinating with your personal knowledge base, handling external communications and your interface with the world). This could very easily supplant a phone.
AI is rapidly getting to such a place where the you don't really need a developer ecosystem to get your device off the ground. As "plugins" into your agent at some later point -- sure, why not.
You want a phone that "does a few things very well" and then you list "personal agent" and "your interface with the world". This would encompass everything anyone does with a phone, except maybe interacting with creative media (video games, ebooks). That's the exact opposite of "a few things". I think you're confusing actual functionality with AI marketing phrases.
The problem is that although what most people use on a daily basis is small nearly everyone uses something unusual app for _something_. I think it would be quite hard to find a market large enough that didn’t include such people.
There is a solution sitting there, which is running Android and having the AI run it behind the scenes I guess, but is suspect that would end up looking a lot like we have now.
This is the fundamental problem with all of these hypothetical new devices. If you assume you can come up with some new UI or innovative interaction model, maybe it’s purely voice or whatever else, then you have to ask if this could just run on a phone.
Modern smartphones won’t be supplanted by tech that could just run on a phone. That doesn’t make any sense. For any new tech to take off and replace phones, it has to provide something that isn’t simply additive to the phone. Otherwise, it just makes more sense to build it into the existing phone.
“A phone, but it has AI and no apps” isn’t even additive. It’s purely a loss of functionality.
> “A phone, but it has AI and no apps” isn’t even additive. It’s purely a loss of functionality.
I don't necessarily agree that “A phone, but it has AI and no apps” is a good product, but it could be considered additive.
When the iPhone came out, it was "a pocket computer, but without a physical keyboard and mouse" and some might have argued that it was subtractive because of that. Maybe we shouldn't be thinking about "apps" as something inherently required by any future device ever created.
The loss of the physical keyboard was indeed actually a loss, but was offset by meaningful improvements.
My problem with most of these proposed devices is that they are purely subtractive. I can run ChatGPT or Claude or whatever on my phone right now. Where is the part where a new type of device delivers some new experience or capability?
The problem with third party audits is that it allows OAI/Ant to shrug off any further responsibility and claim that they are following best practices (basically, reward hacking). The only real solution is to make them absorb liability for the actions of their agents -- because they are the ones giving agency to their models and allowing them to run amok.
Why wouldn’t this same concept apply to whoever is serving it up? Open-weight models are still being served up by infra providers and neoclouds, right? They should be in the hot seat. Not sure? Don’t provide the model. Need assurance? A certified evaluation like the previous comments have mentioned can help. Hosting and running it yourself? You’re in the hot seat.
So is there no liability for, say, a company that releases a known dangerous open-weight model, but fails to disclose that it is dangerous? How about a company that distributes malware under the guise of legitimate software?
Perhaps don't deploy random weights of unknown origin?
Also not every model provider might be capable of babysitting all your uncontrolled agent deployments. If you want SLOs, get into a contractual relationship with entities whose weights you deploy, and also monitor your agents so they don't go off the rails.
All this is just like deploying any other tech in the world eg. if you buy a car, or a chainsaw, or a book.
> Source? How do you know they were "prompted to hack to get answers"? How do you guarantee they will always listen to you when you say "do not hack outside systems". They are not classical deterministic programs doing exactly what you say. They are trained to follow orders by RL, but it's not a perfect process.
Who gives a shit? Not my circus; not my monkeys! It's the responsibility of whoever deploys the agents that they are instructed / sandboxed well enough that they can't cause collateral damage. That is the only way this doesn't get out of hand with everybody deploying their agents / robots for a world of utter chaos.
It is impossible (and asinine) to audit every model and deployment; far better to impose liability and the the socio-legal system figure it out.
What about inference providers like Baseten, Modal, Fireworks, Together, etc? I thought one of their value propositions was inference (using open weights models) that guarantees with crisp terms that they will not use your data.
I worked very briefly at Baseten, and I can say that it was a perpetual annoyance (from an engineering perspective) that customers would complain about issues with their models but we couldn't actually see the inputs/outputs. I don't know about the other providers, but at Baseten they literally weren't stored anywhere.
A provider can genuinely avoid storing inputs, as the Baseten engineer below describes. That is still different from proving what code received the prompt or protecting plaintext while it runs; I built TrustedRouter to separate ZDR, attestation, and confidential routes: https://trustedrouter.com/blog/attestation-is-all-you-need?u...
> to separate ZDR, attestation, and confidential routes
Could you please clarify what that means? Given what I've been searching for, I might in principle be part of your intended customer profile, but I can't figure out whether you are merely doing routing (alternative to OpenRouter) or also inference (alternative to the names I've mentioned above). If it's merely routing, then how do you protect me from any potential misbehavior on the part of the inference provider?
Just feedback for what you're building, so please take this in a positive spirit... I'm an AI researcher and not quite an infra guy, and I'm making recommendations on token APIs for several less knowledgeable around me (I've gotten a few people set up with Baseten recently), and I couldn't figure out whether/why I would be interested in TrustedRouter. You should communicate the story better :-)
EDIT: Here's what I now understand after some digging; please correct if wrong.
There are some M token providers (not the names I listed above?) who provide cryptographic guarantees about inference services. But somebody still needs to verify what they do on each request. For an individual running a single harness, that harness would be a logical place to perform this verification if possible. For an org with N users each running their own harness, TrustedRouter solves the N*M problem and becomes the single gateway for trusted inference -- provided one somehow trusts/verifies TrustedRouter.
AWS and Azure give you the same thing for Claude and ChatGPT, no need to be stuck with open weights. They might sometimes store some of it for other purposes (I don't know the specifics), but it is emphatically not being fed back to OpenAI or Anthropic.
My personal opinion is that statistics textbooks usually come from a prescriptive perspective, and that makes it challenging for the reader to get visceral intuition for what is actually going on. Any reader would be far better off just visualizing the damn distribution / samples and using reasonable judgement, instead of implicitly assuming a Gaussians distribution and blindly memorizing tests / formulae. Making the distributions explicit allows us to model them and get an intuition for what the samples are telling us. I would whole-heartedly recommend the Model based machine learning book to anyone (online version is free) https://mbmlbook.com/
Look at the histogram and think about what distribution one could reasonably impute from samples. And what you would set as bounds for "outliers", per your needs. While we're at it, let me also say that it might be useful to specify outlier bounds not just based on the spread in sample values, but the costs/payoffs they imply for your application.
If you are not doing something crazy, most reasonable people would agree with your judgement. Conversely, if you are making non-obvious inferences where reasonable people disagree, you are in murky water and no sophisticated statistical method will save you. Math is not magic; theorems merely recycle (launder) modeling assumptions into results.
>Look at the histogram and think about what distribution one could reasonably impute from samples. And what you would set as bounds for "outliers", per your needs. While we're at it, let me also say that it might be useful to specify outlier bounds not just based on the spread in sample values, but the costs/payoffs they imply for your application.
Only people with prior education/training in statistics are capable of doing this. The people who don't need a textbook.
Something like 60% of US adults read at or below the 6th grade level, and 25% of US adults struggle to comprehend graphs or charts entirely. Someone who has no idea what a standard deviation is can't intuit about distributions. I think you're dramatically overestimating the average person.
> Someone who has no idea what a standard deviation is can't intuit about distributions.
I disagree vehemently with this claim. I could cite my experience in teaching this topic to liberal arts / humanities college students in the US, but it is really more obvious than that. Anyone can understand a histogram easily and far more intuitively than they can understand the formula for a standard deviation and whether it must divide by N or N-1. Statistics courses and textbooks get stuck on that kind of pedantry, and most students end up missing the forest for the trees.
My larger issue, any time I have tried to learn statistics, is how fast the notation moves. You end up flipping back pages and pages just to double-check a definition that was given once and is now being extended syntactically. It's infuriating.
To the extent that skills are contextual guidance (for this author, this project, etc) and not just (raw) capabilities they are unlikely to be eaten by models.
I maintain all my skill files in a central location (like dotfile management) and have guix home sync it to the skill folders of various harnesses that I'm playing with (codex, pi, antigravity, Claude Code, Deepseek harness, etc). They're set up to be bidirectional links rather than read-only like the default configuration, so I can keep editing them / adding to the corpus from any harness.
This works well for skills since all harnesses expect the same format, but is more annoying for other features.
EDIT: This is actually an example of a potentially useful skill. You might choose to manage your skills slightly differently. All you need to do is write a skill-management skill for your agents to be able to wire things up correctly / access them for edits.
Some other nifty skills/plugins in my experience: render latex equations, cetz diagrams inline, jujutsu, guix, code reviewer, writing feedback.
Don't know why the below comment by killix got flagged; it's a legitimate point.
In the current version of my setup, I've decided to accept that tradeoff.
But it would also be interesting to check whether agent behavior can be controlled well enough by a skill-management skill telling them to synchronously commit any changes with their signature; that would get the best of both worlds.
That's like saying a law and order problem is a PR problem because word got out that crime is spiking.
The PR problem is downstream consequence of what can be measured, but the root cause is upstream. Focusing directly on solving the downstream problem is basically Goodharting the metric -- thereby ensuring the upstream problem never really gets solved, and the downstream metric becomes fake and decoupled from the true situation.
Once you "solve the PR problem" what is the incentive to ensure that the root problem is actually solved now that you have successfully blinded yourself (society) from measuring the true problem?
Well, it is a PR problem. It's bad for business to cause a crime spike... that's my point.
I never said focus directly on downstream. I thought it would be obvious that I'm talking about why you bother with upstream, because the downstream effects are important.
It seems I phrased something very wrong because it looks like everybody is assuming I'm saying that you should do as much bad as you can possibly prevent people from noticing.
It's one of several downstream problems, including poorer quality of life by various metrics. By emphasizing a PR problem for businesses more than other human problems downstream or the root problem, you are demonstrating priorities that prosocial humans viscerally disagree with.
reply