7 ms·
So, from what I gathered it's just the favicons of the search engines, some mozilla country stuff (not sure why) and google safe browsing (which you can turn of
by iMerNibor 11y ago
So, from what I gathered it's just the favicons of the search engines, some mozilla country stuff (not sure why) and google safe browsing (which you can turn off and is a good feature for casual users)
So what's the issue here? All this isnt really a problem and safe browsing is, in my opinion, even good for normal users.
- Manishearth 11y agoI'm pretty sure that these get requests don't even fetch with cookies, so fingerprinting is probably impossible here. The most info they can get is "hey, this ip uses Firefox". Harmless in itself. It can be compounded with more info to track someone, but all of this info already contains IP/browser info so this doesn't help at all.
- dclusin 11y agoI recall reading something on the internet that IP + browser fingerprint is good enough to unique identify a large number of people. Has this changed or otherwise untrue?
- faitswulff 11y agoA quick click here convinced me that this is still the case: https://panopticlick.eff.org/ https://panopticlick.eff.org/
- kbrosnan 11y agoThis is a handful of GET requests for images. You would need a page to fingerprint. The site could get an IP, likely the user agent. Safe browsing requests are sandboxed from all the other Google cookies.
- scottw 11y agoYou sure those are images? All we know for certain is that those are GET requests.
- girvo 11y agoI'd be willing to bet that Firefox would treat them as such, even if they returned something different. Still, those favicons should be bundled instead of making requests, IMO.
- bmelton 11y agoBecause we can see the sum of the requests, I think it's safe to say that they are probably just images. 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.
- takeda 11y agoGeez did you guys even look at the URLs? https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweasel&appver=38.1.0&pver=2.2&key=no-google-api-key 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.
- magicalist 11y ago> Isn't the API key your fingerprint? No, it's a per-application key, so in this case it would be IceWeasel's key.
- takeda 11y agoIn that case why would it make a request with "key=no-google-api-key" then why not use the IceWeasel key right from the start?
- magicalist 11y agoNo clue, but it's not like we have to guess about what it is. It's all covered in the Safe Browsing docs: https://developers.google.com/safe-browsing/lookup_guide#GettingStarted https://developers.google.com/safe-browsing/lookup_guide#Get...
- duskwuff 11y agoGetting the type of "browser fingerprint" they're depending on here requires a bunch of Javascript. You can't get that data from just looking at a single request, which is all that they're getting here.
- HappyTypist 11y agoI think IP + useragent + locale (which is sent with every HTTP request) is enough to pinpoint most users.
- markvdb 11y agoEspecially Debian users ("iceweasel" in the user agent string!)...
- avian 11y agoI made an add-on that tries to help with that: https://github.com/avian2/thawed-weasel https://github.com/avian2/thawed-weasel
- liviu- 11y agoIt's not so much 'Debian users' as 'Iceweasel users' — you can install Firefox from source on Debian, and even use Mint's package repo to install it.
- Manishearth 11y agoBrowser fingerprint requires at least Javascript, and to do it properly you need the ability to run Java/Flash too. These are HTTP requests, not HTML pages which are opened in the browser. Since its not using cookies, these requests only contain the user agent string, which is very far off from any useful kind of tracking-fingerprint.
- rando289 11y ago> Harmless in itself. 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.
- boombip 11y agoReally? Aren't you going to use the browser in about 5 seconds? I'm sure the NSA cares that I checked my mailbox yesterday as well.
- zwarag 11y agoThey don't care about that you checked your mailbox. The problem is that they saved your action for future. Everything you do is saved. That does not mean that they care. But in case they need to care in future. Everything you have done is logged.
- markvdb 11y agoIn the case of Debian, it tells them you are using a specific version of iceweasel, which probably is quite deterministic in combination with the rest of the dragnet.
- raverbashing 11y agoWell, that info in the URL probably means nothing. The user-agent is sent for all those connections
- lmm 11y agoWhenever a new version of Iceweasel hits the repos, a bunch of people upgrade, and perform identical requests. You can figure out how frequently someone checks for updates I guess, but other than that what would you learn? The browser hasn't had the chance to acquire any information that would distinguish you from any of the other Debian users yet.
- jlarocco 11y agoI have a few problems with it, actually. 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.
- magicalist 11y ago> TBH, I don't trust Google at all on privacy matters any more Options -> Security -> deselect "Block reported attack sites" and "Block reported web forgeries". Easy.
- jlarocco 11y agoAfter you've already launched the browser and sent info to Google...
- Qantourisc 11y agoThe information "hey I have an IP and I'm using this browser, and I have a browser at this time" is going to be send A LOT when using the browser for what it's made for. The problems come later when sending every URL to another party (safe browsing). Also from google "Privacy: API users exchange data with the server using hashed URLs, so the server never knows the actual URLs queried by the clients." So it's possibly safe ?
- ionised 11y agoI'm totally Google free save whatever traces of Google tech are in CyanogenMod on my phone and I can't say my life has been negatively affected by going this route. There are alternatives for everything out there.
- pdkl95 11y ago> Harmless in itself. 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/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/ 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.
- Manishearth 11y ago> 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?
- pdkl95 11y agoI 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. [1] http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d...