Wow, what a nice chain by @zemnmez exploiting various issues in the Apple ID service. I particularly like the trick to make event.source be null for messages, wasn’t aware of this one. In the end there is even XSS on the domain, CSP isn’t preventing it.
Brace yourselves... I'd like to share with y'all an email I sent #Apple employee relations on July 16th detailing a list of my concerns & complaints (with associated Box folders & relevant evidence). #Harassment, #Discrimination, #Assault, #Retaliation, more...
Having read the Steve Jobs biography, I’m somehow not surprised at all that such things happen at #Apple. There is no way a healthy company culture would arise with this kind of leadership. And please spare me “the end justifies the means” speech.
> My #Apple team in SW Eng not only documented their goal of making my "life a living hell" in our dev work tracking system, they also kept whiteboards for tally marks when they "scored points" …
The guy wrote this thread without realizing how he is describing a massively toxic culture. And he concludes by stating that he now applies the lessons learned here at his startup. For me this conclusion reads as: “If you work at that startup: run! RUN! NOW!!!”
If you ever find yourself at a company doing this: leave ASAP. The “hard work” heroism is an incredibly bad take for everyone. Long work hours destroy people’s mental health, and they don’t even increase productivity. Overworked people make lots of mistakes, only wasting time.
> The Internet Explorer team was the hardest-working team I’ve ever been on. And I’ve worked at multiple start-ups. It was a sprint, not a marathon. …
For reference: white hat hackers do not transfer out $600 million to “bring attention to a vulnerability,” they would stop a step short of that. But one has to appreciate the gesture of transferring back all that money. 😅
> As our communication with Mr. White Hat is going on, the remaining user assets on Ethereum are gradually transfered to the multisig wallet (0x34D6B21D7B773225A102b382815e00Ad876E23C2) requested by Mr. White Hat.
As @firstname.lastname@example.org points out, Transfer-Encoding is indeed forbidden. While I’ve seen the relevant spec section (220.127.116.11), 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.”
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.