The folk who left Psion tried to resurrect the Psion 3/5 form factor a few times as an Android phone with a fairly decent keyboard, but I don’t think they’re still around (or that it’s cheap enough to justify getting one).
I checked this out and I gotta say it is still in a very early stage. The features they are presenting seem nice, but not very usable, with a lot of rough edges.
Then I found this issue, where essentially they left a huge backdoor open with Remote Debugger: https://github.com/zen-browser/desktop/pull/927. The guy claims that it was due to ignorance, but seeing this really shakes up my paranoia. Luckily I haven't typed any credential into the app. From a security-minded user's perspective, this is not a good sign. I hope that they would really put privacy & security forward, get some 3rd party security audits.
I sincerely hope that Apple don't pull a Recall move, because at that moment I'll be forced to migrate off the ecosystem (maybe I'll install Asahi Linux on my M-series machine).
So thank you, Apple, for not running in this arm race. Not every race is worth participating.
In the case of a serious attack, the blacklist should be every token. You can still handle this quite nicely with JWT by rotating the previous verification key. Depends on systems and configuration, this can be as easy as changing the HMAC private key or push a new RSA key to every verifier.
JWT doesn't encrypt (by default) the payload. The header & payload is passed through base64 and appended with a hash to produce a JWT. JWT verifying doesn't require making API call, and is essentially a hash check. Any verifier with a public verification key can determine if the JWT is bogus by a quick hash check and reject the request right away.
Comparing to session IDs, you have no way to know if an unique id is bogus or not. You have to check from a list, be it a cache or a database. This limits the scalability of the solution. I'm not an expert, but AFAIK JWT verifier can be stationed on the edge of the application network, and I have not checked this but I suspect they can even make a hardware solution for those kind of activity. That's definitely a big reduction of attack surface in terms of DDOS.
IMO JWT doesn't have that many moving parts. Encryption parameters are handled by libraries according to tested standards. The only real thing you need to do is to keep your private key safe.
Yeah. The mechanics of JWTs are complex, involving maths that is easy to get wrong. Hopefully the implementation is based on a standard library and the author didn't roll their own crypto. Hopefully the library hasn't got any known vulnerabilities. Hopefully the implementation hasn't got any problems. Because the JWT actually contains sensitive information that is useful to an attacker, and if they can forge their own JWTs then the system is wide open; all the attacker needs to do is work out the username of an admin (or worse, the JWT itself tells the system if the user is an admin).
Session IDs don't have any of these problems. It does mean you have to do a database lookup on every request, and that can cause problems with scale, but if you have to hit the database anyway for other reasons then you have that problem anyway and have to solve it for those other reasons.
I worked with some platforms that does. However, those usually position themselves as a code generator more than a full application builder.
- Amplication: Last I checked, they allow defining data structure & endpoints etc. before exporting to Nest.js Boilerplate with niceties. They sync to a separate branch on GitHub, so you can use it alongside writing actual logic into the boilerplate, and merge new changes from Amplication to the main branch.
- Draftbit (React Native based Mobile App builder). The builder is not very great, they lack a bunch of features. They make up for this by allowing the developer to add custom JS code very easily. You can write your own Custom React element inside the editor, and with a little massaging things can fall into place. I'm not saying this approach should be abused, though. The team told us once that some of their big clients are mobile dev agencies that mostly just use the platform to Storyboard & bootstrap some UI before doing the actual logic in their own code.
- FlutterFlow (Mobile App builder). I'm biased because I'm still in the progress of helping a client fixing their mess on FlutterFlow. FlutterFlow's code output is really spaghetti. The developer UX on the builder is horrible, so in the end I still opt to eject and deal with the spaghetti code.
Thanks for building Windmill. I spin up a test instance and was blown away by the well-designed-ness.
I'm looking to investigate using Windmill as a website builder for some small internal system. Few questions:
- Is it possible to setup custom path for flows (to hack it into a REST API)
- How can we go and make authenticated flow
You are saying "gross omission" like this is some Python script, like they are skipping the else clause for a condition. Imagine trying to land a plane that is flying at Mach 2, with no direct control, only a video feed with 4 seconds resolution, a bunch of sensors and a tank of fuel for retrograde burn to slow you down. Can you even fathom the number of scenarios that can happen. Your application may have 1 happy path and 2 sad path. Here you get only 1 happy path, a few not so happy path where your probe land sideway or just roll down a crater; and the rest of them are every other combinations of your probe's orientation and speed vector and collision location.
Hell, you can run a few thousand simulators for every scenario you can think of during descent, including lost of burner, propellant leak, etc, and then during the actual descent a chip get burnt because of a stray cosmic ray. There will still be somebody on HN call you out for cutting corner.
