As @firstname.lastname@example.org points out, Transfer-Encoding is indeed forbidden. While I’ve seen the relevant spec section (18.104.22.168), I initially interpreted it as only relevant for HTTP/1.1 to HTTP/2 transition. This is actually not the case.
Similarly, the spec lists restrictions for the Content-Length header but ignores the similarly problematic Transfer-Encoding header. In fact, straight out disallowing both might have been the better option.
Having gone more thoroughly through the spec (thanks @x_cli): yes, HTTP/2 spec does have rules to make conversion from HTTP/2 to HTTP/1.1 safer. In some cases these rules were ignored, but sometimes these were just not strict enough. E.g. allowing both :authority and Host headers is a bad idea.
This is some fancy stuff. Strictly speaking, these aren’t issues in the HTTP/2 protocol. However, with many websites using HTTP/1.1 for their backend communication, the translation from HTTP/2 to HTTP/1.1 becomes a major source of vulnerabilities due to insufficient validation.
Never mind that there is no solution for communication between email servers, this one inherently relies on STARTTLS. Not that there ever was a scalable solution for downgrade attacks here…
So STARTTLS is prone to security vulnerabilities. Yet when I was setting up my email server the recommendations were to drop port 465 for TLS-only email submission (messy history) and rather use STARTTLS on port 587. Guess these recommendations need an update. 😒
IMHO, the real solution is not merely removing PII but getting rid of all user identifiers. Even a random and anonymous identifier allows connecting data points into a profile of an individual user who can then be deanonymized. But mere data points are less valuable of course.
An older article of mine has been circulating again lately. This real-world scenario shows clearly: the focus on PII (or lack thereof) in collected data is misguided. Given a large enough stash of data, it will often be possible to identify people.
Oh, and one organization considered it a good idea to publish my email address in their security bulletin after I reported a vulnerability to them. Way to go for a security product!
I have hundreds of email addresses, yet almost none of them have ever received spam. Some organizations held onto the email addresses longer than they were supposed to, a few were hacked. But I don’t think any of my email addresses were ever sold to third parties. Surprising.
One of the conclusions of this Blackhat talk:
“Very few companies transferred our personal information in ways that we can confirm”
Yes, it’s the same conclusion here after using a unique email address for each communication partner for several years.
I rarely recommend browser extensions, but Alt or Not is very simple and secure. This extension enhances Twitter by making image descriptions for visually impaired people visible, and it makes sure you don’t forget them in your own tweets.
“Smart contracts always do exactly what they are meant to do” they said. “Smart contracts are reliable because no pesky humans are involved” they said.
Reality: “smart contract audits take time, are not cheap, and require highly experienced auditors.”
More details in the article here. Grindr gave location data to third parties which was detailed enough to be associated with a priest and to out him as gay. Yet they keep claiming that this is “infeasible from a technical standpoint.” Yeah, sure…
Huge surprise! Yes, claims that data is being “anonymized” are usually merely a lame excuse. Given enough data, de-anonymization will often be possible. And that’s especially the case for highly sensitive data like movement profiles.
Their autoreply mentions the “new data protection policy.” Yes, it has been merely three years. Not nearly enough time to get accustomed with it of course.
Wladimir Palant, software developer and security researcher, browser extensions expert. He/him
Other Mastodon account for non-technical topics: https://social.tchncs.de/@WPalant
A Mastodon instance for info/cyber security-minded people.