• 3 Posts
  • 58 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle
  • The spec mandating its as a single string isn’t that crazy. It’s good to have a consistent response format so a basic deserializer can deserialize any error response object and get something out.

    If you have different providers. One that returns error: { code: string } and another does something else, you end up with the same problem this post talks about-- Inconsistency.

    As far as I can tell, the spec doesn’t limit you to just the one field and you can add other optional fields to the top level to the response that the caller can optionally decide to handle. But if you know there’s going to be a field called error that is a string. You always get at least something out of that to present.




  • The hard part is browsers. Cookies and local storage are limited by the origin URL. You need it explicitly set on the domains you intend to visit, but those domains don’t know your age. The one that knows the age is the identity provider, but it can’t set it for all domains. There are other techniques that you could use, like a smart card combined with a browser extension to do local based user info attestation, but those are difficult to manage at a nation scale and I suspect people will struggle with them, though there are some countries that do have national smart cards (e.g. Estonia.)


  • Its possible to implement something that hides your actual age from a website, but the tricky part is hiding what website you’re visiting from an identity provider.

    Let’s walk through a wrong solution to get some fundamentals. If you’re familiar with SSO login, a website makes a request token to login the user and makes claims (these request pieces of user information.) One could simply request “is the user older than 18?” And that hides the actual age and user identity.

    The problem is how do you hide what website you’re going to from the identity provider? In most SSO style logins, you need to know the web page to redirect back to the original site. Thus leaking information about websites you probably don’t want to share.

    The problem with proposals that focus on the crypto is that they actually have to be implemented using today’s browser and HTTP standards to get people to use them.



  • Batteries are bounded by more predictable chemistry more so than something like the breakdown of a mechanical based trigger waiting for rust or decomposition. Chemistry makes it easier to model and predict. If you’ve got a 1Ah battery and it consumes x watt hours per hour, then it takes y days to burn through. Tolerances that cause the battery to have slightly more or less capacity or component power consumption will likely be <5%, thus not radically different because nobody is timing this to the minute.














  • Computer algorithms solve problems all over the world for companies already. I bet airlines already have teams of people using computer algorithms to figure crew management, flight routing, cost optimization, etc.

    The fact that they’re exploring quantum computers and non-classical algorithms just suggests that gate allocation is NP-Hard. Sure things go wrong when computers fail already, Look at Southwest or Delta’s recent meltdown, but to act like this a bad thing is just nonsense. This should be looked at as a good thing that airlines are working on.


  • Why do you think this is going to replace air traffic control work? It’s picking which gate to park the plane at. This was done by airline and airport operations teams, not ATC. Imagine if you could automatically pick gates to reduce the time a plane spends taxiing and/or minimize time passengers spend walking. That’s 100% a useful application for computer optimization algorithms. Humans aren’t going to do that better and it’s not a function of safety that tower or ground control needs to do.