Vanillicon Proxy: Suggestion for more Privacy and Reliability

korelstar

The vanillicon plugin produces links to vanillicon.com, which leads to third-party domain requests when user accesses a forum. This is disadvantageous due to multiple reasons:

• if there is a problem connecting to the vanillicon.com (e.g. network is broken or the server is down), the user images can't be displayed and the page loading is slowed down.
• every request to a third-party domain could potentially be used for user tracking and is therefore bad for privacy.

In order to eliminate these problems, I have implemented a proxy plugin, which executes the requests to the third-party site instead of the user, and further provides a cache for the images. Therefore, the user now loads the images from the forum server.

I've uploaded the code as a new plugin vanillicon proxy, but I suggest to integrate the proxy and caching code into the official plugin resp. the official vanilla release (since vanillicon is integrated into vanilla since v2.2). This would also be beneficial for the operators of vanillicon.com, since the number of requests would decrease notably.

What do you think about this?

hgtonight

Not a terrible idea.

My biggest criticism is that it will never re-request the image, even on a hard refresh from the client.

Other than that, you should be placing these images in the /cache or /uploads folders which have to be writable to install vanilla.

Finally, the structure method will be called every time vanilla is updated or the utility structure method is called. Since you are only setting a config, I would move that to the setup method and remove it.

Great job otherwise

phreak

Thanx that is a good move @korelstar.

One question. Would my users that have a Vanillicon now and are quiet happy with their Avatar get a new one or stay with the current? They are sometimes quiet unhappy if their userpic changes.

korelstar

Thanks for the constructive feedback!

@hgtonight said:
My biggest criticism is that it will never re-request the image, even on a hard refresh from the client.

Why would you need that? The images are static and don't change, so the only situation would be an erroneous transfer between vanillicon.com and the forum. But I thought about that, too. My proposal is to provide a button in the admin dashboard, in order to delete the full cache. I think, this would be sufficient.

Other than that, you should be placing these images in the /cache or /uploads folders which have to be writable to install vanilla.

Good idea. Since it's more like a cache, I would move the directory there. But: will the cache directory be always accessible from the web? Since the other data in that directory effectively should not be accessible from web, the policy of this directory might change in future vanilla releases. I think I will chose the upload directory, just to be on the safe side.

Finally, the structure method will be called every time vanilla is updated or the utility structure method is called. Since you are only setting a config, I would move that to the setup method and remove it.

Hmm. This was not my idea, I just copied this part from the official vanillicon plugin v2, which is integrated in vanilla 2.2. However, I will change my code according to your remarks.

@phreak said:
One question. Would my users that have a Vanillicon now and are quiet happy with their Avatar get a new one or stay with the current? They are sometimes quiet unhappy if their userpic changes.

No, the avatar doesn't change. Since it uses the same configuration key for the vanillicon version setting (v1 or v2), there is a seamless transition from the original vanillicon plugin to the vanillicon proxy.

hgtonight

@korelstar said:
Thanks for the constructive feedback!

@hgtonight said:
My biggest criticism is that it will never re-request the image, even on a hard refresh from the client.

Why would you need that? The images are static and don't change, so the only situation would be an erroneous transfer between vanillicon.com and the forum. But I thought about that, too. My proposal is to provide a button in the admin dashboard, in order to delete the full cache. I think, this would be sufficient.

The advantage of using a service like vanillicon or gravatar is getting continuous improvements for "free". Having a cache that never updates negates that.

Keep up the great work

korelstar

Which kind of improvement would this be for vanillicon? It's just about images, and the visual part of that image should not change for a specific filename. There is very few space left for improvements.

Nevertheless, I could implement periodically updates for the cache. There are several possibilities:

1. manual refresh in the admin dashboard (plugin settings)
2. automatic refresh when the plugin is (re-)activated
3. automatic refresh when the forum is updated (it should be possible to hook up into the update process, hmm?)
4. a periodical job which removes all files once a (e.g.) month
5. a periodical job which (e.g.) daily removes all files older than a (e.g.) month
6. automatic deletion of old files when accessing the admin dashboard (this should be possible, hm?)

Does vanilla provides an API for periodical (cron-like) jobs? Due to performance reasons, I would not do this job on every page access. Hence, 4. and 5. might not be possible to realize (I would not depend on cron on the server).

hgtonight

You could check to see if the file is X days old upon access and refresh it then. Look into filemtime.

korelstar

You're right, I should have mentioned this possibility in the list, too. However, I've discarded this approach immediately since it requires that every access to an avatar is processed by PHP. This is disadvantageous:

1. it hat negative effects on the performance (the PHP intepreter has to be started etc.)
2. it has negative effects on the client-side caching behavior (without additional mechanisms, the client would re-request the avatar on every page load without using the client-side cache)

In my approach, PHP is only used if the image is not cached already. In the other case, the web server can use all internal optimizations in order to send the image fastly to client (e.g. memory caching, no additional script execution, ...). Furthermore, the web server provides many useful mechanisms for such static files out of the box, such as HTTP headers for caching, partly retransmission etc.

To sum up: Vanilla is slow enough. Therefore, I will not realize your suggestion. ;-)

R_J

What's really great at the Vanillicons is that they are SVG. There might be around 16 different eyes, 16 different mouths and 16 different "heads". The tilt and the colors are no elements but mere style.

So if you create a SVG with all existing elements in it, that file would be quite small. You only would have to load that one and this could be cached. And SVGs can also be enclosed as html elements so you could even choose not to load another external element if you prefer.

All avatars are only styled "instances" of the one SVG and would look like that:

<svg  width="100" height="100">
  <g transform="rotate(20,50,50)" visibility="visible" style="stroke-width:3;stroke:rgb(44,22,77)">
    <use xlink:href="#head-11" style="fill:rgb(0,0,158)"></use>
    <use xlink:href="#eyes-01"></use>
    <use xlink:href="#mouth-08"></use>
  <g>
</svg>  

You could save it to the user table or let it be calculated from the mail hash.

korelstar

@R_J
That's a great idea. But in order to be compatible to vanillicon.com, this approach requires that vanillicon.com publishes the algorithm and the master SVG file (as far as I know, vanillicon isn't open source). I would appreciate that, because I would prefer a local avatar creation with a respective vanilla plugin. Since vanilla has this great plugin framework, there is no need to outsource this task to an external service with all it's disadvantages.

Another aspect is, that only vanillicon v2 uses SVG. v1 use png. Or do they internally use SVG, too?

R_J

I guess there are two ways to provide your users with standard icons: a) use an online service like vanillicon or use some sort of identicon like library which generates the avatars on your own server.

One advantage of online services is that generally you could have the same avatar at different places on the net without uploading your picture. But the service must be widely implemented like gravatar is. The best feature of gravatar is that you only have to update your avatar picture once, if you like to change it. All other services should always fetch the avatar from a central server. So if you use an online service, it cannot serve its extra benefit without adding a lot of additional requests to your page.

While I would expect that the vanillicon generation procedure will not be laid open, no one can stop you from creating your own set of mouths, eyes and heads and generate avatars out of that. Cute round faces can hardly be copy right protected. You could also use some identicon creating library, but personally I prefer the friendly vanillicon faces over the abstract bunch of pixel some identicon libraries generate.

I guess there is a big performance gain possible if you cut down those extra requests from an external server.

If you start creating a plugin, I'd be happy to help out if I can.

---

And just to stop speculating and get an answer from someone who's able to give competent answers on that...
@Linc: would Vanilla Inc. publish the SVGs and the code used to create a Vanillicon from a mail so that it could be made a plugin which doesn't rely on the vanillicon server or will it be kept closed?

Linc

I don't think there's any interest in open sourcing the Vanillicon code because it is designed as a service, not a downloadable product. However, if folks have privacy concerns I'd be happy to look into developing a privacy policy for the service. The lack of one is just us being short on time, not using the data for something nefarious. To my knowledge, we're not collecting or storing information aside from exactly what's required to cache and serve the image files, and overall traffic count. It's pretty a benign side-project we run just to make Vanilla a little nicer to use.

korelstar

@hgtonight
I've implemented your suggestions, released a new version and published it as project on GitHub.
:-)

korelstar

@Linc
I understand, that you want to provide vanillicon.com as a service and do not open source it. However, how does this affects the vanillicon plugin?

I could do a pull request to integrate my extension in the official plugin. We could provide the new cache mechanism as an option which has to be activated in the dashboard. But has such a pull request a realistic chance to be accepted or is this not desired due to company policy?

Linc

I understand why some folks will find this alternative desirable, but I don't think it's a good addition for the core plugin because it increases the bandwidth usage, storage, and (I assume) CPU usage on your server, which for some folks is a super barebones hosting package. It also occurs to me this would work poorly on a multi-frontend system like our cloud solution provides, because you'd end up with copies on every frontend.

korelstar

CPU usage is very low, bandwidth usage is low due to caching, and storage depends on the size of the community (example: 4 MB maximum per 1.000 users).
The extent of copies depends on the overlap of communities (I do not think that this is very high). However, you could link the cache directory to a single place.
Finally, the proxy and caching functionality can be disabled.

So, there aren't any grave technical arguments, but I think your rejection is rather political. But, of course, that's okay.