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.
[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.
>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.
Why would you assume that such permission would be "special" to Debian? It's an icon. There is zero reason for a search engine to restrict such use (and distribution).
>There is zero reason for a search engine to restrict such use (and distribution).
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.
> and the licensing that they'd offer would likely not allow use for any purpose
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?
>Do you really think Google or Yahoo would just say, "No, we don't care about being in Firefox/Iceweasel's default search list"?
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.
> simple pieces can become incredibly useful when you find a clever way to combine them
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?
I find it difficult to believe you cannot answer that question on your own.
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.
I was talking about the safe browsing request. Arguably that's even more important to the average user than TLS safety. MITMs are rare, malware sites are plenty.
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.
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.