Re: media.libreplanet.org non-requested confusing auto download issue

[Michael McMahon]

sysadmin@fsf.org would be the address to report problems with
media.libreplanet.org's settings.

Have you checked if this setting is in mediagoblin upstream?

Best,
Michael McMahon | Web Developer, Free Software Foundation
GPG Key: 4337 2794 C8AD D5CA 8FCF  FA6C D037 59DA B600 E3C0
https://fsf.org | https://gnu.org

On 5/5/21 11:51 AM, Jean Louis wrote:
> As for campaigns@fsf.org in copy of this email I suggest that on FSF
> Mediagoblin pages of Libreplanet, preloading should be turned off, and
> poster should be placed instead.
>
> To generate a poster I am scaling video down by using Common Lisp, and
> then generating video thumbnail by using `ffmpeg':
>
> (defun media-scale (width height new-width)
>   "Returns the height proportional to the width
> height, and based on the new width"
>   (let* ((ratio (/ width height))
>          (height (truncate (float (/ new-width ratio)))))
>     (list new-width height)))
>
> (format nil "ffmpeg -y -i '~a' -vframes 1 -s ~ax~a '~a'"
>             video width height temp-thumbnail-320)
>
> For me is important that width and height of the screenshot of video
> corresponds to the same scale as original one. But one could create
> picture first and then resize it with Imagemagick:
>
> Example:
>
> $ ffmpeg -y -i xvideo8.mp4 -vframes 1 xvideo8.jpg
> $ mogrify -resize 320 xvideo8.jpg
>
> that would result in resized video. However MediaGoblin is not fit for
> that, it would require maybe some configuration or even patches.
>
> Then the URL to the final file xvideo8.jpg would be used as
> poster="https://www.example.com/xvideo8.jpg"; that would show in place
> of video.
>
> * Miroslav Rovis <miro.rovis@croatiafidelis.hr> [2021-05-05 17:08]:
>> But since you're on bugs at gnu (as your email says), I hope
>> my lead and your explanation is sufficient to make the
>> change, and I hope it will just happen, silently is fine for
>> me. 
> Definitely not, I do not represent GNU project, I just support GNU
> project. 
>
> GNU project while supported by FSF is in its own, it is not same as
> FSF, though much related. 
>
> Libreplanet.ORG is not GNU project, it is FSF's project. You can
> try reporting to: campaigns@fsf.org
>
>>> In many countries people pay good amounts for data, and often Internet
>>> is not fast, it could take many hours to load such video.
>> It is also that analysis is more than an order of magnitude
>> slower than simple browsing. I can't know what I take into
>> my machine quickly even with year 2020 launched modern
>> (commodity) processor machine (AMD Ryzen 7 Pro 4750G), with
>> unnecessary preloading like this, that only analysis can
>> tell what it (likely) is.
> As I work with Website Revision System in background, I have today
> reworked a plugin for my own publishing that by default no video will
> preload. None was preloaded by default even before, but discussion as
> here helped me realize what is important.
>
>> What I mean is, it took a couple of minutes to preloading-imposed
>> download into browser cache a good portion of grandsun1715.webm
>> file, but when, seeing the quick growing of the network trace and
>> understanding that some unexpected traffic was happening, I cut the
>> network connection (physically), and went on to analyse with
>> Wireshark and some scripts of mine, it took me many hours to reach
>> to my conclusion, because Wireshark, Tcpdump, and other are good
>> tools, but the network is not optimized for analysis, it's optimised
>> for quick use, not analysis...
> To avoid that confusion, next time you can simply use right mouse
> click and option Inspect Element or just F12 in Firefox-based
> browser, then you go to Network tab, reload and watch for things.
>
>> So, many hours it took me to analyze and reach to my (probable)
>> conclusion, including the failed decryption of exactly the huge
>> unexpected download. That basically means that possibly there was
>> MiTM and spoof that happened as well. Hope not, but thearetically
>> possible.
> That is good approach for unknown connections on computer, but the
> above one is so much simpler when you know it was invoked by browser.
>
>> To me, knowing what gets into my machine --and the browser is the
>> most used for intrusion, has the attack surface ridiculously huge
>> and hard to control-- is as important as free software and
>> hardware. Free software and hardware must be safe, else my freedom
>> can easily be compromised and hence it's not freedom anymore. [*]
> Recommended reading:
>
> How to Run a More Secure Browser
> https://www.dragonflybsd.org/docs/handbook/RunSecureBrowser/
>
> When I wish to invoke URL by using the above mentioned DragonFlyBSD
> tip on safe browsing, I am sometimes using this Emacs function:
>
> (defun browse-safe-url (url &optional arg)
>   "Browse URL with b"
>   (let ((username "ano")) ;; different username than my own
>     ;; Insecurity settings for personal DISPLAY only
>     (shell-command "xhost +")
>     ;; Browse URL with different username
>     (async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
>                        (format "exec iceweasel \"%s\"" url))))
>
> Otherwise you may construct command for you:
>
> This allows access to your X Server from other user's space, but is
> insecure if you are in some local network. If you are behind firewall
> it is pretty alright.
>
> $ xhost + 
>
> You must be sudoer in /etc/sudoers and have to configure another user
> name on the system. You then launch a browsre like `iceweasel'
>
> $ sudo su -c -- ANOTHER-USER -c iceweasel
>
> Then browser will launch in other user's space. 
>
> The assumption is that in that user's space you should not keep any
> sensitive private files.
>
>