VLC 3.0.7 and security(jbkempf.com)
jbkempf.com
VLC 3.0.7 and security
http://www.jbkempf.com/blog/post/2019/VLC-3.0.7-and-security
72 comments
> The medium security issues are mostly out-of-band reads, heap overflows, NULL-dereference and use-after-free security issues. Those issues should not be exploitable with ASLR [...]
Is this really valid? I remember reading numerous Google Project Zero blog posts that begin with finding an issue that should not be exploitable thanks to ASLR, and then the research would promptly proceed to defeating ASLR - usually by chaining to some unrelated and much less serious side channel exploit.
Is this really valid? I remember reading numerous Google Project Zero blog posts that begin with finding an issue that should not be exploitable thanks to ASLR, and then the research would promptly proceed to defeating ASLR - usually by chaining to some unrelated and much less serious side channel exploit.
(I'm the author of the blog)
> Is this really valid?
Yes/No. The issue is more about categorizing between low, medium, high and critical security issues, because this impact the bounties values.
So, we have to define some guidelines on which is high or medium, because this is the most difficult part to differentiate. OOB reads gets medium, while OOB write gets high. Buffer overflows get high, while Null-deref gets medium.
If you try hard enough, those are probably exploitable, but maybe, we're not sure. While the OOB writes are exploitable, so this is more important, so it gets high.
Of course, it is important to fix everything, but we need to be fair, notably when it is not our money.
> Is this really valid?
Yes/No. The issue is more about categorizing between low, medium, high and critical security issues, because this impact the bounties values.
So, we have to define some guidelines on which is high or medium, because this is the most difficult part to differentiate. OOB reads gets medium, while OOB write gets high. Buffer overflows get high, while Null-deref gets medium.
If you try hard enough, those are probably exploitable, but maybe, we're not sure. While the OOB writes are exploitable, so this is more important, so it gets high.
Of course, it is important to fix everything, but we need to be fair, notably when it is not our money.
Cannot really be said in a general way. With a lot of effort probably all of those could lead to more serious things, but not easily in a platform and setup agnostic way, i.e., you probably need time and be able to try multiple times to get you a realistic chance.
If it's not possible to try multiple times (e.g., your try crashes or runs into some other protection mechanism (no-execute flag on page set, return address validation, ...) then there's, again depending on the specifics of the bug and it's context, a very slim chance to achieve a (arbitrary) remote code execution, or something similar serious, realistically.
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.
VLC can also connect to a remote host and play a network stream. You could probably infer delta-T through the time it takes VLC to request the next chunk of your video/audio stream.
But still, that's a long way from exposing the address of useful gadgets or other potentially sensitive information...
But still, that's a long way from exposing the address of useful gadgets or other potentially sensitive information...
Thanks for the in-depth explanation!
[deleted]
> If you've listened to some of my talks or spoke to me (I'm sorry for you), you know I'm a bit critic of those programs, because they give money to find the issues, not to fix them.
>> What about you give money to VLC instead of random hackers?
> Well, security is important, so this is cool for our users, but still this is a mixed bag, for me.
I've asked that question to Julia Reda a few months ago, and I think the answer was pretty interesting. It boils down to the absence of companies that provide this service ("security bugfix bounties") and are also willing to deal with basically being an EU contractor. So instead the EU-FOSSA bounties went to HackerOne, which is not perfect but is a step in the right direction that could be implemented immediately.
Also note that Google does provide bounties for security patches and hardening (https://www.google.com/about/appsecurity/patch-rewards/ -- VLC or ffmpeg are not in there, but many base libraries are) and for integrating FOSS projects into their fuzzing frameworks (https://www.google.com/about/appsecurity/patch-rewards/autof...). I don't know of any other company providing this kind of bounties for FOSS devs.
>> What about you give money to VLC instead of random hackers?
> Well, security is important, so this is cool for our users, but still this is a mixed bag, for me.
I've asked that question to Julia Reda a few months ago, and I think the answer was pretty interesting. It boils down to the absence of companies that provide this service ("security bugfix bounties") and are also willing to deal with basically being an EU contractor. So instead the EU-FOSSA bounties went to HackerOne, which is not perfect but is a step in the right direction that could be implemented immediately.
Also note that Google does provide bounties for security patches and hardening (https://www.google.com/about/appsecurity/patch-rewards/ -- VLC or ffmpeg are not in there, but many base libraries are) and for integrating FOSS projects into their fuzzing frameworks (https://www.google.com/about/appsecurity/patch-rewards/autof...). I don't know of any other company providing this kind of bounties for FOSS devs.
I submitted this for discussion because of the "Opinion about bug bounties" section at the bottom of the post. It was interesting to read about the wide variety in quality of responses to an open source bug bounty.
There's a wide variety in the quality of responses to bug reports too.
Last year I stumbled across a bug which could result in a leak of personal data (specifically, private messages). So I did the good-samaritan thing and reported it, opening with "I don't want a bug bounty for this" (it was a pretty trivial bug, just a high impact one).
What I got back was a wall-of-text missive about how it wasn't on the OWASP TOP10, wasn't eligible for a bug bounty anyway, and finished with a personal attack. I didn't even reply to it.
I haven't bothered submitting anything else, not on Hackerone, not anywhere.
Last year I stumbled across a bug which could result in a leak of personal data (specifically, private messages). So I did the good-samaritan thing and reported it, opening with "I don't want a bug bounty for this" (it was a pretty trivial bug, just a high impact one).
What I got back was a wall-of-text missive about how it wasn't on the OWASP TOP10, wasn't eligible for a bug bounty anyway, and finished with a personal attack. I didn't even reply to it.
I haven't bothered submitting anything else, not on Hackerone, not anywhere.
You should have released the email complete with personal attack and all info needed to reproduce the bug after 90 days. Their incompetence isn't your problem but it is their users problem.
>On 8 June 2019, 08:03 by ahmet sahin simsek
>hi
>I downloaded thé new version and I have a problème withe subtitle please can you help me
How do these people manage to find these unrelated blog posts and decide to request tech support there?
>hi
>I downloaded thé new version and I have a problème withe subtitle please can you help me
How do these people manage to find these unrelated blog posts and decide to request tech support there?
The libcurl maintainer got/gets emails[1] asking for technical support on people's cars because they likely stumbled across his email address in the mandatory license text.
1. https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/
1. https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/
Reminds me also of this exchange the maintainer of thttpd had with a repo guy: http://acme.com/software/thttpd/repo.html
Or the time Tuttle (a city in Oklahoma) threatened to sue call the FBI on CentOS: https://www.theregister.co.uk/2006/03/24/tuttle_centos/
(I'm somewhat amused that the website in question still doesn't seem to work 13 years later.)
(I'm somewhat amused that the website in question still doesn't seem to work 13 years later.)
And why do they feel it's appropriate to ask for help there? This would be like going to a talk from a presidential candidate about fuel economy, and raising your hand and saying "My car doesn't start, can you help me?"
Probably a relatively new internet user with little understanding of how the whole thing works. Just uses it to watch content.
If “Facebook” is the internet to you, typing into the first comment box you find seems more reasonable than finding an FAQ.
User seems to even have their spell-check in French mode - possibly not even using their own computer to ask the question.
If “Facebook” is the internet to you, typing into the first comment box you find seems more reasonable than finding an FAQ.
User seems to even have their spell-check in French mode - possibly not even using their own computer to ask the question.
[OT] Non-English speaker here. Is there any difference (in grammar and/or meaning) between "an FAQ" and "a FAQ"? I'm asking because it sounds good but it goes against the little English grammar I remember from school...
"a" vs. "an" is based on the first sound of the word, not the first letter. You would say "an honor" but "a hair" because, while they both start with the letter h, one has a silent h and the other doesn't.
If you pronounce "FAQ" by spelling out the letters (and not like "fack"), it starts with "eff", so you should say "an FAQ." I think that's the pronunciation I usually hear.
If you pronounce "FAQ" by spelling out the letters (and not like "fack"), it starts with "eff", so you should say "an FAQ." I think that's the pronunciation I usually hear.
In particular it's "a" if the following word starts with a non-vowel sound, and "an" for a vowel sound.
Compare:
an SQL command
a SQL commandI think I hear both "ess queue ell" and "sequel" for SQL frequently, but "eff ay queue" for FAQ way more than "fack."
I didn't encounter "sequel" until some years after I encountered "ess-queue-ell" - had no idea what the person was on about to start with.
I guess it's one of those things that native English speakers don't even know they know. Like "Fewer tests means Less data", rather than "less tests means fewer data", or "six charming small new round green plastic tables" rather than "six plastic charming green round new small tables".
I guess it's one of those things that native English speakers don't even know they know. Like "Fewer tests means Less data", rather than "less tests means fewer data", or "six charming small new round green plastic tables" rather than "six plastic charming green round new small tables".
Or that "the" is pronounced "thuh" before consonant sounds and "thee" before vowel sounds - same rules as "a"/"an" but no difference in spelling!
During a congressional hearing, a US Congress representative asked Sundar Pichai for tech support about his daughter's iPhone: https://www.theverge.com/2018/12/11/18136377/google-sundar-p...
It was not an off-topic question, it was making a point about political ads and has nothing to do with the above.
Have you ever been to an open forum? This is exactly what it's like.
Oh boy. I guess you haven't noticed but it's ubiquitous. Every communication channel for a popular program is filled with help requests and feature requests. It might've been alright back in the day when there were much fewer people on the web and apps like VLC were for enthusiasts.
A bug tracker with feature requests for a popular app is like a gang rape these days. Hundreds upon hundreds of “Why is it still not fixed, it should take just ten minutes!!!” The weirdest thing is, trackers for things like Intellij Idea or Node.js are similarly filled with every problem, wish and opinion that users have—you'd think that programmers should know better but apparently not. “Tab to exit parentheses is essential for me, I'm not migrating from Eclipse until this is implemented!”
I almost completely stopped posting issues without code when I saw the scale of this phenomenon.
A bug tracker with feature requests for a popular app is like a gang rape these days. Hundreds upon hundreds of “Why is it still not fixed, it should take just ten minutes!!!” The weirdest thing is, trackers for things like Intellij Idea or Node.js are similarly filled with every problem, wish and opinion that users have—you'd think that programmers should know better but apparently not. “Tab to exit parentheses is essential for me, I'm not migrating from Eclipse until this is implemented!”
I almost completely stopped posting issues without code when I saw the scale of this phenomenon.
This is what I like with Stack Overflow. Most of this kind of posts are removed. Starting to contribute and following the review queues was mind opening. Also it helps me a lot to improve my own question.
Covert spam?
1) Spammer uses a bot to post harmless automated comments
2) Waits for a while, than looks which of his comments ranks higher in Google
3) Edits some of top-ranked comments to include usual viagra ads with hyperlinks to promoted websites
1) Spammer uses a bot to post harmless automated comments
2) Waits for a while, than looks which of his comments ranks higher in Google
3) Edits some of top-ranked comments to include usual viagra ads with hyperlinks to promoted websites
This sort of thing was so much more common (and worse) in the late 90s/early 2000s.
You couldn't write a blog post about some security finding or integration achievement without it attracting a slew of comments from clueless outsourced contractors begging you to teach them how to build or deploy a related enterprise-scale solution.
You couldn't write a blog post about some security finding or integration achievement without it attracting a slew of comments from clueless outsourced contractors begging you to teach them how to build or deploy a related enterprise-scale solution.
First off, let me just say that I use VLC and I think it's really great. I really appreciate the work done: VLC is my preferred application for watching videos on linux or android.
> from the usual security-asshole to some of the nicest guys ever
It's not clear whether the asshole in question is being dogmatic about some ninety-day disclosure-to-publication deadline or whether they're maybe being rude about the project having security bugs. I have read lots of stories (mostly ones shown here on HN) about knee-jerk overreactions from CIO/CTOs from not-too-large or not-too-technical businesses w/vulnerabilities. Those kind of blame-the-messenger things likely shape their behavior with respect to disclosures.
> The result of that, is that when you don't know how much to award for a security issue (is it medium or low?), you decide on the niceness of the reporter :)
Gee, this sounds like it's not considering the impact to the user. Isn't that the intent of impact ratings? I suppose the risk of misclassification here is wasting the budget of the bounty on low-harm issues or dissuading researchers from digging deeper to find the high-impact ones.
> from the usual security-asshole to some of the nicest guys ever
It's not clear whether the asshole in question is being dogmatic about some ninety-day disclosure-to-publication deadline or whether they're maybe being rude about the project having security bugs. I have read lots of stories (mostly ones shown here on HN) about knee-jerk overreactions from CIO/CTOs from not-too-large or not-too-technical businesses w/vulnerabilities. Those kind of blame-the-messenger things likely shape their behavior with respect to disclosures.
> The result of that, is that when you don't know how much to award for a security issue (is it medium or low?), you decide on the niceness of the reporter :)
Gee, this sounds like it's not considering the impact to the user. Isn't that the intent of impact ratings? I suppose the risk of misclassification here is wasting the budget of the bounty on low-harm issues or dissuading researchers from digging deeper to find the high-impact ones.
(author of the blogpost here)
> It's not clear whether the asshole in question is being dogmatic about some ninety-day disclosure-to-publication deadline or whether they're maybe being rude about the project having security bugs.
Being dogmatic with 90days disclosure, would get you a "hardline security reporter", but not an "asshole".
Notably, because there has been no reporter that refused to extend by a reasonable amount of days, for us. "Hey, can we get 120 days, because we got other bugfixes and we want to do all of them together".
No, we're talking about actual assholery here:
- requesting answer and reproducibility in 24hours, and sending 10 mails in the mean time;
- sending the same issues more than 10 times, because the stacktrace he has is slightly different, but refusing to listen when told that this was the same issue, and therefore only one bounty;
- refusing to read the guidelines, and refusing to test the good version, and then insulting us;
- agressivity, or insults, to the point where the HackerOne team had to intervene several times;
- plugging the output of his fuzzer to HackerOne without checking if it actually crashes or if it is a different bug;
- submitting the same bug to a different program (Google Android Apps) to get 2 times the bounty, while the bug DID NOT apply on Android, but he did not even check;
- a few others that I forgot.
So yeah, this is not about dogmatic or hardliners: we know how to deal with those in the open source communities.
> It's not clear whether the asshole in question is being dogmatic about some ninety-day disclosure-to-publication deadline or whether they're maybe being rude about the project having security bugs.
Being dogmatic with 90days disclosure, would get you a "hardline security reporter", but not an "asshole".
Notably, because there has been no reporter that refused to extend by a reasonable amount of days, for us. "Hey, can we get 120 days, because we got other bugfixes and we want to do all of them together".
No, we're talking about actual assholery here:
- requesting answer and reproducibility in 24hours, and sending 10 mails in the mean time;
- sending the same issues more than 10 times, because the stacktrace he has is slightly different, but refusing to listen when told that this was the same issue, and therefore only one bounty;
- refusing to read the guidelines, and refusing to test the good version, and then insulting us;
- agressivity, or insults, to the point where the HackerOne team had to intervene several times;
- plugging the output of his fuzzer to HackerOne without checking if it actually crashes or if it is a different bug;
- submitting the same bug to a different program (Google Android Apps) to get 2 times the bounty, while the bug DID NOT apply on Android, but he did not even check;
- a few others that I forgot.
So yeah, this is not about dogmatic or hardliners: we know how to deal with those in the open source communities.
Did you really get any of these, or were you exaggerating?
>people telling us that the VLC source code was visible
If you really did and they're public anywhere (and the people weren't joking), I'd love to see them. Sounds absolutely amazing.
>people telling us that the VLC source code was visible
If you really did and they're public anywhere (and the people weren't joking), I'd love to see them. Sounds absolutely amazing.
> Did you really get any of these, or were you exaggerating?
All of these, in this single 3-months bug bounty program. I'm absolutely not exaggerating.
> If you really did and they're public anywhere (and the people weren't joking), I'd love to see them. Sounds absolutely amazing.
This is on our private security@ contact. We have one every month, telling us that.
All of these, in this single 3-months bug bounty program. I'm absolutely not exaggerating.
> If you really did and they're public anywhere (and the people weren't joking), I'd love to see them. Sounds absolutely amazing.
This is on our private security@ contact. We have one every month, telling us that.
That's amazing ... I don't know how anyone would even get to the point of realizing VLC has a bug bounty progam without also knowing that VLC is an open source program and therefore the source is supposed to be visible.
>> people ranging from the usual security-asshole
This pretty much illustrates the attitude of most of the bug bounties programs holders.
This pretty much illustrates the attitude of most of the bug bounties programs holders.
VLC have a past with "security-asshole" that could explains why JB seems tired with some members of the infosec community in general. From what I've read from the past controversies, each time a security issue arises in VLC the team is attacked by an angry mob of infosecs.
This blog post closing remarks summarize the recurring issue well: https://www.beauzee.fr/2017/07/04/videolan-and-https/
This blog post closing remarks summarize the recurring issue well: https://www.beauzee.fr/2017/07/04/videolan-and-https/
Yeah, that'd really put me off reporting anything.
If you read a (dead, for some reason) comment by the author, he explains what that means: https://news.ycombinator.com/item?id=20147573
Perhaps he should be more specific in the blog post instead. Removing phrases like "security-asshole" in the first place would also go a long way.
> Removing phrases like "security-asshole" in the first place would also go a long way.
I absolutely refuse to remove phrases like that. This is exactly what some of those people are and because they are security people does not allow them to behave less well than other people.
And I find that I'm being quite polite by not shaming those people publicly.
I absolutely refuse to remove phrases like that. This is exactly what some of those people are and because they are security people does not allow them to behave less well than other people.
And I find that I'm being quite polite by not shaming those people publicly.
hey, I work in a low-level security group under a larger generic security org - at a general level, there are too many security-assholes and they make our lives harder when interacting with developers as they think we're all like that.
security-assholes are a huge problem
security-assholes are a huge problem
That the link to Julia Reda's mentioned bug bounty program, which caused all these new reportings: https://juliareda.eu/2018/12/eu-fossa-bug-bounties/
eg glibc got a payout of 45.000 which means 4 exceptional risk bugs and 1 critical. https://www.intigriti.com/public/project/glibc/glibc
I find that quite disturbing.
eg glibc got a payout of 45.000 which means 4 exceptional risk bugs and 1 critical. https://www.intigriti.com/public/project/glibc/glibc
I find that quite disturbing.
[deleted]
Interestingly I had to enable JS to see the checksum for the file download (?!).
Reproducible builds + a signed list of hashes would be a nice move for security.
Reproducible builds + a signed list of hashes would be a nice move for security.
All videolan files are GPG-signed and have several hashes (md5+sha1+sha256)
Ah, maybe I missed the link on the DL page.
All I see on the DL page are links to the source, nothing on GPG nor hashes
https://www.videolan.org/vlc/#download
When I clicked to DL my version, all I saw was a "click here to see hash" that needed me to enable JS. Just sha256, which is good btw, more is not better when it comes to hashes - sha256 is sufficient.
Many open source projects provide all these on 1 page, rather than rely on complex code to deliver the info or display it on the DL page.
Ex: https://www.torproject.org/download/ lists sigs under each OS option.
All I see on the DL page are links to the source, nothing on GPG nor hashes
https://www.videolan.org/vlc/#download
When I clicked to DL my version, all I saw was a "click here to see hash" that needed me to enable JS. Just sha256, which is good btw, more is not better when it comes to hashes - sha256 is sufficient.
Many open source projects provide all these on 1 page, rather than rely on complex code to deliver the info or display it on the DL page.
Ex: https://www.torproject.org/download/ lists sigs under each OS option.
Well tor project and VLC have a very different audience, but I'll see what I can do.
I totally understand. Back in grad shool I focused on usable security, and usually less clicks to get to something means more likely people will use the info.
Thanks for your help.
Thanks for your help.
I always wondered what purpose these hashes shown on dl pages serve. If someone can hack your website to change out the .exe or whatever, surely they could also just change the hash displayed?
The issue is more a rogue mirror, than the main website being hacked. But yes, this is very true.
What this blog post doesn't mention is that they finally addressed the bug where if you have a broken file and looping enabled, it no longer gives you infinite pop-ups saying it can't play the file
I filed a bug report about something just like that many years ago (hanging in a CPU intensive loop if you remove all the files in the looping playlist out form under it, i.e. a disk drive goes offline or USB stick is unplugged), and he brushed it off and dismissed my bug report, telling me simply not to do that.
And I also took the time to file several other very detailed bug reports against the Video Effects / Magnification Zoom user interface, which is not only ugly and poorly designed from an ergonomic perspective, but actually drawn into the video at video resolution instead of being drawn in an overlay at full screen resolution, so it gets rotated and is unusable when you combine it with Video Effects / Transform / Rotate, because it fails to transform the mouse events the same as the video and user interface. He brushed that one off as working as designed, too. It's still just the same as it was many years ago when I filed that bug report.
I'm serious: Give it a try, you'll fall out of your seat laughing at how terrible it is! Check out the lowres pixelated font it uses to draw "VLC ZOOM HIDE" between the thumbnail and the bizarre curved zoom scale wedge! The mouse target area of the zoom wedge actually diminishes in size with the width of the wedge, until the minimum zoom target area is only one video pixel wide at the bottom, so it's almost impossible to click. (And it's totally impossible to click anywhere when the video is rotated or flipped, since the target area isn't correspondingly transformed.)
Yes, I know the drill: It's free software, so I should just download the source code, read it, figure out the problem, fix it myself, and post a pull request. But I don't feel spending my time doing that after the author of VLC won't even admit there's a problem.
And I also took the time to file several other very detailed bug reports against the Video Effects / Magnification Zoom user interface, which is not only ugly and poorly designed from an ergonomic perspective, but actually drawn into the video at video resolution instead of being drawn in an overlay at full screen resolution, so it gets rotated and is unusable when you combine it with Video Effects / Transform / Rotate, because it fails to transform the mouse events the same as the video and user interface. He brushed that one off as working as designed, too. It's still just the same as it was many years ago when I filed that bug report.
I'm serious: Give it a try, you'll fall out of your seat laughing at how terrible it is! Check out the lowres pixelated font it uses to draw "VLC ZOOM HIDE" between the thumbnail and the bizarre curved zoom scale wedge! The mouse target area of the zoom wedge actually diminishes in size with the width of the wedge, until the minimum zoom target area is only one video pixel wide at the bottom, so it's almost impossible to click. (And it's totally impossible to click anywhere when the video is rotated or flipped, since the target area isn't correspondingly transformed.)
Yes, I know the drill: It's free software, so I should just download the source code, read it, figure out the problem, fix it myself, and post a pull request. But I don't feel spending my time doing that after the author of VLC won't even admit there's a problem.
> and he brushed it off and dismissed my bug report, telling me simply not to do that.
I did not do that. That's totally not true. You are confusing me with someone else.
And the bug is fixed.
> after the author of VLC won't even admit there's a problem.
There is no "the author of VLC". There are many persons, and some of them are nicer than others; but spitting on the project for that is not normal. If you have any bugreport that were closed while they should not (transform related), please mail me.
I did not do that. That's totally not true. You are confusing me with someone else.
And the bug is fixed.
> after the author of VLC won't even admit there's a problem.
There is no "the author of VLC". There are many persons, and some of them are nicer than others; but spitting on the project for that is not normal. If you have any bugreport that were closed while they should not (transform related), please mail me.
I'll try to dig up the bug report I wrote.
Will you at least acknowledge my criticisms of the Video Effects user interface problems, please? Have there ever been any bug reports on that that you can remember? I'll try to dig that one up too.
While you're here, I'm really curious: What was the thinking behind the design of the Video Effects / Magnification Zoom interface? Why does it draw into the video instead of using an overlay? Why does the mouse target area of the zoom wedge diminish to be almost impossible to hit? Why doesn't it transform the mouse coordinates for the zoom controls when it rotates the video? Why that font for "VLC ZOOM HIDE"? I understand what "ZOOM" and "HIDE" do, but what is "VLC" for? Just to remind me I'm using VLC?
Will you at least acknowledge my criticisms of the Video Effects user interface problems, please? Have there ever been any bug reports on that that you can remember? I'll try to dig that one up too.
While you're here, I'm really curious: What was the thinking behind the design of the Video Effects / Magnification Zoom interface? Why does it draw into the video instead of using an overlay? Why does the mouse target area of the zoom wedge diminish to be almost impossible to hit? Why doesn't it transform the mouse coordinates for the zoom controls when it rotates the video? Why that font for "VLC ZOOM HIDE"? I understand what "ZOOM" and "HIDE" do, but what is "VLC" for? Just to remind me I'm using VLC?
> Will you at least acknowledge my criticisms of the Video Effects user interface problems, please? Have there ever been any bug reports on that that you can remember? I'll try to dig that one up too.
Of course, the video filters UX and UI in VLC is really awful, but very hard to debug for now.
> What was the thinking behind the design of the Video Effects / Magnification Zoom interface?
It was a very old filter done for the time where you could use remotes through STB and where the filter was streamed.
> Why doesn't it transform the mouse coordinates for the zoom controls when it rotates the video?
Because rotation was done a long time after, and because rotation is applied at the end, so it can be done on the GPU, while the transform is done before.
All that is very buggy, sure. But it requires some core changes that we are doing now 4.0 to improve them quite a bit.
Of course, the video filters UX and UI in VLC is really awful, but very hard to debug for now.
> What was the thinking behind the design of the Video Effects / Magnification Zoom interface?
It was a very old filter done for the time where you could use remotes through STB and where the filter was streamed.
> Why doesn't it transform the mouse coordinates for the zoom controls when it rotates the video?
Because rotation was done a long time after, and because rotation is applied at the end, so it can be done on the GPU, while the transform is done before.
All that is very buggy, sure. But it requires some core changes that we are doing now 4.0 to improve them quite a bit.
You really shouldn't accept features that don't work and allow "very buggy" yet only marginally useful untested features to exist in the code base for decades.
If a new feature breaks an existing feature, then don't accept it until the developer fixes the problem. And simply don't accept untested features with such tightly coupled interactions with so many different parts of the system.
If you let anybody who wants toss in willy nilly unreviewed random features that can all be enabled at once, but have never been tested against each other, then you're going to have a lot worse than user interface bugs: you're going to have security bugs.
The video effects interface clearly lets you enable them all at once, so they should have been tested together, and the bugs either fixed or the features rejected until they were.
I could also write a lot of bug reports about the spectacularly horrible Video Effects / Crop user interface (and how it interacts with rotations), as well as about why the shuffle button sometimes inexplicably turns on when you press the repeat button (it must be a Heizenbug since it's not doing it now, but I'm sure I've seen it do that many times, causing me to have to click again and again to get it back to how I wanted it). But I was discouraged after you brushed off my previous bug reports.
As it turns out, I already described a lot of the Video Effects user interface bug in great detail five years ago, but your reply brushed of what I said without acknowledging it, and literally discouraged me from writing detailed descriptions of bugs, how to reproduce them, and how they interact with each other: "If you did shorter posts, maybe people will read them...".
I will point out that your very own signature quoted at the end says "If you want an answer to your question, just be specific and precise. Don't use Private Messages." I was being specific and precise, and not using private messages. That's why I'm being specific and precise and posting this publicly: Because you said so.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>There are many things about the "Video Effects" window that are terribly designed and implemented.
>Is it really supposed to randomly enable the effects when you change movies, some times remembering them from movie to movie, sometimes forgetting them, sometimes even remembering between invocations of VLC, and sometimes not?
>Is there some reason the "crop" dialog only lets you click on the arrows to change it from 0 to 100 pixels, but you can enter any number and it's not limited to the actual video size? And why the scale seems to be greater than pixels when cropping 90 degree rotated video? And that it's so incredibly hard to reset or change the numbers, resulting in pop-ups that scold you for entering a bad number, instead of helping you correct the error? Is there some reason the letters "px" follow the number, and it's an error to enter other letters or if you accidentally delete one of the letters? That "crop" dialog seems to be as user hostile and maliciously designed as the magnification dialog (although at least it is not drawn over the video in low resolution pixels -- even though it would be much easier to use than the four numeric fields, if that were the case and it were well designed).
>There are just so many problems with so many parts of the VLC user interface, that it's extremely hard to keep it down to "a couple of small paragraphs". Is there a back story about the design and implementation of those Video Effect dialogs, and why they are so terrible? Were they done by the same person? Or did many different people contribute to them, with no overall design or code review?
>Is there something about the Mac version of VLC that makes it fundamentally random and non-deterministic? Does the Windows version suffer from the same kind of unpredictability? (I only use the Mac version regularly.)
>[...] The reason it's so hard to enter a number, is that you have to select both the number and the "px" which is separated by a space, in order to delete them before typing the new number, and it's very easy to screw that up, because the field is so small, and double or triple clicking is so unreliable, and most of the time does not actually select both words, but one or the other, or part of each, so when you type a new number, it often still has the prefix of part of the previous number, or the suffix of part of the space followed by "px", so it is syntactically invalid, then the extremely obnoxious dialog pops up and scolds me for entering an invalid syntax, without actually doing anything to help correct the problem, as I already described.
>A single click simply sets the cursor position without selecting any of the text, so if you type a number, it will definitely be a syntax error.
>A double click selects either the number, or the "px", or the space between them, or most likely (since the area is the largest) double clicking in the space to the left of the number selects absolutely nothing and leaves the cursor before the number. So in most of those cases, typing a number will result in a syntax error, which leads to the punishment of the obnoxious dialog:
>"The value "0 px0 is invalid." Please provide a valid value. [Discard changes] [OK]" -- the escape key does NOT dismiss the dialog. The return key goes back to editing the field with the invalid value, and pressing return again pops up the same error message, so you have to type "cmd-a" to select all and then enter a correct value. Terrible user interface design.
>[...] "0px" is invalid. when you type "0 px", the space does not appear until you type the "p", which leads you to think it's ignoring the space even though it's not. If you're going to REQUIRE people to type a space between "0" and "px", then you should bloody well echo it when people enter it.
>The "px" suffix is totally useless. No, "10%" does not work. "10 %" does not work. "10 + 10" does not work. Nothing I can think of works. The " px" suffix is just useless decoration that does NOTHING useful but make it very easy to make a syntax error. [...]
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
If a new feature breaks an existing feature, then don't accept it until the developer fixes the problem. And simply don't accept untested features with such tightly coupled interactions with so many different parts of the system.
If you let anybody who wants toss in willy nilly unreviewed random features that can all be enabled at once, but have never been tested against each other, then you're going to have a lot worse than user interface bugs: you're going to have security bugs.
The video effects interface clearly lets you enable them all at once, so they should have been tested together, and the bugs either fixed or the features rejected until they were.
I could also write a lot of bug reports about the spectacularly horrible Video Effects / Crop user interface (and how it interacts with rotations), as well as about why the shuffle button sometimes inexplicably turns on when you press the repeat button (it must be a Heizenbug since it's not doing it now, but I'm sure I've seen it do that many times, causing me to have to click again and again to get it back to how I wanted it). But I was discouraged after you brushed off my previous bug reports.
As it turns out, I already described a lot of the Video Effects user interface bug in great detail five years ago, but your reply brushed of what I said without acknowledging it, and literally discouraged me from writing detailed descriptions of bugs, how to reproduce them, and how they interact with each other: "If you did shorter posts, maybe people will read them...".
I will point out that your very own signature quoted at the end says "If you want an answer to your question, just be specific and precise. Don't use Private Messages." I was being specific and precise, and not using private messages. That's why I'm being specific and precise and posting this publicly: Because you said so.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>There are many things about the "Video Effects" window that are terribly designed and implemented.
>Is it really supposed to randomly enable the effects when you change movies, some times remembering them from movie to movie, sometimes forgetting them, sometimes even remembering between invocations of VLC, and sometimes not?
>Is there some reason the "crop" dialog only lets you click on the arrows to change it from 0 to 100 pixels, but you can enter any number and it's not limited to the actual video size? And why the scale seems to be greater than pixels when cropping 90 degree rotated video? And that it's so incredibly hard to reset or change the numbers, resulting in pop-ups that scold you for entering a bad number, instead of helping you correct the error? Is there some reason the letters "px" follow the number, and it's an error to enter other letters or if you accidentally delete one of the letters? That "crop" dialog seems to be as user hostile and maliciously designed as the magnification dialog (although at least it is not drawn over the video in low resolution pixels -- even though it would be much easier to use than the four numeric fields, if that were the case and it were well designed).
>There are just so many problems with so many parts of the VLC user interface, that it's extremely hard to keep it down to "a couple of small paragraphs". Is there a back story about the design and implementation of those Video Effect dialogs, and why they are so terrible? Were they done by the same person? Or did many different people contribute to them, with no overall design or code review?
>Is there something about the Mac version of VLC that makes it fundamentally random and non-deterministic? Does the Windows version suffer from the same kind of unpredictability? (I only use the Mac version regularly.)
>[...] The reason it's so hard to enter a number, is that you have to select both the number and the "px" which is separated by a space, in order to delete them before typing the new number, and it's very easy to screw that up, because the field is so small, and double or triple clicking is so unreliable, and most of the time does not actually select both words, but one or the other, or part of each, so when you type a new number, it often still has the prefix of part of the previous number, or the suffix of part of the space followed by "px", so it is syntactically invalid, then the extremely obnoxious dialog pops up and scolds me for entering an invalid syntax, without actually doing anything to help correct the problem, as I already described.
>A single click simply sets the cursor position without selecting any of the text, so if you type a number, it will definitely be a syntax error.
>A double click selects either the number, or the "px", or the space between them, or most likely (since the area is the largest) double clicking in the space to the left of the number selects absolutely nothing and leaves the cursor before the number. So in most of those cases, typing a number will result in a syntax error, which leads to the punishment of the obnoxious dialog:
>"The value "0 px0 is invalid." Please provide a valid value. [Discard changes] [OK]" -- the escape key does NOT dismiss the dialog. The return key goes back to editing the field with the invalid value, and pressing return again pops up the same error message, so you have to type "cmd-a" to select all and then enter a correct value. Terrible user interface design.
>[...] "0px" is invalid. when you type "0 px", the space does not appear until you type the "p", which leads you to think it's ignoring the space even though it's not. If you're going to REQUIRE people to type a space between "0" and "px", then you should bloody well echo it when people enter it.
>The "px" suffix is totally useless. No, "10%" does not work. "10 %" does not work. "10 + 10" does not work. Nothing I can think of works. The " px" suffix is just useless decoration that does NOTHING useful but make it very easy to make a syntax error. [...]
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
Re: does vlc really have a zoom feature ?
Post by Jean-Baptiste Kempf » Wed Jul 30, 2014 10:06 pm
If you did shorter posts, maybe people will read them...
Jean-Baptiste Kempf
http://www.jbkempf.com/ - http://www.jbkempf.com/blog/category/Videolan
VLC media player developer, VideoLAN President and Sites administrator
If you want an answer to your question, just be specific and precise. Don't use Private Messages.
As a bystander, I have not checked the earlier correspondence you mentioned, but this post comes off as quite excessively aggressive. If they were unfairly dismissive, that’s one thing, but you’re in no position to demand that they fix or improve anything in particular. If you’re dissatisfied with VLC in any way, you are eligible for a full refund of what you paid for it.
I once also thought that providing detailed descriptions of every possible issue after extensive context was clear communication. I have since learned that this is not at all true.
A very long post cannot be specific, and precision is lost in too much detail.
A very long post cannot be specific, and precision is lost in too much detail.
Here's the thread about "VLC's terrible "Magnification/Zoom" user interface" from July 27, 2014.
I posted a detailed message describing exactly what the problems were (there were MANY), specific and precise step by step instructions detailing exactly how to reproduce them, with references to Fitt's Law on wikipedia to support my points about usability.
You eventually replied "If you did shorter posts, maybe people will read them..." to which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you." And then I gave up trying to help you. (Yet here we are, again! So why don't you give it another go, and acknowledge the problem, please?)
That's what I consider "brushing off", when you won't take the time to even read what I wrote, yet spent at least as much time arguing and telling me that you didn't read what I wrote and that I should do shorter posts, as it would have taken you to read what I wrote in the first place.
Do you not bother reading long detailed security bug reports too? Or only if they are very polite and complementary? If your skin is so thin that you deal with constructive input about security bugs the same way as you dealt with my report, then VLC users are in big trouble.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>[...] The terrible things about the design of the VLC magnification user interface are as follows: [...]
dfuhrmann>Sorry, but instead writing your really long post, you would better do fill a short and precise enchanchment request at your bug tracker for this issue. Actually, I stopped reading in the middle.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>Of course, I was planning on filing a lot of bugs.
>But of course I also want to discuss the bugs here FIRST, to give anybody who thinks so the chance to chime in that it's designed to work that way on purpose, or that they don't consider it a bug for some reason.
I gave a link to another thread where Jean-Baptiste Kempf brushed off another similar bug report, "hot key magnification. does it exist?" on Jun 12, 2012:
https://forum.videolan.org/viewtopic.php?f=12&t=101741&p=343...
A user described the problem, and Jean-Baptiste replied smugly but incorrectly with the single character "z", and the user replied "Thanks for the response, Jean-Baptiste, but you did NOT read what I wrote."
He was never able to get you to listen to what he was saying or take him seriously, and you never followed up on his clarification. He finally said "Please read my original question again. Maybe you, too, are confused by the nomenclature. Zoom ("z") is NOT the same as magnification.".
That's what I call rudely brushing off and ignoring valid bug reports. And it worries me that this well established pattern might apply to security bugs, too.
And here are two about the much more terrible infinite loop problem:
Here's the "Infinite loop on playlist" one from March 5 2012, in which the developer Rémi Denis-Courmont brushed off the report with "That's not really a bug. VLC is doing what you told it to... The obvious solution would be to stop the playlist whenever an error occurs. But that would probably cause even more frustrations..."
https://forum.videolan.org/viewtopic.php?f=2&t=98866&p=33285...
And here's the "Infinite loop on missing files" from October 23, 2013, where Jean-Baptiste Kempf himself brushes it off with "Known limitation."
https://forum.videolan.org/viewtopic.php?f=14&t=114668&p=388...
Two times that bug was reported on the discussion groups, and brushed off. Once by another developer. Once by you. Do you remember now?
I posted a detailed message describing exactly what the problems were (there were MANY), specific and precise step by step instructions detailing exactly how to reproduce them, with references to Fitt's Law on wikipedia to support my points about usability.
You eventually replied "If you did shorter posts, maybe people will read them..." to which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you." And then I gave up trying to help you. (Yet here we are, again! So why don't you give it another go, and acknowledge the problem, please?)
That's what I consider "brushing off", when you won't take the time to even read what I wrote, yet spent at least as much time arguing and telling me that you didn't read what I wrote and that I should do shorter posts, as it would have taken you to read what I wrote in the first place.
Do you not bother reading long detailed security bug reports too? Or only if they are very polite and complementary? If your skin is so thin that you deal with constructive input about security bugs the same way as you dealt with my report, then VLC users are in big trouble.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>[...] The terrible things about the design of the VLC magnification user interface are as follows: [...]
dfuhrmann>Sorry, but instead writing your really long post, you would better do fill a short and precise enchanchment request at your bug tracker for this issue. Actually, I stopped reading in the middle.
https://forum.videolan.org/viewtopic.php?f=12&t=103604&p=407...
>Of course, I was planning on filing a lot of bugs.
>But of course I also want to discuss the bugs here FIRST, to give anybody who thinks so the chance to chime in that it's designed to work that way on purpose, or that they don't consider it a bug for some reason.
I gave a link to another thread where Jean-Baptiste Kempf brushed off another similar bug report, "hot key magnification. does it exist?" on Jun 12, 2012:
https://forum.videolan.org/viewtopic.php?f=12&t=101741&p=343...
A user described the problem, and Jean-Baptiste replied smugly but incorrectly with the single character "z", and the user replied "Thanks for the response, Jean-Baptiste, but you did NOT read what I wrote."
He was never able to get you to listen to what he was saying or take him seriously, and you never followed up on his clarification. He finally said "Please read my original question again. Maybe you, too, are confused by the nomenclature. Zoom ("z") is NOT the same as magnification.".
That's what I call rudely brushing off and ignoring valid bug reports. And it worries me that this well established pattern might apply to security bugs, too.
And here are two about the much more terrible infinite loop problem:
Here's the "Infinite loop on playlist" one from March 5 2012, in which the developer Rémi Denis-Courmont brushed off the report with "That's not really a bug. VLC is doing what you told it to... The obvious solution would be to stop the playlist whenever an error occurs. But that would probably cause even more frustrations..."
https://forum.videolan.org/viewtopic.php?f=2&t=98866&p=33285...
And here's the "Infinite loop on missing files" from October 23, 2013, where Jean-Baptiste Kempf himself brushes it off with "Known limitation."
https://forum.videolan.org/viewtopic.php?f=14&t=114668&p=388...
Two times that bug was reported on the discussion groups, and brushed off. Once by another developer. Once by you. Do you remember now?
Excellent point: yes, we fixed (actually worked-around) that bug in this release.
Sorry about forgetting about it: I cared more about the FOSSA project here, and forgot about this.
Sorry about forgetting about it: I cared more about the FOSSA project here, and forgot about this.
Oh, don't get me wrong, I'm very grateful! I just wanted to mention it to encourage others to upgrade ;)
That’s not a security bug, though?
https://www.sstic.org/2019/presentation/keynote_2019/
They did pay for the bugs, but with "large extra-bonuses for fixes". Maybe this will pave the road to a different approach.