I worked on Opera Link, the first built-in synchronization between different installations of the Opera browser, both desktop, Opera Mini and Opera Mobile (+ a web view).<p>Favicons got included in the data from day one, and it was awesome to get the look and feel of your bookmark bar/UI with the correct icons right away.<p>Back then we stored the booksmarks in a home grown XML data store (built on top of mysql, acting more or less as a key-value store). This worked quite nice, and it allowed us to easily scale the system.<p>One night the databases and backends handling the client requests suddenly started eating a lot more memory, and the database started using much more storage than normal.<p>As one of only two backend devops working on Opera Link, I had to debug this, and find out what was going on. After a while I isolated the problem to a handful of users. But how could a few users affect the system so much?<p>As a part of the XML data store, we decided naively to store the favicons in the XML, as a base64 encoded string. While not pretty, a 16x16 PNG is not that much data, and even with thousand of bookmarks, the total overhead on compression and parsing was neglishable. What we did not foresee was what I uncovered that night; A semi-popular porn site had changed something on their server. They had started serving the images while also pointing browser to the same images as the favicon! Each image being multiple megabytes, sent from the client, parsed on the backend, decoded, verified, encoded back to base64, added to the XML DOM, serialized, compressed and pushed back to the database...<p>Before going to bed that night, I had implemented a backlist of domains we would not accept favicons for, cleaned up the "affected" user data, and washed my eyes with soap.<p>I miss those days!