Which means the issuer has to be involved in every attestation and you aren't allowed to own/control your private key.
The government shouldn't know if/how many times I use my ID—you would be essentially building a country-wide blackmail database since it's a near direct proxy for porn usage. And it doesn't even matter if it's true, people will assume it anyway.
Your system effectively collects exactly the data ZKP is intended to protect.
Which is a long way of saying "ZKP" isn't an answer to this problem because you can't actually have zero knowledge in a system where people have little incentive to keep their key a secret.
My example is still just as good if the ID holder is complicit.
But also, this on-device fingerprint MFA would presumably be fairly bypassable. E.g. just glitch the device to extract the private key. ... and of course all the power hungry / extra complex ZKP machinery means less resources spent on preventing glitch attacks.
Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!
A phone line from before WWII works fine to make a call but absolutely sucks for DSL.
And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.
It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.
You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.
And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.
The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.
Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.
It comes down the web browser being used for two different use cases and two camps arguing past one another.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.
But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites.
I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.
And the old "dynamic HTML" approach is not easier to maintain and developm. By far.
In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.
Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?
Because the "in schools" changes the calculus massively. You see a similar reaction to banning phones and personal computers while in school.
Kids can still access and use AI outside of school meaning the enforcement is entirely on the school and doesn't require massively a privacy invasion for adults by way of age verification. Schools already put children under (from an adult perspective at least) a pretty intense rules regime so this doesn't represent any kind of change—indeed it's probably better framed as a
lack of a change from the status quo.
What's surprising about this is that you can get the bullshit machine to produce correct externally validate citations. It's not particularly hard either—it's one of the first things you build when you give an LLM access to a body of documents/search. So for a large public service to whiff like this is certainly a stain on their credibility.
On the other hands it's a boost to their credibility that they make their mistakes easier to evaluate than their competition does. It would be worse if they had a similar error rate without openly providing references. Kudos to Perplexity for including more empirical attack surface.
By training it on a whole bunch of examples with valid external citations, to the point where it's able to hallucinate something that's valid. Of course, it won't always work, which is the point of TFA.
I don't think this is an answer. I'm basically claiming there is an uncontrollable error probability, and I think you agree with that. The person I'm replying to implies it can always be reduced (maybe even to zero).
From a security perspective, panic at runtime is not that bad for security. Much better than continuing to run with undefined behavior. If someone sends a malformed video in and it crashes the ffmpeg process you can just log it and restart it. Vs potentially exploiting the system.
I mean this reminds me of Firebase v1 and FoundationDB I think both of which have a favorable reputation for quality in both design and implementation. I do think there's something to be said for being forced to code against what operations are actually fast in your DB. Once it works you can be reasonably confident it will also be fast rather than the typical RDBMS experience of getting an abundance of rope with which to hang yourself with. You often won't find out until it's already load bearing that your query doesn't scale.
This is a great example of outages looking different from the perspective of the operator vs the user. Because there's many shards the blast radius of failure is contained to a small subset of users but for those users it's an outage. The way it's designed you can't lose any shards without impacting users. Compare to say Elasticsearch where it's possible to lose nodes and lose shards without the user noticing. One approach isn't universally better than the other.
Of course. On the other hand, is it fair to call it a single point of failure if it being down only affects a shard? Maybe within the shard indeed. Or for a single customer indeed. Not sure if we have terminology to indicate one or the other.
You're trying to solve with technology a problem that lives in the abstract human world. Even the simplest possible case, you make a physical unique object that you define as conferring ownership to the person who possesses or controls it. Someone steals
the object, now the person in possession of the object isn't the owner. There's this allure of trying to tie this abstract notion of ownership to a physical thing but it's breaks down immediately. It doesn't even work for physical objects.
Automated enforcement of ownership rules is completely tangential to the actual problem you're running into. You own a physical book, you make a copy then sell the book. That's a copyright violation, no "verification" or whatever nonsense needed. What happened in regards to ownership in this case is already clear. Companies sure do like DRM but it's as much a pale imitation of ownership as anything else.
I feel like none of the replies are really cutting to the core of what the problem with your logic actually is—because your way of thinking is incredibly common in tech since it's what we do all day. The fallacy is scale invariance, that the nature of a thing doesn't change when the scale does. Anything you can do you can put in a for loop.
And the equivalence you're drawing is that the fundamental nature of someone recording a video with their phone is the same as a digital panopticon.
The government shouldn't know if/how many times I use my ID—you would be essentially building a country-wide blackmail database since it's a near direct proxy for porn usage. And it doesn't even matter if it's true, people will assume it anyway.
Your system effectively collects exactly the data ZKP is intended to protect.
Which is a long way of saying "ZKP" isn't an answer to this problem because you can't actually have zero knowledge in a system where people have little incentive to keep their key a secret.
reply