INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: AndrewFG on December 20, 2013, 03:23:23 am
-
Hi Jim,
It occurs to me that there is probably a generic reason why more AV programs are causing more problems in MC.
I think it is because when MC is playing a track, it is very often transcoding the original file on the fly to another format, and this other format is buffered to a temporary file on disk. Obviously this temporary file is totally new to the PC and as far as the AV is concerned it appeared from nowhere and has no established trust credentials.
When you think about it like that, it seems only natural that an AV application would have heuristics to give special attention to just such types of files.
Perhaps one way to avoid undue attention from AV applications could be to not write such temporary transcoded files onto disk, but keep them instead in RAM. Obviously for really big transcodes you might run out of RAM, but maybe you can do something using Windows paged RAM management system. (At least in that case you would as it were have Microsoft on your side in any discussions with AV vendors...)
EDIT: Another idea could be to apply a Digital Signature to your temporary transcode files using a JRiver signing certificate issued by a globally well known certificate authority (e.g. such as VeriSign). However this might not be possible since you cannot apply a meaningful DSig to a file until after it has been fully written to disk (i.e. until after its contents have become stable).
EDIT 2): We have also recently heard about malware being spread in bogus MP3s so perhaps another way to avoid undue AV attention is to store your temp files using a file extension that is explicitly non executable and explicitly not able to run macros; suggestions would be .tmp or even .txt -- however this might be just too obvious a ploy that any serious AV application would try not to be duped by...
-
I don't think it's just a temp file problem. And spreading a virus in a media file seems impossible to me.
It's a complex subject and the AV industry has a difficult job distinguishing between friend and foe, but it's their job to do, not ours. They've inserted their software between the applications and the OS, so they need to make that work correctly without requiring new work for the applications.
-
It's a complex subject and the AV industry has a difficult job distinguishing between friend and foe, but it's their job to do, not ours. They've inserted their software between the applications and the OS, so they need to make that work correctly without requiring new work for the applications.
Jim, I do agree with you. Really! My suggestions were simply a) advice to help you to signal to the AV vendor that you are indeed a friend rather than a foe (if you refuse to ID yourself to the security guard, then don't blame him if you get shot), and b) suggesting to keep your stuff inside the application (MC) boundary rather than transacting with the OS -- as you say the AV vendors insert themselves at the App/OS interface so if you don't cross that interface you won't get problems...
-
Jim, I do agree with you. Really! My suggestions were simply a) advice to help you to signal to the AV vendor that you are indeed a friend rather than a foe (if you refuse to ID yourself to the security guard, then don't blame him if you get shot), and b) suggesting to keep your stuff inside the application (MC) boundary rather than transacting with the OS -- as you say the AV vendors insert themselves at the App/OS interface so if you don't cross that interface you won't get problems...
If every file needs to be signed, then that's a decision that should be made by the OS, not the app or the AV.
-
If every file needs to be signed, then that's a decision that should be made by the OS, not the app or the AV.
Nope, I don't agree Jim. I think the creator of a file always has an obligation to prove their bona fides. (But I guess that we are unlikely to ever agree on this, so lets not over cook this discussion...)
-
EDIT: Another idea could be to apply a Digital Signature to your temporary transcode files using a JRiver signing certificate issued by a globally well known certificate authority (e.g. such as VeriSign). However this might not be possible since you cannot apply a meaningful DSig to a file until after it has been fully written to disk (i.e. until after its contents have become stable).
Our install and main executables are signed.
But you can't sign temporary conversion files, for three reasons:
1) You can't sign a file that's changing
2) A signed media file may fail to play on some devices
3) We would need to include our secret signing key with the program
-
1) You can't sign a file that's changing
2) A signed media file may fail to play on some devices
3) We would need to include our secret signing key with the program
I knew statement 1).
I suspected statement 2).
And I agree that statement 3) is the killer.