This is the part that tends to have the most mistakes, if used. It's generally better to provide minimal info manually if the CD wasn't identified by its ID.

I can't recall when something like that was enforced. Artistic intent is definitely something that editors and guidelines intend to preserve. Though in some cases it might be hard to determine if something is a mistake or intentional - there are incredibly weird releases.

It's used as the basis in a _lot_ of places. So fixing errors fixes them in a lot of other websites (and infoboxes).

Faster if someone votes on the edit, which you can request on their IRC/Discord/Discourse if there's a need (like larger or dependant edits).

It's even better that quite a few of those connections are unencrypted (and are actively used by some vendors to profile devices).

From my understanding this isnt correct. While a DNS resolution may or may not be encrypted, which is highly dependent on the local client's environment. Data being sent to apple is not being sent via DNS, as these DNS connections are only the beginning of negotiating a conneciton to Apple's servers. The connections themselves where data is transfered, are negotiated using TLS and thus encrypted.

The only point where this is not the case would be system probes, such as captive-portal check, OCSP, or NTP, but none of these would be capable of portraying anything more than simple metadata, like your ip address.

> Data being sent to apple is not being sent via DNS

Obviously I'm talking about what follows the name resolution.

> The connections themselves where data is transfered, are negotiated using TLS and thus encrypted.

They're not, as I said there are quite a few unencrypted ones. Last time I couldn't even set up a HomePod without allowing insecure connections.

> but none of these would be capable of portraying anything more than simple metadata, like your ip address.

Just the captive portal check alone contains things like the User-Agent, which has plenty more than just your IP.

> I suspect the reason why there are not more new devices for the budget pricepoint is that the market is saturated. Unlike phones, there isn't really a compelling reason to upgrade regularly. My mother has used her kindle for years at this point, and probably will use it for years to come.

I think e-ink patents are holding the ecosystem back in terms of possible designs (and trade-offs). I'm sure we'd see more and cheaper e-readers if the tech was freer.

The software still seems like the biggest let-down in terms of progress though. I've used like five different readers over the past decade, all from different manufacturers and they all have something that really annoys me. Things like one missing notch on the brightness slider, no custom software option or just poor UI button placement.

> the main goal as it seems to me is to ensure an OEM won't be successful marketing a phone that funnels less money to Google.

In general such an attested environment provides guarantees a lot of software makers want. Starting from just anti-malware and anti-cheat ending with just DRM.

Some app developers might want attestation for those reasons, but Android is big enough that almost none of them would leave if it was unavailable.

I can't wait for an usable open-source e-reader software for this reason amongst many others. I had to jailbreak my Kindle just to run Syncthing on it. Now I finally have an always up-to-date library. Why is it this annoying I don't get.

The cards might be cheap but they tend to be very hot and wasteful in terms of power. Only the newer more expensive modules finally support PCIe ASPM properly. Lack of it might actually also increase overall system power consumption due to certain sleep states becoming inaccessible.

> It's that more complex stuff is inherently more prone to security vulnerabilities

That's overly simplifying it and ignores the part where the simple stuff is not secure to begin with.

In the current context you could take a HTTP client with a formally verified TLS stack, would you really say it's inherently more vulnerable than a barebones HTTP client talking to a server over an unencrypted connection? I'd say there's a lot more exposed in that barebones client.

The alternative of the article was ACME vs other ways of getting TLS certificates, not https vs http.

Of course plain http would be, generally, much more dangerous than a however complex encrypted connection

Why the heck was this downvoted