China seems to be well ahead of the US on the regulating encryption front, so I don't think that China will be ahead in terms of the general populous using encryption that can't be broken (excluding governments, of course). This article indicates that a lot of Chinese firms don't use encryption in China at all to avoid having to deal with giving the government keys. They also mandate usual encryption algorithms (SMS4 comes to mind) which are presumably selected because they can be broken.

Which is why domains all include www.example.com/web_beacon.png at the bottom; then they contract with example.com to get a list of what other domains you have visited.
Because this feature seperates them the work example.com cookie won't be shared with the Slashdot example.com cookie.
Some browsers allow disabling 3rd party cookies, but that tends to cause issues with SSO and isn't the general default. I currently use self-destructing cookies which causes cookies out-of-scope to vanish, which also solves this issue.

As this is talking about SMS messages we are mostly just looking at cell phones here. More often than not when I get someones cell number its from their home-town where they got their first cell phone 10 years ago... and no longer has any relation to where they are living presently.
As such, of all the evil they can do with that information (cross-account linking, marketing) there are better ways for them to get location data (namely marketing an app using the collected phone numbers which uses GPS to 'find the store nearest you').

It appears at least a few people have had luck with using it on Windows here, but the results certainly appear mixed and no official clients are offered.
I've not touched a Windows server since the days of 2k (and never ran SSL on it), so... I can't really provide much useful assistance I'm afraid.

Free certificates can now be gotten via https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fletsencrypt.org%2F. Its still in public beta, but functional. For help on the how to set up encryption, LetsEncrypt's client can take care of few web servers, but for more specific instructions you would need to disclose what web server software your using.

The criteria are all about what the ad looks like... I care more about if its attempting to get around cookie destruction, doing browser history digging, accepting obfuscated JS from malvertisers, etc. It does say it doesn't allow Flash/Shockwave/etc, which is better then nothing, but not really good enough... I'm going to stick with NoScript (and not running adblock).

If a site sends a strict transport security header (e.g. "Strict-Transport-Security: max-age=31536000; includeSubDomains"), it will cause a browser to store that and refuse to allow an override if the certificate verification fails (and also changes plain http attempts to https). So for sites that do have certificates and wish to have enforcement of that there is a good option for that (though doesn't help for the first request, that is unlikely to have anything interesting in it).

They don't need to take an oath given what I read from the document. It doesn't really say anything, uses lots of weasel words such as "legitimate business purposes". Additionally they allow sharing of covered information to protect the "safety, property, and rights" of Participating Members (themselves), which I see as allowing them to come up with some reason to share whatever they want.

I have a Yubikey that I use for encrypting my password stores (using the private id as one of several components passed to a pbkdf). It detects replays by verifying that every token has a larger counter then all prior used tokens (and the timer depending on the application).
A Yubikey token looks like 'ficrtvulktgnerhddigbhcudufurijghfcckvchhjfli' and is a modhex (16 chars picked for being the same across charsets) and contains the following:
1) A public ID to identify the key
2) AES128 encrypted 128 bits containing the following:
a. Secret ID
b. Insertion counter (how many times its been plugged into a computer)
c. Token counter (within one insertion)
d. Timestamp (A counter counting the time since the token was inserted into the computer)
e. Random number
f. Checksum of the above
Their website has full specifications and documentation.

That depends on the use case. Take for example a printer which is using TLS to encrypt documents sent to it and scans from it to the computer. In the case of a single self-signed CA its just snake oil as far as security as anyone could take the self-signed certificate from the FW image and MiTM the connection.
If, instead, the printer created a random self-signed certificate on first boot and the printer driver asks the user on a certificate change 'printer xyz appears to have changed its fingerprint, did you perform a factory reset?' (and on new printer add just save the certificate from the new printer on first use).
The above change would change the snake oil to some meaningful level of security (not 100%, but most likely the first setup isn't going to be MiTM'ed). Additionally if TLS isn't using forward-secrecy then a certificate shared across all devices allows anyone to decrypt logged traffic to/from any of these devices by extracting the key from the manufacturer provided fw image rather then having to hack it out of the physical device itself.

The digital versions of textbooks that I've thus far seen are anything but free, unless the district got a special deal on the digital text book versions for the iPad's that make them less expensive. Without having said numbers (that I'm sure are under multiple NDA's) speculation on the overall price is difficult.
Looking at the Google Play textbook store (because its easy to look at and ebook prices seem the same across sources in my experience) they are between $40-$50 each, and then couldn't be transferred between devices (e.g. students) if they are given rather then loaned the iPad (article uses the term 'given'); again could be changed with a special contract.

Not the OP, but I'd like to see passwords replaced with SSL client certificates. The GUI for them in most modern browsers is horrific and the error messages shown when something goes wrong even worse; but both issues could be fixed.
If additional verification of identity is required then a password would be much safer behind a certificate (as an attacker trying passwords would need the users certificate and could easily be rate limited by account).

These are embedded devices so they would need to be on a firewalled off network (presumably allowing access from the byod wifi to allow control from selected smartphones) anyway to keep them from being internet-hackable, as they aren't likely going to get patches for security and protection from disgruntled employees who have the lights ips/keys already.
That being the case, there is little reason to use public IP's for them at all (since the entire range would have to be completely firewalled off, so using fe* or 10.* IP's doesn't really matter all that much and allows for somewhat easier auditing of the security situation.

The use I can think of is the ability of office workers to change the color (presuming these are similar to their Hue bulbs) and brightness of the lights over their cubes (as they could use their smartphones to identify said lights and connect to them without going through some central system) or in their offices rather then being stuck under florescent lights or with the same color/brightness for everyone that the office management decided on using.
Not a really great use, but its better then no use. I'd expect most offices would nix the idea of having assorted light colors throughout the cube farm as being unclean and disable the feature, leaving no use for all but some of the offices.