291–300 of 310 posts
Earlier quoted context omitted.
There’s absolutely nothing ordinary or easy about that setup, but I admire it. I’ve only seen that level of paranoia at a three letter agency. Do applications with pinned certificates break? A bunch of mobile apps do that to get in the way of Wireshark.
https://f-droid.org
Earlier quoted context omitted.
I think it's fair to assume j. random user isn't typing " http://api.example.net " into their web browser. leading www perhaps, leading api no.
You'd be surprised... generally if there's a dedicated hostname for the API, I would expect / to either display or redirect to API docs. Also, doesn't help when you're reverse proxying /api to $API/api
Earlier quoted context omitted.
>When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing? >for the price of a free Let's Encrypt cert you can del…
> Neither desktop firefox nor chrome seem to do this by default they do, you probably just checked the "i'm sure this is safe" button posted a pic on the imageboard hehe
Earlier quoted context omitted.
https://f-droid.org
Someday on iOS, if Tim wills it.
According to this film, which Wozniak said was very accurate, Steve Jobs was a douchebag.
Android sucks, too. I only use it out of necessity, not choice.
Why do I use a TLS forward proxy.
Because I loathe using popular, so-called "modern" web browsers. I prefer using smaller, simpler clients.
Earlier quoted context omitted.
> we had (and still have today) all the technology required to build genuinely secure systems. True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been. Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willin…
I’d disagree that there has to be a trade off at all. Using hardware security keys or device based passkeys, secure authentication is actually pretty convenient now.
there's probably a term for the cognitive fallacy where you assert that however it happens to be is how it had to be. it's like normalcy bias, but retroactive.
The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
This sounds like a great way to cause Denial-of-Service attacks.
Earlier quoted context omitted.
Just tried on Chromium, I get ERR_ADDRESS_UNREACHABLE as I would expect.
Yeah, someone else said it's not enabled for everyone. It might just be settings? Do you have "Always use secure connections" turned on? I don't remember if that was a manual toggle or not. However it's triggered, I hope they make the UI better before they deploy it more widely. And I'll quote the exact text for you: [warning triangle] The connection to 192.168.0.40 is not secure You are seeing this warning because t…
Earlier quoted context omitted.
If you're serving web traffic and API traffic on the same domain, which many services are, then not listening on port 80 may not be possible. Even if you do use a different domain, if you're behind a CDN then you probably can't avoid an open port 80. I do keep port 80 closed for those of my services I can do so for, but I don't have anything else that needs port 80 to be open on those IPs. I think Stack Exchange's so…
I always thought it was bad practice to use the same domain for API and non-API traffic. In the browser there'll be a ton of wasted context (cookies) attached to the API request that isn't needed. So it's better to have "api.example.com" and "www.example.com" kept separate, rather than using "www.example.com/api/", where API requests will have inflated headers.
In any case, I'd recommend same-origin requests for browser access to APIs and a separate domain for non-browser access, purely for separation of concerns. That lets you tailor the access rules for your endpoints according to the type of caller you're expecting.
Earlier quoted context omitted.
> we had (and still have today) all the technology required to build genuinely secure systems. True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been. Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willin…
I’d disagree that there has to be a trade off at all. Using hardware security keys or device based passkeys, secure authentication is actually pretty convenient now.
Earlier quoted context omitted.
I’d disagree that there has to be a trade off at all. Using hardware security keys or device based passkeys, secure authentication is actually pretty convenient now.
yeah, the assertion is entirely false. there doesn't need to be any such tradeoff. there's probably a term for the cognitive fallacy where you assert that however it happens to be is how it had to be. it's like normalcy bias, but retroactive.
Maybe you're right. I've certainly heard others make this claim. I just personally haven't seen a real-world example of this being true.