Sometimes, making particular security design decisions can have unexpected consequences. For security-critical software, such as password managers, this can easily lead to catastrophic failure: In this blog post, we show how Bitwarden’s Windows Hello …
Idempotency is when doing an operation multiple times is guaranteed to have the same effect as doing it just once. When working with APIs…
Hahaha, that might be British-specific I guess? I always assumed it was universal. Just means "a long time".
It's hard to work on APIs without hearing about OpenAPI. OpenAPI is an API description format, which is essentially metadata that describes…
This is modifying system CA certs on your own device, with root access. There's plenty of examples in the article, but most commonly you'd want to add your own CAs so that you can intercept and inspect your own network traffic. There's a wide world of developer/researcher/reverse engineering tools that do exactly that, there's a demo here: https://httptoolkit.com/android/
It could plausibly be malicious, but it requires direct root access on the device, and if somebody has root access there's already far more malicious options available to them so it's not a meaningful threat in any sense.
Previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing Magisk or any tools at all, just by writing to disk. Right now, that's widely used and included in the setup guides for lots & lots of tools. All of that will start breaking for users when Android 14 arrives.
I totally agree it is possible to work around this restriction, but it's going to be significantly more complicated, and those changes will only be required because the OS used to let you read & write these files all by yourself, and now it doesn't.
I don't think Android should move further in a direction where it's impossible to directly control anything unless you install a 3rd party modification to the root daemon. That's not a good result. These are important settings and the OS itself should allow you to control them (behind reasonable safeguards & warnings, but still).
Unless it's a fully managed device (different to a work profile - this has to be configured when the device first boots, it's for phones that are fully corporately owned & managed) then I think that has to be acting as a user-level CA certificate (trusted only by apps who opt in to trust it, which notably includes Chrome) not a system-level CA certificate (trusted by all apps by default). That will keep working just fine.
Fully managed corporate devices can do this, there's a separate mechanism for that: https://developers.google.com/android/work/requirements/fully-managed-device
This only works when the corporation fully manages the device though - not for normal work profiles. It's only possible to enable that setup when the device OS is initially installed, and the resulting device is controlled 100% by an IT administrator. It's not something you can do for your own device, and even for small companies it's quite complicated and expensive.
When Android was initially announced in 2007 by the Open Handset Alliance (headed by Google) their flagship project was billed as an "open…
When Android was initially announced in 2007 by the Open Handset Alliance (headed by Google) their flagship project was billed as an "open…
To be clear - even in that world, not having WEI would make you much more suspicious than a 'normal' user, so you're effectively describing every Firefox and/or Linux (etc) user seeing captchas all the damn time. If Cloudflare used this as a signal, that'd be a captcha for 20% of websites.
Try using Tor today and see how inconvenient the web becomes. Just 'not blocked' doesn't mean you get a reasonable experience.
The only healthy route for the web is fair access and free competition between clients. WEI sets that on fire.
TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there's existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.
I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I'd reach for TypeScript if there isn't a special reason.
I'm the maintainer of HTTP Toolkit - it's not a Postman alternative (it's an open source project focused on intercepting & debugging traffic, not sending it) but I'm actually working on building a UI for exactly this right now, so this thread is perfectly timed!
Is there anything that any of you really love or hate about any of the tools suggested here?
What core features beyond just "edit method+URL+headers+body, send, view the response status+headers+body" are essential to you?
Anything you wish these tools could do better?
I'm planning on taking the client functionality live within a few weeks max, so if you want to help your perfect Postman alternative come to life now's the moment 😁
Caching is hard. Unfortunately though, caching is quite important. Hosted caching & CDNs offer incredible powers that can provide amazing…
