Yeah, though it's not great marketing. Especially for hiring interpretability researchers. Their own alignment research has reward model interpretability, personality features and so on (see https://alignment.openai.com ).
It just seems like a different department wrote it, which is a shame because I'd love to read about goblin feature vectors and functional emotions.
It's a funny detail to skim, but what's more surprising is how mechanistic interpretability and alignment science have much better tools and research than the goblin blog post suggests, including from OpenAI's own alignment team:
But the "opt-out" will not prevent ecosystem effects caused by the default shutdown of convenient app installs due to the policy. Not even for GrapheneOS users. It's a global policy by a body we never voted for. You can't opt-out of that different world by waiting 24-hours, the ecosystem could have permanent effects. This is coming from a company that doesn't even bother to expose a permission to disable Internet access per app. It's there underneath, but they just ... don't expose the choice.
Is it really going to have ecosystem effects? Surely the small portion of power-users who are bothering to intentionally sideload apps can click a couple of buttons. Or just load via ADB and avoid the entire thing.
The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow, and I think this is a good compromise that doesn't impact people's ability to sideload.
I say this as someone who sideloads apps literally every day.
Will mandatory ID gatekeeping of developers have ecosystem effects? Surely the only question is how much? You may install apps over ADB every day, but APK installing is much more convenient and open-source F-Droid developers currently don't have to do a thing to be "allowed" to ship APKs.
`The entire point here is to prevent scam actors from using a false sense of urgency to defraud people.`
The proposed architecture is a general developer gate, it is not a proportionate response to the problem - it isn't even proposing to gate specific app permissions, it's being able to install the apps from APKs at all under a regime they administer, with users forced to have this change with no prior consent, only opt-out, and distribution limiting work-arounds (that harm reach).
If Android were to ask the user if they wanted to disable installing downloaded apps from developers who haven't shown Google IDs for their own safety, and let end users give informed consent about what self-protection behaviour level they want for their system, at the point of roll-out, or device setup, that would be quite different.
Why should Google be trusted to gate what apps can be easily shared, when stock Android won't even allow users to toggle Internet access per-app? It isn't proportionate compared to other permissions they could mediate, and worse, it's a centralised architecture vulnerable to authoritarian pressure, and afterwards they will be well positioned to lock it down more.
> The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow
Does it, and if it does, does it need to be addressed by an OS vendor creating a mechanism to ban developers for most users? I'm not convinced of the former, and I'm certain the latter is bad. I predict within ten years, we will see this used against something that is not malware.
What do you mean "ban developers for most users"? Most users get their apps through the play store, which will still exist here. Some users sideload apks, which is also a functionality that will still exist.
> we will see this used against something that is not malware.
See what exactly used against something that is not malware? The Play Store already has requirements other than "don't be malware". If you're talking about the sideloading requirements, all of these requirements apply to every app, not just malware.
Recently, both Apple and Google banned apps for reporting immigration raids in the USA from their respective stores. Android users can still trivially download such apps from other sources. After the verification requirement, nothing changes as long as the developer has a permission slip from Google. If they don't, users have a waiting period that could be a critical delay in an emergency like a crackdown by an oppressive government.
Google has stated that it will only withhold such permission from developers who distribute malware. I imagine they'll stick to that promise at first, but long-term I think they won't. Once it's possible for them to impose partial bans on developers, governments have every incentive to pressure them to do it.
Hey akshayka, I'm not that teacher, but I am a fan, and I notice that marimo sharing would be easier if export and import from normal boring Spyder/Jupyter percent formatted .py files worked by default, instead of indented `@app.cell` decorated functions, and same for for plain Markdown, where right now it has "{.python.marimo}" code blocks with triple backticks, that would normally just say Python. Import and export that used more normal metadata (like comments) would be amazing and would make pointing people to marimo easier. Any chance of this?
So we need a new standard problem due to the complexity of the last standard? Isn't unicode supposed to be a superset of ASCII, which already has control characters like new space, CR, and new lines? xD
The only ones people use any more are newline and space. A tab key is fine in your editor, but it's been more or less abandoned as a character. I haven't used a form feed character since the 1970s.
Should we really buy the many months of switching difficulty argument?
Surely the main API surface is a HTTP API like ChatCompletions? If it's the exact shape of Anthropic's API, the difference is surely minor. There are likely up to 2 API surfaces, that's it. If the OpenAI model APIs are more flexible (esp. with the new 1M context of GPT-5.4), then it should have little difficulty adapting. Then there is LiteLLM and similar that make it even easier, half of their tooling should be using something that abstracts like that anyway. Yes it needs evals and prompt engineering work to optimise it, but they should be used to that by now. Presumably they could even clean-room fine-tune an OpenAI model to match the same Claude shape with low loss. So I don't buy it.
It’s not the syntax of the API that’s the issue, it’s the behaviour and performance of the model. You can create code, images, and video with just about any model, but there’s reasons people prefer Claude Code or Sora for particular tasks
Currently it says they have released metadata and album art. Is archiving and sharing the textual track metadata alone (no images, no audio) legal in the US, or Europe? By what basis is it legal or illegal?
reply