which then led me here. It seems that the Kindle Fire not only needs to phone home often, but starts burning battery if it can't! Really poor design.
I'm just trying to figure out if this was because of a newly-blocked device-metrics-us.amazon.com, or if it was an upgrade to the Fire's OS. I suspect the former.
BTW @showipintbri , the app making the requests (according to the battery monitor I've installed) is Amazon Device Metrics. I would like to try disabling it (I only have one Fire tablet), but it wouldn't surprise me if it breaks things. Somebody want to give it a try??
I can't disable the Amazon Device Metrics app on the Kindle Fire, it just restarts anyway.
So instead I've whitelisted device-metrics-us.amazon.com and then added an /etc/hosts entry for it to point to another machine on my local net that is running an SSL server on port 443. It doesn't seem to be processing any requests (no doubt because it has a bogus certificate), but I'm curious whether this will satisfy my KF enough to make it through the night without a 40% battery level drop. I.e., will the app be satisfied that it is resolving the name, but can't actually connect?
This is really awful behavior of the app anyway -- it means that if your KF is in a marginal or non-existent Wifi zone overnight, its battery will drain quickly, while it's "off", for no apparent reason. Nice design, Amazon!
It's good to see my suggestion started off some research on Kindle Fires and the device-metrics-us.amazon.com domain. I find it irritating that the devices behave in this fashion. However, I can't help but ask, does anyone know why this domain is on the block list? What are the Kindle Fires doing with it? Or, said differently, does the domain really belong on the block lists?
There is no one blocklist - several standard blocklists are installed with pi-hole. They do a good job without problems. But you can add or delete lists as you want or need. It is very easy now to turn on/off installed blacklists or to add new blacklists in the admin menu.
Also you can examine which installed and activated blocklist includes this amazon url...
Frank, yes I understand that there are several standard blocklists. device-metrics-us.amazon.com is found in list.0.raw.githubusercontent.com. However, I ask the same question. Does anyone know why this domain is included? The Kindle Fire tablets hit it like crazy when blocked, and it would be good to know what prompted the domain being on this blocklist in the first place.
More from my testing: Sending requests (via /etc/hosts) to a local server seems to slightly extend battery life -- but it still drops from 100% to 80% in a half-day of being unplugged; far worse than before.
I'm trying the control side of the experiment now, and have whitelisted device-metrics-us.amazon.com completely to ensure that I'm seeing the old battery life.
The terrible thing about this design is that if your kindle lives in a place with poor or no wifi reception, then your battery life is going to suffer as it can't find the device-metrics host. And what, exactly, is it doing contacting this host every 4-5 seconds?
It's been few days since I last responded but I wanted to add: I am seeing the same thing!
My kids (2) have Kindle Fire Tablets. I'm seeing both collectively hitting over 50,000 DNS requests per day.
I too noticed my kids tablets battery life draining completely in a day, even when sitting idle and not being used.
What I tried was turning off wifi on the kids tablets. This seems to extend the battery life (like it originally was), not because it's not using wifi but because its not generating over 25,000 DNS requests and web-requests.
Another thing I found was dis-associating from the wifi also extends the battery life, again, this is because it has no way to make the DNS requests. But when wifi is on and you are connected to a network, it will constantly try to connect draining battery.
The next experiment is white-listing the domain and seeing my device battery metrics after.
This is now my top blocked domain as well. I'm going to dive into this a little later to see if it's my Echo that's causing the issue, or if any other devices are hitting it frequently.
can you tell me if you have deactivated pi-hole for a longer time to see if the amount of queries will be reduced to a normal amount?
Also this amount of queries can appear, when some necessary domains are blocked by pi-hole! Then sometimes domains are requested every few seconds. This also happens with Samsung Smart-TVs.
Try it out!
It is important to know how many and which queries appear on your device, BEFORE anything is blocked in pi-hole.
I think a question that hasn't been answered yet was "why is 'device-metrics-us.amazon.com' being blocked in the first place? Is it how amazon delivers ad's?
I've got half a dozen Echo Dots in my house. I'd like to know if there's any benefit to whitelisting this domain (or whatever the cleanest way to un-blacklist it is).
first, list.0.raw.githubusercontent.com is not the real url of the blacklist containing this query, but a placeholder that says that this query is found in the first active entry of your blacklists.
So list.0... is the first, list.1... the second and so on...
So to get back to your question, this query is used by the Steven Black list, also by Arielle and Quidsub lists.
As you can see, not all lists are containig this query.
Why? Because not all developers of "tracking-blacklists" want to block this domain, but some do. It's a metrics url which is used by several other companies tracking your using behaviour while using their products.
So feel free to whitelist this query if you have no problems with user tracking, or block it when there are no disadvantages in user experience using Amazon products...
As we've accrued more devices that are constantly sending information about us, the ads and targeted marketing, along with robo calls have just gotten damned creepy and overwhelming. So, I decided to install pi-hole. Very impressed. Nearly 30% of all requests, and a high margin of traffic is just our devices tracking our kids and us. It's been very interested to watch. We can see the data flow when we turn on devices, turn them off pick them up, tap, turn, set down, lights on, lights off, walk out of range, walk in range, stand up, sit down, login, logout. It's been fun just testing things and seeing how insanely tracked we are. Anyhow to point. iPads with Amazon Prime Video immediately started discharging, and I could see in the pi-hole query logs the culprit. device-metrics-us.amazon.com requests every few seconds.
So, here's what I did.
Setup a certificate authority. I'm a developer so I already had this.
Setup RESTful service to handle requests to POST /metricsBatch
Study the posts. (You'll need a root trusted cert and a proxy for you devices setup) There is a lot of data being sent each time you interact with Amazon Prime Video. Including, your top level LAN info (eg. 192.0.0.1), device model, customer id, ram available, disk available, app version, device id, wifi identifier of some sort, region, platform, etc.
Study the response. It's empty. Just a status 200.
Revise /etc/hosts on your pi-hole machine to point to your secure RESTful service that eats and logs all the requests, respond with status 200
Whitelist device-metrics-us.amazon.com, and observe that your service is intercepting responses. The requests should not be happening every few seconds now. Instead, they happen each time you interact with prime, and approximately 1 time per minute.
Delete Amazon Video from your device and cancel Amazon. Observe that battery life is better than before and bank account has more money each month.
I'm honestly surprised that with all media that Apple is putting out about protecting users' privacy, that they are permitting apps to send so much with absolutely no controls for the user to stop it or even be aware. If anything, pi-hole has made it very clear, which services and devices I want to use. I'm in the process of identifying invasive apps and services now. What I can't control directly or via pi-hole and similar technology, I'm just purging.