I mention that the data that appears to be used for those purposes is sent again in a separate request to a separate end point, so we have two types of requests: last read location, and reading analytics. Sorry it wasn't clear, I'll try to improve the wording.
Will you also be updating and noting that the requests to Wikipedia and Bing are for explicit customer-benefiting features?
Might be worth noting that you can opt out of their data collection (on the e-reader, at a minimum) as well. Settings > Device Options > Advanced Options > Privacy or in the device management console in your account on amazon.com
> Is there a reason why that text needs to be sent before the user clicks the "translate" button?
Yes - UX latency. I would expect this kind of thing to take a few thousand milliseconds, and shaving off a few hundred milliseconds from between when the user highlights text and when they select "translate" is significant. The fact that this data is being sent to Wikipedia of all places further signals that the usage is likely to be innocuous.
Do I think that this is globally a good design decision? No, for both engineering and privacy reasons. There's definitely no good reason why it should be sent to Amazon at all.
> There's definitely no good reason why it should be sent to Amazon at all.
I was wracking my brain on this, and all I could come up with was "to independently verify the invoicing for Bing translations" and "how many times are people accessing the definition/translation and not highlighting". So, analytics, not something that explicitly benefits the user.
Can we stop pretending that analytics don't explicitly benefit the user? Product Engineering organizations rely on analytics to improve user experiences.
Analytics can be done less granularly and still benefit the user. Also, surely not every data point collected is used to benefit the user.
For example, Amazon doesn't need to know where I am when I request a definition or translation. If they're concerned about usage, they only need to know how many times I actually used one or both of those features per day, per week, or month. They don't need to know instantly every single time a word is highlighted.
> Analytics can be done less granularly and still benefit the user. Also, surely not every data point collected is used to benefit the user.
How? For all we know, it isn't granular - it might be aggregated at the server level to hide specific user's actions. But they'd still need to be sending in the data from the device to the server.
The device could keep a daily count of interesting actions, and sync that to analytics servers on a daily or weekly basis. That preserves 95% of legitimate use cases while leaking much less private data (like how my reading habits are distributed across the day)
I mean, you're still collecting most of the problematic data. And you might legitimately be interested in what you're leaving out - knowing time of day that people do things is actually important for plenty of use cases.
I'm surprised you'd say that. Out of interest, how does analytics help websites not use blathery, unhelpful text in overly-small fonts, done too-pale to make them unreadable. A lot of UI failings are of this most basic kind.
When you play an online slot game where you bet money that some numbers will appear on screen, and they use analytics to "improve user experience" (read: engagement, read: you losing more money), is that benefiting you or is it benefiting them?
Kindle devices have a dictionary on device. By looking into which words are most frequently defined, they can add these to the local dictionary to help improve the speed of the UI.
This isn't universally true - Dan Luu's computer latency page[1] lists three Kindles, all below 900 ms of latency. And, since some devices have latency as low as 570 ms, it makes sense that they would use this optimization.
have you actually used a kindle? it certainly doens't take seconds for the definitions to pop up. a full-page refresh might take a second, but most page turns or UI interactions are partial draws and are much faster.
I suspect that they were overstating a limitation of these devices rather than speaking from inexperience. While it has been years since I've used a Kindle, I do use Kobo devices and the delays are perceptible. While changing a page may be quite quick, user interface elements (such as a box containing a definition) seem to take longer. I suspect that they have to be more agressive when refreshing the screen before and after these user interface elements are displayed in order to make the ghosting less perceptible.
If you want to see what I mean by the ghosting of user interface elements being more perceptible, try using KOReader. The ghosting after using a menu can be quite noticable (at least on Kobo devices, which are based on the same technology).
And the fact that the screens are slow should be motivation to make the rest of the system as responsive as possible. A good software engineer will work around bottlenecks, not shrug their shoulders and introduce new ones.
Also remember that "Kindle" can refer to an app on your phone or desktop computer, all of which may share code related to highlighting and translating.
That doesn’t seem right. Let’s consider the screen refresh to be like a subway station, where the train shows up every few seconds. We need the text we want to show to the user to be at the stop waiting when the train arrives. If we miss the train, we need to wait for the next train to get our text on the screen. The network latency delays when we show up to wait at the station.
If the refresh rate is 5 seconds, and the network response time is 500ms, than eliminating the 500ms response time means we are 10% less likely to miss the train. On average, the time for the text to appear on the screen decreases by 500ms.
All this assumes the refreshes happening on a static schedule. If the software can trigger the refresh, then it’s a lot simpler. The 500ms improvement in latency would apply equally to every engagement with the translate feature.
There's no static schedule. It's an e-ink display. Refreshes happen when software tells it to display something new and take several hundred millis per blank - and a screen can be up to three blanks (because if it doesn't go white-black-display, then some pixels get stuck "on" or "off" or "halfway").
In that case, it’s clear that eliminating the network request before triggering the refresh directly reduces the amount of time the user has to wait to see the result.
There isn't a "translate button" - the selection of the word i the button for define/translate/wiki. You swipe between the three cards.
I like this, as a user. I don't want MORE buttons to tap through when I'm trying to define or translate a word. Especially since the Kindle eink screen and UI is not the most responsive.
> Might be worth noting that you can opt out of their data collection (on the e-reader, at a minimum) as well. Settings > Device Options > Advanced Options > Privacy or in the device management console in your account on amazon.com
Good tip, I'm going to give this a whirl. Unfortunately, all the network calls add a significant amount of latency even if one didn't care about privacy.
>(off-topic) What’re the advantages of pihole over /etc/hosts?
It's good for cases exactly like this - devices where you don't have control over /etc/hosts (or where you have lots of them and don't want to keep the hosts files in sync). I use it for my Samsung TV to keep them from phoning home (but still letting me use apps)
Edit: you can also set up a DoH endpoint and filter traffic while also allowing Encrypted SNI to work
> It's good for cases exactly like this - devices where you don't have control over /etc/hosts
Is the pihole a DNS server or a firewall? Sibling comments suggest it's a DNS server, but that doesn't answer this need at all -- if you don't control /etc/hosts, you don't control the device. It can do its resolution however it wants. Most obviously, it can include the domain names you don't want it to reach in its own /etc/hosts file, which you just said you didn't control.
In addition to sibling replies which point out network-wide usefulness... pihole (or any dns server) can/will return NXDOMAIN instead /etc/hosts which will only return an ip. A dns server can also be configured to match a domain and any subdomain (wildcard match) without having to specify each entry individually.
They both work similarly if you're using them to block outbound requests, but a Pi-Hole would intercept and block outbound requests for every device on the network where it's installed, whereas editing /etc/hosts would only block requests on a single device (unless that device is your router, I guess?)
I liked the article. If you are gonna update it, please consider also mentioning technical aspect. Frankly, Amazon snooping on users is to be expected, but short mention of app for which platform have you analysed using which tools would be welcome addition.
> Frankly, Amazon snooping on users is to be expected
Snooping on users during e-commerce transactions, sure.
But recording user's detailed interactions with every ebook? I hope that's a big surprise to your average Kindle user.
It would be great to see a data request response and how much of this data is retained and for how long. It's clearly not anonymized at the request level.
Very easy to see a future where just reading certain books or reading certain books too many times could flag you as dangerous or be used to support a mental incompetence hearing resulting in loss of rights.
