If I had to summarize the bad security design that is epidemic in the software industry, this would be a good candidate. Security is about always being vigilant and minimizing potential risks, and not the roughly boolean categorization that most people use, where everything judged "safe" or "unsafe".
TL;DR - Stop using "default allow"!
You would think that programmers (and engineers in general) would understand that understand how small, simple pieces can become incredibly useful when you find a clever way to combine them. Unfortunately, the lesson of "information hiding" - and all of the stuff we derive from it, like {object,aspect}-oriented programming and other encapsulation techniques - end up being ignored when discussing security.
Applied to web browsers, the burden of proof should be to justify why a request is both necessary and safe. The "necessary" criteria is important, because we do not know how this data could be combined in the future, possibly in damaging ways. A good example of this is how the NSA uses Google's PREF cookies[1] to track sessions. Another example is panopticlick-style browser fingerprinting, where every bit leaked can make the fingerprint more accurate.
The fact that this is about favicons is a perfect demonstration of how this "default allow" attitude. Not only is that not necessary, it can be supplied with the browser[2], completely removing the need for any GET request. Minimizing external requests isn't even considered.
[1] https://www.washingtonpost.com/blogs/the-switch/wp/2013/12/1...
[2] copyright and trademark are poor excuses - if the search engine wants to be in the default set of search tools provided by the browser, they can trivially authorize the redistribution of a a simple icon.
Debian's policy does not allow them to accept "special dispensation" for copyright and trademark permission - either everyone has to get it or Debian can't accept. This is part of why Iceweasel was split from Firefox in the first place:
Per the Debian social contract:
>License Must Not Be Specific to Debian
>_The rights attached to the program must not depend on the program's being part of a Debian system._ If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system.
Because these logos depict their trademarked images, and the licensing that they'd offer would likely not allow use for any purpose. Debian's social policy requires that everything included in their distribution be freely licensed for any use.
Then they don't want to be in the default set of search providers. Seriously, has the art of negotiating been lost completely? Google/Yahoo/etc need that strategic placement far more than they need to enforce some minor point about their logo's trademark. Debian's social policy doesn't mena they have to let themselves be browbeat by businesses without even an attempt at negotiating.
Do you really think Google or Yahoo would just say, "No, we don't care about being in Firefox/Iceweasel's default search list."? Would their shareholders be happy about losing market share over want of a trivial licence?
Given that they haven't freely licensed their images and this has been an issue for some time I'm going to have to say the answer is "yes" because Firefox/Iceweasel download the missing images on startup.
Here's the thing. There's nothing to combine this info with that doesn't already have this info. IP+User agent. This info is sent with every request and any other gathering of data will contain these anyway.
So it's not just harmless in itself, it's harmless, period.
How is this different from OCSP pings and stuff like that?
The difference is that OCSP provides a needed service, the very purpose being related to a TLS connection that the user requested. Checking the CRL is an important part of the TLS security process, and it would be stupid to ignore it.
A favicon provides no security benefit, and is entirely optional.
Yes, it may be true that making a GET request for both a CRL and a favicon might leak more or less the information. That isn't relevant, and misses the point entirely about minimizing the network. We don't know what data is useful. It is entirely possible that the situation can change in the future and previously harmless data can become a part of something greater.
Minimizing network use to what is necessary is an implementation of the "default deny" policy, and it is the only sane security policy because we cannot predict the future. Enumerating badness[1] is always going to end up playing catch-up.
[1] http://www.ranum.com/security/computer_security/editorials/d...
I do think that the favicons could just be integrated.
I don't think there's any point minimizing the network in this specific case. "We don't know what data is useful.", sure, but any other data this can be compounded with _already contains the same information_.
Though yes, stuff could change in the future. I can't see how it could change in any way to make this useful, but you're right, this isn't something we can predict. That point is valid.
Since we know NSA is reading this, it's telling them that you (and they have a good idea who you are if you are connecting from a residential line) just launched your browser. I'd say that's pretty intrusive.
The user-agent is sent for all those connections
https://safebrowsing.google.com/safebrowsing/downloads?clien...
Isn't the API key your fingerprint? The key is not shown here, because the author was showing what the requests look like on first run, subsequent requests would contain your unique ID in them.
Not picking on you specifically, I saw several responses saying the same thing.
No, it's a per-application key, so in this case it would be IceWeasel's key.
There's nothing to stop, say, ebay from serving PHP scripts on ICO extension, processing the request as a pageload and then ultimately returning the icon file, but for anything useful to have been gleaned, it would have generated more requests.
Either it did generate more requests and Mozilla didn't honor them (in which case, yay), or it didn't generate more requests (in which case, yay). The former would be slightly preferred as the latter doesn't prevent ebay from later changing their strategy.
Number one is that it's happening when users don't expect it. As an end user, I don't expect my browser to start making requests until I tell it to.
And it's silly to say the information is "harmless in itself," because most of the information Google, Facebook, Yahoo, etc. collect is harmless in itself. The whole point of those companies is to collect as many tiny pieces of "harmless" information as possible to build up profiles about people.
TBH, I don't trust Google at all on privacy matters any more. The way they try to tie my work Gmail to my personal Gmail, to my youtube viewing and cram everything into Google+ has really rubbed me the wrong way, and I've been moving away from their services as much as possible. The last thing I want is my browser contacting them without my knowledge.
Options -> Security -> deselect "Block reported attack sites" and "Block reported web forgeries". Easy.
There are alternatives for everything out there.