Comment 3 for bug 1532732

On 12.01.2016 10:28, Michi Henning wrote:
> After discussing this with James, here are some thoughts.
>
> Adding direct download of arbitrary remote images opens an attack/bug
> vector. For example, a caller could ask for http://<whatever> and it
> turns out that the remote server (maliciously or otherwise), is very
> slow, or doesn't respond at all until the request times out. This means
> that one application can disable access to remote images for other
> applications because the thumbnailer allows only a limited number of
> outstanding HTTP requests at a time. Or the server could potentially
> return garbage images each and every time, each of which would result in
> an entry in our failure cache. That can have negative performance impact
> on other apps.
>
> But, I don't think all is lost. The pragmatic answer to the problem
> would be for the application to download the image (or audio file, or
> whatever) and simply drop it into the file system somewhere. Then pass a
> URL to that file to the thumbnailer, and it will do the rest
> (extraction, scaling, rotating, caching, etc.)
>
> This isn't quite as convenient as having the thumbnailer do all of the
> work, but I think it might be workable?

The problem with that is that in QML the actual fetching of the image is
hidden behind the scenes. Right now one uses

Image {
  source: someurl
}

and qml does the rest. I think the only way to out a cache in there is
to place it into the imageprovider. Putting that back on the app
developers shoulder is probably causing noone to use it I think.

>
> I'm open to suggestions though. I agree that having this feature would
> be really nice. But we'd have to sort out the potential denial-of-
> service/reliability issues. If the actions of one application can
> disable access to thumbnails for other applications (or significantly
> reduce throughput), we have a problem.

Hmm, so far I was assuming that the cache is per app, instead of a
common pool for every app. Same as I was thinking the maximum number of
concurrent downloads would be on a per-process basis. Wouldn't that make
sense from a security point of view and get away with the above
problems? Now, I have no idea how realistic it would be to change the
thumbnailer to that.

I realize that in the music/video artwork case it totally makes sense to
keep a shared pool of data. In this case tho, I think overlappings
between apps would be quite rare (as each app typically connects to one
remote service) and the gain of splitting caches/logic seems bigger than
the loss if giving up the shared data pool. Would it be possible to use
2 different mechanisms, shared for media artwork, split cache for
arbitrary images?