Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We analyzed 425k favicons

iconmap.io

Post reply on HN
Print view View original

71–80 of 131 posts

Re: We analyzed 425k favicons

#71

Post by jiggunjer »

jiggawatts wrote: post #59
shuntress wrote: post #54

Earlier quoted context omitted.

> "had their nephew throw up a wordpress site instead of hiring a professional" The web is supposed to be accessible to everyone. This type of "blame the victim" attitude is a poor way to handle criminal activity.

If they had used static content, it would remain 100% accessible to them, but also vastly more secure. Dynamic content generation on the fly for a blog is unnecessary complexity that invites attacks.

wouldn't that preclude a few popular features like a rich text editor?

Re: We analyzed 425k favicons

#72

Post by lmm »

MrBoomixer wrote: post #65
dmurray wrote: post #61

Earlier quoted context omitted.

The gzipped size is probably the correct metric to care about, right? Virtually all browsers will support that. Sure, Discord could do a bit better, but it's not correct to knock them here for costing their users 285KB.

This is bad math, not researched heavily but in 2020 discord had 300 million users. 285kb goes a long way with wasted energy and bits flowing through the pipes. I agree generally with what your saying though gzipped sizes are what's being sent some CPU usage somewhere to unzip. less bytes == less waste?

PNG basically includes gzip in the file format, so you're not reducing the amount of CPU used, you're just moving where it happens.

Re: We analyzed 425k favicons

#73

Post by lmm »

thrdbndndn wrote: post #68
Quai wrote: post #63

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). 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. Back then we stored the booksmarks in a home grown XML data store (built on top of mysql, acting m…

Wait, so you can see user's data directly?

GP is talking about something implemented in 2008. It was a different time and a different mentality.

Re: We analyzed 425k favicons

#74

Post by charcircuit »

shuntress wrote: post #54
jacurtis wrote: post #40

Earlier quoted context omitted.

What most of them do is they will use Wordpress exploits to get into random wordpress website ran by people who know nothing about managing a website and are running on a $3/mo shared hosting account. After they get into these random wordpress sites, then then embed links back to their sketchy site in obscure places on the wordpress site that they hacked, so that owners of the site don't notice, but search bots do. T…

> "had their nephew throw up a wordpress site instead of hiring a professional" The web is supposed to be accessible to everyone. This type of "blame the victim" attitude is a poor way to handle criminal activity.

and anyone can hire me to design them a website.

Re: We analyzed 425k favicons

#75

Post by anyfoo »

notatoad wrote: post #67
anyfoo wrote: post #32

Earlier quoted context omitted.

The opposite is the case. Overall, being too lenient in what code accepts and applying heuristics will lead to way worse problems down the line. For example, you want your compiler to fail hard instead of saying: "Oh, this isn't a pointer, but I'm sure you meant well, I'm just going to treat it as a pointer!" In this particular case, it seems to me that the hints serve no purpose and should be abolished, and in the m…

The hints are not a hint in how to render the icon - browsers don't need hints for that. the hints are an instruction to browsers on which icon to download in the case where multiple icons are specified. if you are safari and you don't know how to display SVG favicons, then you don't need to waste bytes downloading a favicon only to fail to display it. the HTML does not limit a site to only one favicon.

Why is that not done through the MIME type and using HEAD? The server is apparently much better able to figure out the MIME type through magic numbers and file extensions of the actual file, than the author (human or not) of the HTML, as we see.

The same headers also inform the browser that they can skip downloading a favicon that they consider too big, for example.

Re: We analyzed 425k favicons

#76

Post by mfkp »

jacurtis wrote: post #40
noitpmeder wrote: post #31

Earlier quoted context omitted.

Does anyone know the story behind these? How do seemingly obscure sites consistently get massive amount of obscure content placed highly in results.

What most of them do is they will use Wordpress exploits to get into random wordpress website ran by people who know nothing about managing a website and are running on a $3/mo shared hosting account. After they get into these random wordpress sites, then then embed links back to their sketchy site in obscure places on the wordpress site that they hacked, so that owners of the site don't notice, but search bots do. T…

I recently saw and reported one to a local business.

If you typed in the domain and visited directly, it wouldn't redirect to the scam site. But if you clicked on a link from a google search, then it would redirect.

Probably makes it harder to find for small website owners if they're not clicking their own google searches.

Re: We analyzed 425k favicons

#77

Post by jiggawatts »

jiggunjer wrote: post #71
jiggawatts wrote: post #59

Earlier quoted context omitted.

If they had used static content, it would remain 100% accessible to them, but also vastly more secure. Dynamic content generation on the fly for a blog is unnecessary complexity that invites attacks.

wouldn't that preclude a few popular features like a rich text editor?

You can have a separate system, even a locally running desktop app do that. You can still have a database, complex HTML templating, and image resizing! You just do it offline as a preprocessing step instead of online dynamically for each page view.

Unfortunately, this approach never took off, even though it scales trivially to enormous sites and traffic levels.

I recently tried to optimise a CMS system where it was streaming photos from the database to the web tier, which then resized it and even optimised it on the fly. Even with caching, the overheads were just obscene. Over a 100 cores could barely push out 200 Mbps of content. Meanwhile a single-core VM can easily do 1 Gbps of static content!

Re: We analyzed 425k favicons

#78

Post by scrollaway »

anyfoo wrote: post #75
notatoad wrote: post #67

Earlier quoted context omitted.

The hints are not a hint in how to render the icon - browsers don't need hints for that. the hints are an instruction to browsers on which icon to download in the case where multiple icons are specified. if you are safari and you don't know how to display SVG favicons, then you don't need to waste bytes downloading a favicon only to fail to display it. the HTML does not limit a site to only one favicon.

Why is that not done through the MIME type and using HEAD? The server is apparently much better able to figure out the MIME type through magic numbers and file extensions of the actual file, than the author (human or not) of the HTML, as we see. The same headers also inform the browser that they can skip downloading a favicon that they consider too big, for example.

HEAD support is never a guarantee, and content type auto detection is just another kind of heuristics.

Re: We analyzed 425k favicons

#79

Post by anyfoo »

scrollaway wrote: post #78
anyfoo wrote: post #75

Earlier quoted context omitted.

Why is that not done through the MIME type and using HEAD? The server is apparently much better able to figure out the MIME type through magic numbers and file extensions of the actual file, than the author (human or not) of the HTML, as we see. The same headers also inform the browser that they can skip downloading a favicon that they consider too big, for example.

HEAD support is never a guarantee, and content type auto detection is just another kind of heuristics.

Ugh, HEAD is not being universally supported, at least for static content? Okay, I accept that this has value then.

As for the MIME type, for image types I'd say it's more than stable enough. Certainly much, much more stable than the 6.7% error rate mentioned in the article here, I'd be surprised if it was even 1%. If you double click on an image on your desktop for example, you can in almost all cases expect that it will be opened correctly. It ceases being a heuristic entirely if you tell the webserver that *.png is image/png, and only put PNGs with names ending in ".png".

Guess those are the reasons why I got out of web development in 10 years ago, everything's held together by scaffolding and needlessly wasteful and inefficient there.

Re: We analyzed 425k favicons

#80

Post by memco »

nerfhammer wrote: post #35
arp242 wrote: post #26

I got mine down to 160 bytes with some pixel tweaking and converting it to a 16-color indexed PNG. It's not a lot of work or very difficult (I'm an idiot at graphics editing), but you do need to spend the (small amount of) effort. I embed it as a data URI and it's just four lines of (col-80 wrapped) base64 text, which seems reasonable to me. Haven't managed to get my headshot down to less than 10k without looking hor…

there are png optimizer programs, e.g. optipng

ImageOptim was a favorite of mine. They have a standalone mac app and a webservice. It combines several of these tools into a single GUI.
Post reply on HN