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://letsencrypt.org/. 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.
Liquids aren't hard to defend against, all it has are two wires with +5 volts and ground and a resistor across another two lines to tell the device its a dumb charging terminal (that doesn't need to be asked to draw more power). Some simple epoxy around the wires and a current limiter (common in just about every usb setup anyway) will take care of conductive liquids (by preventing them from doing damage to the electronics with the limit until the liquid drains out of the port).
Chewing gum stuffed into the USB port is likely the most common and hardest to solve problem there. I presume they would have designed the contacts to be resistant to chemicals that dissolve gum to allow cleaning, but still not going to be pretty.
Other then that, its a big metal box, assuming the solar panel is covered in suitably tough plexiglass I don't see too much in the way of likely damage (but I'm not a vandal, who likely have more experience in how to cause problems that aren't easy to fix).
It looks suspiciously like the smaller armrests placed in the middle of benches in order to prevent the homeless from being able to sleep on the benches, rather then just a poor design decision; but I don't really know what the thought process behind the decision was. I agree with you, a poor design that is also ugly.
They are talking about the GPS ground stations that monitors the GPS signals (and is programed with its exact position and altitude) and determine what corrections, if any, need to be made to the GPS signals (so that what it knows to be its correct position is the same as what its GPS receiver is telling it)
Russia wants similar ground stations set up in the US for their GLONASS system, which I think is fair (and good for users of navigation systems, if not for the US military which would like to be able to turn off Russia's navigation systems).
Where there is an IT team to provide support using SSL client certificates will prevent (and detect via server SSL logs and client errors) fake certificates.
When enabled the client will sign (using their client cert, generally with a site-specific internally managed CA) all the communications after the key negotiation finishes, so if there is a middle-man that modified the certificate/keys the server will see the clients signature of the communications as incorrect (as the client and server wouldn't agree on what the communications were) even if the user overrides the SSL certificate warning or an attacker (or employer, or user, or vender) adds a fake/compromised CA to the trust store.
Doesn't work for sites without a support team to work with users and investigate failures or in cases where the internal CA is compromised, but for the highest of security needs its more effective then using Flash.
Reading the wiki on both desalinization via boiling and reverse osmosis indicates the vast majority of the energy in both methods (ether boiling the water under a vacuum or pumping at a high pressure) seem to be independent of how much salt it has to remove; so reducing the salt content by a few percent won't reduce the energy consumption (but will flood most existing plants and require more energy to have them rebuilt).
For my Prius there is a metal ring around the start button (and a mechanical key built into the key fob to open the doors) and if I press the fob on the ring even without a battery in the key the car can power it enough to authenticate the key and will then allow me to start the car.
The price of the keys, however, is indeed unacceptable.
My (limited) understanding of how drugs like the ones talked about here work is that they increase the number of "ticks" that the brain records so it thinks more time has passed, rather then actually speeding the brain up.
So, if the intent of work is to torture people with work then it might be effective, though afaik said people wouldn't likely get any more accomplished per earth-year then anyone else. Perhaps they would waste less time thinking that more wasted time has passed being wasted or something of that nature depending on what it covers.
I don't work from home all that productively, and do much better from a workplace that is split from my living space (and don't want to pay for the space to have an office in my apartment).
So for my uses it would take more innovation then virtual conferencing tools.
Currently they just don't fix problems in cars software unless there is a recall.
There haven't been any patches for the security holes associated with the electrical impulses causing doors to unlock (a patch requiring the door controller to get a cryptographic hello should do the trick), nor the issue allowing one remotely take control of a car, never mind the assorted annoyances that a software patch could fix.
If they were actually able to remotely patch a car there would be more questions about why they aren't making the patches, and they would rather not the focus be on them being cheap.
One problem with ICANN now is that they hold the root DNSSEC keys, so anyone who controls the strings of ICANN can spoof otherwise secured DNS records (and the associated SSH/PGP/HTTPS key pinning done with said records). The NSA, for example, I'm sure would be interested in the ability to man in the middle domains that are seen as important (ones that someone bothered to sign with DNSSEC).
I'm also sure that the GCHQ is equally interested in getting their hands on said keys.
I agree, however the current uses of flash are:
1) Videos
2) Copying text to the clipboard
3) Cow-clicking Games
The first could be moved to HTML5 but DRM (or in YouTube's case advertisement functionality) are slowing that down. DRM by definition can't be open source, so we ether have Flash or HTML5 DRM extensions (that are likely to be almost as bad, in addition to not being maintained and having security researchers yelled at as pirates instead of fixing the vulnerabilities).
In the second case some browser extension could be developed to allow copying only on button click like the popular flash applet does for that, better then having a full programing language for it.
The third case could make use of a foss solution, but with the first two having better options and devs already set in the ways of Flash its unlikely that there would be enough of a market for that to become substantial.
Slashdot Mirror
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://letsencrypt.org/. 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.
Liquids aren't hard to defend against, all it has are two wires with +5 volts and ground and a resistor across another two lines to tell the device its a dumb charging terminal (that doesn't need to be asked to draw more power). Some simple epoxy around the wires and a current limiter (common in just about every usb setup anyway) will take care of conductive liquids (by preventing them from doing damage to the electronics with the limit until the liquid drains out of the port).
Chewing gum stuffed into the USB port is likely the most common and hardest to solve problem there. I presume they would have designed the contacts to be resistant to chemicals that dissolve gum to allow cleaning, but still not going to be pretty.
Other then that, its a big metal box, assuming the solar panel is covered in suitably tough plexiglass I don't see too much in the way of likely damage (but I'm not a vandal, who likely have more experience in how to cause problems that aren't easy to fix).
It looks suspiciously like the smaller armrests placed in the middle of benches in order to prevent the homeless from being able to sleep on the benches, rather then just a poor design decision; but I don't really know what the thought process behind the decision was. I agree with you, a poor design that is also ugly.
They are talking about the GPS ground stations that monitors the GPS signals (and is programed with its exact position and altitude) and determine what corrections, if any, need to be made to the GPS signals (so that what it knows to be its correct position is the same as what its GPS receiver is telling it)
Russia wants similar ground stations set up in the US for their GLONASS system, which I think is fair (and good for users of navigation systems, if not for the US military which would like to be able to turn off Russia's navigation systems).
Where there is an IT team to provide support using SSL client certificates will prevent (and detect via server SSL logs and client errors) fake certificates.
When enabled the client will sign (using their client cert, generally with a site-specific internally managed CA) all the communications after the key negotiation finishes, so if there is a middle-man that modified the certificate/keys the server will see the clients signature of the communications as incorrect (as the client and server wouldn't agree on what the communications were) even if the user overrides the SSL certificate warning or an attacker (or employer, or user, or vender) adds a fake/compromised CA to the trust store.
Doesn't work for sites without a support team to work with users and investigate failures or in cases where the internal CA is compromised, but for the highest of security needs its more effective then using Flash.
Reading the wiki on both desalinization via boiling and reverse osmosis indicates the vast majority of the energy in both methods (ether boiling the water under a vacuum or pumping at a high pressure) seem to be independent of how much salt it has to remove; so reducing the salt content by a few percent won't reduce the energy consumption (but will flood most existing plants and require more energy to have them rebuilt).
For my Prius there is a metal ring around the start button (and a mechanical key built into the key fob to open the doors) and if I press the fob on the ring even without a battery in the key the car can power it enough to authenticate the key and will then allow me to start the car.
The price of the keys, however, is indeed unacceptable.
My (limited) understanding of how drugs like the ones talked about here work is that they increase the number of "ticks" that the brain records so it thinks more time has passed, rather then actually speeding the brain up.
So, if the intent of work is to torture people with work then it might be effective, though afaik said people wouldn't likely get any more accomplished per earth-year then anyone else. Perhaps they would waste less time thinking that more wasted time has passed being wasted or something of that nature depending on what it covers.
I don't work from home all that productively, and do much better from a workplace that is split from my living space (and don't want to pay for the space to have an office in my apartment).
So for my uses it would take more innovation then virtual conferencing tools.
Currently they just don't fix problems in cars software unless there is a recall.
There haven't been any patches for the security holes associated with the electrical impulses causing doors to unlock (a patch requiring the door controller to get a cryptographic hello should do the trick), nor the issue allowing one remotely take control of a car, never mind the assorted annoyances that a software patch could fix.
If they were actually able to remotely patch a car there would be more questions about why they aren't making the patches, and they would rather not the focus be on them being cheap.
One problem with ICANN now is that they hold the root DNSSEC keys, so anyone who controls the strings of ICANN can spoof otherwise secured DNS records (and the associated SSH/PGP/HTTPS key pinning done with said records). The NSA, for example, I'm sure would be interested in the ability to man in the middle domains that are seen as important (ones that someone bothered to sign with DNSSEC).
I'm also sure that the GCHQ is equally interested in getting their hands on said keys.
I agree, however the current uses of flash are:
1) Videos
2) Copying text to the clipboard
3) Cow-clicking Games
The first could be moved to HTML5 but DRM (or in YouTube's case advertisement functionality) are slowing that down. DRM by definition can't be open source, so we ether have Flash or HTML5 DRM extensions (that are likely to be almost as bad, in addition to not being maintained and having security researchers yelled at as pirates instead of fixing the vulnerabilities).
In the second case some browser extension could be developed to allow copying only on button click like the popular flash applet does for that, better then having a full programing language for it.
The third case could make use of a foss solution, but with the first two having better options and devs already set in the ways of Flash its unlikely that there would be enough of a market for that to become substantial.