Live data from Hacker News

Kindle collects a surprisingly large amount of data

nullsweep.com

321–330 of 393 posts

Re: Kindle collects a surprisingly large amount of data

#321

Earlier quoted context omitted.

>One can remove DRM for amazon's ebook format (.azw3 ?) via some python scripts. You didn't hear it from me though. Not for the new KFX format. Only way to get around that is to use an older version of the kindle desktop app that downloads the azw format. Workaround won't last long though. And won't work on newer macs because the old version is a 32bit app .

Apparently you can do the conversion with Calibre.[1] 1: https://epubor.com/how-to-convert-kindle-kfx-to-epubpdfmobi-...

Last I checked (a year ago?) KFX wasn't a great input format, as it's optimized for the Kindle readers and not for conversion/interoperability. That is, KFX is to AZW3 as PDF is to HTML.

Re: Kindle collects a surprisingly large amount of data

#322

Earlier quoted context omitted.

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

The text in question: > Highlighting or tapping any word will send the requests with the text to Bing Translate and Wikipedia, as well as back to Amazon. Is there a reason why that text needs to be sent before the user clicks the "translate" button? Is there a reason why it needs to be sent to Amazon?

This is literally my #1 used feature of my Kindle. I read texts in different languages to have a quick access to single-tap translations.

If it took 2 taps, I would switch platforms.

Re: Kindle collects a surprisingly large amount of data

#323
post #235

Earlier quoted context omitted.

> 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…

The screen refresh rate on these devices is measured in seconds , so a few hundred millis of network latency is impossible to display.

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.

[1] https://danluu.com/input-lag/

Re: Kindle collects a surprisingly large amount of data

#324
post #235

Earlier quoted context omitted.

> 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…

The screen refresh rate on these devices is measured in seconds , so a few hundred millis of network latency is impossible to display.

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.

Re: Kindle collects a surprisingly large amount of data

#325

Earlier quoted context omitted.

Any cheap budget table isn't e-ink, which matters for battery life and, at least for some people, reading pleasure. Also, I mainly use my Kindle for reading research papers in academia, into the hundreds of publications each year. So, after years of using these devices its UI (which I find admirably simple and straightforward) is burned into my muscle memory. So, switching to another series of devices would mean havi…

There are many cheap e-ink readers on the market these days, though.

I've never seen one that has the bang for the buck of a basic paperwhite. I got my last one for under $100 and I never use the amazon nonsense. I just keep it in airplane mode and load my own books.

Re: Kindle collects a surprisingly large amount of data

#326
post #323

Earlier quoted context omitted.

The screen refresh rate on these devices is measured in seconds , so a few hundred millis of network latency is impossible to display.

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. [1] https://danluu.com/input-lag/

[deleted]

Re: Kindle collects a surprisingly large amount of data

#327
post #306

Earlier quoted context omitted.

> If so, why don't they loudly advertise the data collection and do it only with opt-in? But they do. https://m.youtube.com/watch?v=yg70ojfWXnk

The video is about synch, while the conversation is about "collection does lead to better products" -> i.e, analytics.

What do you believe syncing means? This discussion talks about whispersync reporting last page read and most recent page read events. What do you think that's supposed to do?

Re: Kindle collects a surprisingly large amount of data

#328

Earlier quoted context omitted.

The screen refresh rate on these devices is measured in seconds , so a few hundred millis of network latency is impossible to display.

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…

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").

Re: Kindle collects a surprisingly large amount of data

#329

Earlier quoted context omitted.

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…

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.

Re: Kindle collects a surprisingly large amount of data

#330
post #235

Earlier quoted context omitted.

> 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…

The screen refresh rate on these devices is measured in seconds , so a few hundred millis of network latency is impossible to display.

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.
Post reply on HN