debazel

Only to other proprietary systems within the FIDO Alliance that you don't own or control.

Additionally passkeys allow services to detect and ban specific password managers, so have fun when the only approved managers that works consistently across all services are Google/Apple/Microsoft. There is already a list of "bad" clients here https://passkeys.dev/docs/reference/known-issues/

ironically the only group of users I've found that actually care about native UI, are other developers and Mac purist.

Is there a reason this has to happen client side with extra pre-flight requests? Taking your example, why couldn't Facebook's server just check the origin header and then reject all request from unapproved origins server side instead?

A revocation list can often be lazily replicated and doesn't require the complexity of distributed synchronization.

If you store sessions then you need to ensure the session has been replicated to every node before you can return it to the user. For revocation lists it is often acceptable that the token is still valid for a short while at some nodes while it is being replicated.

A revocation list is also not considered highly sensitive data, which would be another complexity layer when working with distributed data.

So I just wasted my time reading through this garbage and I can't find anything that debunks what you claimed it does? The whole thing boils down to Israel fired a lot of ammunition, therefore it was actually Israel killing all the civilians.

On top of that, the whole article is mainly sourcing from "The Electronic Intifada", which definitely seems like the most objective source for objective truth on Oct 7th.

I tried it with OpenCode and it is borderline incapable of using tool calls, so that might be why it is doing so bad on your test.

The amount of steering necessary is rapidly decreasing. You're looking at a way too small timeline if you think this will be sustainable, or you're hoping that LLMs will hit their peak very soon.

I guess it's up to interpretation, but I read it the complete opposite way, as in Linux distributions should not think so highly of themselves as to expect OpenBSD to conform and adapt to their mess, and OpenBSD rightfully should not be expected to "give a flying Fedora about Linux".

A phone is worthless without software.

The standard itself being open is irrelevant. I'm not sure why this is always brought up for attestation standards. It is fundamentally impossible to trust the signature from open-source software or hardware, so a signature from open-source software is essentially the same as no signature.

The need for a trusted entity is even mentioned in your specification under the "attestation" section: https://spec.c2pa.org/specifications/specifications/1.4/atte...

So now, if we were to start marking all images that do not have a signature as "dangerous", you would have effectively created an enforcement mechanism in which the whole pipeline, from taking a photo to editing to publishing, can only be done with proprietary software and hardware.

but eventually we should start flagging images with no source attribution as dangerous the way we flag non-https.

Yes, lets make all images proprietary and locked behind big tech signatures. No more open source image editors or open hardware.

Until you explore "too deep" and get your whole account banned for suspicious activity and permanently grief your whole career.

Good. More open source tools should be unappealing the the "corporate world". They can fund and pay for their own tooling.

This is not an easy fix. Charge backs will lead to life-time permanent bans. Which means you're now forced to buy an iPhone in order to pass store attestation for essential applications like banking apps, government ID, age verification, etc.

That's irrelevant, a blocked account justified or not should not prevent you from canceling your subscription. It should in fact automatically cancel any subscription upon account suspension.

My experience with actually trying this is that current LLMs benefit greatly from having a framework to build on.

More code in the context window doesn't just increase the cost, it also degrades the overall performance of the LLM. It will start making more mistakes, cause more bugs, add more unnecessary abstractions, and write less efficient code overall.

You'll end up having to spend a significant amount of time guiding the AI to write a good framework to build on top of, and at that point you would have been better off picking an existing framework that was included in the training set.

Maybe future LLMs will do better here, but I wouldn't recommend doing this for anything larger than a landing page with current models.

You wouldn't even have to be a high profile target like a sanctioned judge. Simply getting your account banned by some automated process that marked you as "suspicious" will basically render you excluded from society.

It is absolutely insane to put this amount of power in 2 foreign companies that will be able to destroy your life with zero reason, oversight, or due process.

It takes five minutes to explain how an idea could open up a new market segment. It takes two seconds to say "that sounds risky." But in a meeting, the two feel equivalent.

In what world do these sound equivalent? Simply saying that something “sounds risky” is not serious criticism and wouldn’t hold any weight at any place I’ve ever worked at. You would have to actually explain why it sounds risky and point to something tangible.

What type of "experience" are you expecting to have anyway?

Being told upfront what is required to complete the process so you don't have to start over again multiple times?

Most common use cases are social media, messaging (WhatsApp, Messanger, Telegram, no one is using SMS anymore), ID apps, payment and banking apps.

You could skip social media, but without the others you would basically have to carry around a second phone or be severely handicapped just trying to live a normal life.

Beside all of that, the idea that a $1000 iPhone is usable without an account because you can SMS and check emails is laughable disingenuous.

An iPhone without an Apple account is about as useful as brick because you can't load your own software onto it without the store.

cover most common use-cases.

It absolutely does not.

You would need to lug the device with you everywhere because BankID is used for all sort of things in Sweden. I couldn't even use a vending machine here without the BankID app.

WebViews aren't written or rendered with interpreted languages either. It is also usually not Javascript that makes browser based apps so heavy. It is almost always the whole browser stack that is making them large and memory hungry, which is mostly written in C++.

You can also hook a WebView up directly to a low-level language and skip Javascript entirely, so does that mean Rust + WebView = Native?

Are you sure that endpoint is sending all traffic to opencode? I'm not familiar with Hono but it looks like a catch all route if none of the above match and is used to serve the front-end web interface?

That is entirely dependent on the font.

I strongly believe that most would actually. All parents I've talked to have had issues with parenting their children's online activity. They know there are harmful things they want to prevent them from accessing but it is simply to hard to configure and set up existing tools for it. (Besides every single friend they have don't have any restrictions so it all seem pointless.)

I can also see also large support for uploading ID to various services when talking about kids, but when you re-frame the question to adults, most seems to really dislike the idea immensely.

Sure there will be children with access to unrestricted devices, just like we had kids with porn mags hidden in a forest somewhere back in the day, or how that one sketchy guy was buying alcohol, etc. But I think this is an acceptable level of risk for whatever harm people want to prevent.

I think a part of a better solution is to give parents and children better tools to manage their social graph themselves. Essentially the real problem is discovery and warding off of social outliers in a way that doesnt out all responsibility on opaque algos or corporations.

This is actually a key consideration for the proposed implementation. The biggest issue for parents when restricting their children's online activity is that they simply don't understand the tool available for it.

By having a "child mode" iPhone, parents don't have to know any of that. They simply buy the iPhone Kids for their children and then get a plain iPhone for themselves.

If these restrictions were to actually be enforced by law as well, then it would make it very easy for teachers and other guardians to check if a device is appropriate for the child using it.

I actually think this would be easier to implement than many of the current ID verification methods I've seen being pushed. We already have the infrastructure for selling age restricted goods, this is nothing new. Manufacturers that are unable to restrict their hardware in a "child" mode don't have to do anything and could simply continue selling to adults only.

It's obvious we're moving in a direction where we are going to get these restrictions in one way or another, and this is the only way I've come up with that doesn't come with serious privacy implications.

Most importantly, this solution would be simple for anyone to understand. You don't need to be a cryptography expert to understand there are child safe devices and then there are unrestricted devices for adults.

Children are just too effect of a tool when building a surveillance state. We should have banned children from owning open computers a long time ago just like we do with Alcohol, Driving licenses, etc.

Instead children would own special devices that are locked down and tagged with a "underage" flag when interacting with online services, while adults could continue as normal. We already heavily restrict the freedom of children so there is plenty of precedent for this. Optionally we could provide service points to unlock devices when they turn 18 to avoid E-waste as well.

This way it's the point of sale where you provide your ID, instead of attaching it to the hardware itself and sending it out to every single SaaS on the planet to do what they wish.