touch-packages team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

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?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to thumbnailer in Ubuntu.
https://bugs.launchpad.net/bugs/1532732

Title:
  Caching for arbitrary images on the web/remote hosts

Status in thumbnailer package in Ubuntu:
  New

Bug description:
  I frequently hit the use case that I query some host (might be in my
  local network, might be on the internet) for a list of things. The
  result set comes with images so I present a scrollable list of all
  those things to the user.

  Problem now is that with the images being fetched, the list scrolling
  is somewhat stuttery and also presents empty images at first which
  then are only filled with content a bit later. Scrolling the list back
  up, same thing again happens as the in-QML caches we have are based on
  RAM and with that can't hold tons of images. They are discarded and
  scrolling the list back up causes them to be reloaded.

  
  It would be great if the Thumbnailer could take care of this and fetch and cache them for the developer.

  One point to think about would be timeouts. Some use cases will always
  present the same image again. For example in kodimote I fetch the
  music artwork given by kodi. The artwork won't ever change, so the
  cache can be persistent. At the same time, fetching things from an
  online server *might* change over time. Ideally this would be
  configurable so that the developer can specify some cache time out for
  entries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1532732/+subscriptions