4 ms·
This is a pretty bad way to make an announcement. The abstract mentions iOS, Firefox, VLC and multiple Android devices. 1. At least 2 of those entries are soft
by laserbeam 4y ago
This is a pretty bad way to make an announcement. The abstract mentions iOS, Firefox, VLC and multiple Android devices.
1. At least 2 of those entries are software users CAN upgrade manually, but versions are hidden deep within the text. If users can take action that should be incredibly clear.
- I have been unable to quickly skim and find a version of Firefox has fixes for these.
- VLC has a fix for a use after free issue in 3.0.18, but I can't tell at a glance if other issues still persist.
2. Do we know anything about whether this is exploited in the wild or not? I can't tell from the abstract nor the conclusion.
The technical information is valuable, but anything actionable for users to mitigate effects is really hard to find :(.
[Edit] Ok, the disclosure and ethics subsection does mention that Apple, Mozilla and VLC have fixed these bugs in their latest releases, and Google and MediaTek are aware of the problems.
That's the bit I was hoping to find at a glance.
- est31 4y agoThose are fair questions but note that this is a research paper (and an excellent one at that), not a blog post meant for general audiences. The focus of the abstract and introduction sections is more higher level, on the contributions of the paper, instead of what it means for end users.
- izacus 4y agoA research paper should doubly avoid having such clickbait titles.
- Aissen 4y agoWhat is clickbait here ? They found new vulnerabilities, reproduced old ones, across various products, and crafted an exploit.
- laserbeam 4y agoI fully agree it is a research paper and the subject matter is absolutely great! My complaint is the research paper hints at what may be affected in the abstract, that got picked up in the title, and then it got a challenging to find actionable details quickly for either an end user or someone only mildly interested in the topic. It also liked to a github page which is a great place include the short non-research content. I think the github page was WIP at the time the article appeared on hn. I know my attitude was critical, but I also tried to include that info in the message (even though I found the responsible disclosure subsection after posting my original comment). I also feel that info should be present on HN in one of the top comments for these kinds of articles (regardless of whether it's mine or someone else's).
- est31 4y ago> It also liked to a github page which is a great place include the short non-research content. I think the github page was WIP at the time the article appeared on hn. I see. When I made the reply it already linked to the pdf. So you can't really be blamed neither can I. Such confusion is normal when a link changes. > I know my attitude was critical, but I also tried to include that info in the message To be fair, hn is renown for that attitude. Some of the most famous hn comments are precisely of that kind :) https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 The paper was written to suit an academic audience first, which includes people reading it 20 years later. Actionable advice for users is then in accompanying notices. Also, usually when papers get published, it's months after they have been submitted so usually security bugs are already fixed and if you are on somewhat up-to-date patch levels, you are safe. I say usually because some vendors might not be as quick to patch or it might not be as easy to fix bugs (say bugs in hardware or such).