61–70 of 104 posts
Earlier quoted context omitted.
Empathy and accessibility. Does it make sense to have a ramp in front of your shop for < 5% customers?
My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web i…
From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox. Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is…
What shifts the discussion a bit is that many of the bottom 5% aren't lost customers. If your website doesn't work on my minority browser, smart TV or PS Vita I might be willing to just try it in Chrome instead
Earlier quoted context omitted.
>Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)? Rails uses a token-based check, and this article demonstrates token-less approach. Rails didn't solve CSRF btw, the technique was invented long before Rails came to life.
Yes, I assumed this is what they were ignorantly pointing towards. Indeed, Csrf tokens are an ancient concept. WordPress, for example, introduced nonces a couple years before rails. Though, it does appear that rails might have been thr first to introduce csrf protection in a seemingly automated way.
I believe the new technique is easier to use for SPA architectures because you no longer need to extract the token from a cookie before adding it to request headers.
Earlier quoted context omitted.
My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
Grandma or poor folk with their old device may not be "largely a choice"
I think I'll probably carry on with not supporting browsers that don't have Sec-Fetch-Site. The alternative, Csrf tokens, actually causes me immense issues (they make caching very difficult, if not impossible).
(and I say all of this as someone who is specifically building something for the poorest folks. I'm extremely aware of and empathetic to their situation).
Earlier quoted context omitted.
My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.
Also, Firefox exists, though they don't seem to care about privacy much anymore either.
And, of course, safari, which is terrible in most regards
Earlier quoted context omitted.
Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere. As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him sto…
There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.
Earlier quoted context omitted.
My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
Grandma or poor folk with their old device may not be "largely a choice"
Secondly, users should upgrade their devices to stay safe online, since vulnerabile people are often scammed or tricked into downloading apps that contain malware.
So we should not cater to outdated browsers when they could pose a risk.
Earlier quoted context omitted.
It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.
There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Also, Firefox exists, though they don't seem to care about privacy much anymore either. And, of course, safari, which is terrible in most regards
Being chromium derivatives, they don't really have a say in what's included in “their” browser though.
> Also, Firefox exists
Well, you disregarded is as “arcane browser” right above.
I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web i…
If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin. So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF…
Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this.
https://security.stackexchange.com/questions/158045/is-check...