High Fructose corn syrup is called HIGH fructose because it contains a higher concentration of fructose
Higher than what?
I'll answer that for you. It's called high-fructose corn syrup because it has more fructose than the preexisting product "corn syrup" (from which it is made). Corn syrup is all glucose (and water), made by hydrolyzing corn starch. High-fructose corn syrup is made by using an isomerase enzyme to convert glucose to fructose.
Meanwhile, fructose in sucrose is bound to glucose at 50 to 50 mix which must be broken in the body through the use of a(n) enzyme(s).
This is true, and there are probably subtle metabolic effects between sucrose and a mixture of glucose and fructose. However, sucrose is not "sugar later". While it needs to be hydrolyzed into monosaccharides, that's a fast process. "Sugar later" is more like starch, which is a glucose chain that actually takes some time to digest.
On top of that, fructose which occurs naturally tends to be bound to fiber, i.e. indigestible cellulose.
Bound to? Not necessarily. "In the presence of?" Sure, often, but that's the difference between natural foods and processed foods. Soda is flavored sugar water without any of the other products that normally come along with sugar -- regardless of whether you make it with beet sugar, cane sugar, high-fructose corn syrup, or honey.
That's like saying salted almonds occur naturally.
High-fructose corn syrup is a 1:1 solution of glucose and fructose (except for the 80-20 kind). You'll find 1:1 solutions of glucose and fructose in honey, figs, and grapes (yes, along with a bevy of non-sugar chemicals). It's corn starch that's processed by enzymes into sugars that you find everywhere in the natural world. Chemically speaking, there's nothing strange, sinister, or synthetic about it.
It's real sugar. Here, they're making the distinction between "natural sugars" -- substances that are chemically sugars -- and "artificial sweeteners" -- sweet substances that contain no sugar compounds. (Artificial sweeteners might include some sugars, if they're indigestable. All of them have some feature that make them zero or low calorie -- like being extremely sweet per weight.)
HFCS is a ~50/50 mix of glucose and fructose. Both of those occur naturally. HFCS can be produced by natural means, even: corn starch plus the right enzymes. It's very close to the sugar composition of honey (minus the maltose) and is the same as invert sugar (hydrolyzed sucrose).
It's bad to eat a lot of it, but there's absolutely nothing interesting chemically about HFCS.
Inbound with Tor is not so bad, but it requires a two-machine setup that's nontrivial for a non-sysadmin to do correctly. Getting the server's outbound (new connections, not return traffic) to transit over Tor exclusively is less easy. Ideally, you don't make outbound connections from your server.
That's a coy way of saying they were trying to do SQL injection and it didn't work.
and it spits out the IP address for no reason.
In the course of trying to do SQLi, they generated a ton of different error message. The HTML source of one of the error message contained the server's real IP address. Pretty easy mistake to make if you unwisely put your hidden-service Web server and your Tor proxy on the same physical machine (thereby running your Web server on a device that has a public IP address).
Such a configuration might be necessary if, for example, your website integrates a third-party system (like a captcha) and that third party happens to block Tor traffic.
They're saying the server leaked its own IP address. Unless you've set up your system so that your Tor hidden server is on a computer not connected directly to the Internet and it connects to a physically-separate Tor node that blocks any network flows other than ones going over the Tor proxy, then any Tor hidden server also has a leakable IP address. A Web server error message (or embedded error message from a third-party service, for example), header, or other piece of data might then contain the server's IP address.
That's pretty thin information by itself. But if any part of your server is configured to listen on all network interfaces (instead of, say, localhost), then someone making an HTTP request to that IP address gets a page from your server. That's fairly damning evidence.
Yes, wireless network security, network service security, and wireless data coverage are all solid enough that this is a great idea and definitely could not be easily hacked.
Hardcoded credentials aren't necessary. What they *mean* is that the *reason* for hardcoded credentials is "support". "Necessary" here doesn't actually mean "necessary", but rather, "deemed to be the best choice". Of course, it might really be the best choice. There's certainly a cost associated with making the support more complicated. You have to weigh that against the difficulty of using the hardcoded credentials and what you can do with them. There are lots of potential tradeoff points, from "using hardcoded credentials was the stupidest choice you've ever made" to "it's technically offensive, but also the best option".
Doesn't require physical access. Firmware reprogramming is easily over-the-wire with many USB devices. It just requires logical access to the device. A computer running malware is a malicious third party with logical access to the USB device.
Yes, devices have updateable firmware. How is this a "sneakernet issue"? The firmware update does not cause Windows to install anything. Those are orthogonal features.
Sure. Depending on your device (iPhone works differently from the standard USB fast-charging spec), you should be able to easily look up what resistors need to go where. (As mentioned, non-iPhone devices use an informal standardized spec. A circuit diagram of something like a Samsung charger should show you.)
What sneakernet issue? Be more clear. USB devices do not contain installable software, except for the obvious and well-known case of a mass-storage device happening to contain files that can be intentionally or inadvertently executed by the end user after the MSD is connected.
You just need a resistor or two. Almost any USB-charged device will charge at 500 mA if it is connected to a dumb charger (no data lines), but in order to charge at a higher current (as many devices do), it needs to sense that it's connected to a charger that supports the higher current draw. So that it can be implemented without real USB-supporting electronics, that's just done with some simple electrical components. So you can make a charger that blocks the data lines but permits full-speed charging.
If you're okay with the slow version, just go out and buy a "power only" USB cable. They already exist. Alternately, this.
It'd probably be easier to implement a little hardware device that places restrictions on device classes that can connect through it and limits hybrid devices (e.g., keyboard+mouse = ok, keyboard+webcam = reject).
1. A ton of USB devices are actually implemented as general-purpose components with programmable firmware (attached to whatever support hardware, like a network card or a webcam, is necessary). So they're more common than you think.
2. Smartphones are an excellent reprogrammable USB device that lots of individuals have.
3. This is difficult enough to really engineer well that it is probably a bigger threat as a targeted attack against a big organization for now. Until someone does the engineering to make it easy to deploy widely. Then, it'll be a threat for everyone. Kind of like automated hacking of consumer-grade routers to modify the firmware to participate in an Internet-wide portscan. It's the Metasploit effect: it's not a big problem until someone makes it automated, then it is.
They are bugged only once, and then they accept the cert locally.
Not necessarily. On Chrome, for example, accepting a self-signed cert long-term isn't the default behavior. Even that isn't a great idea: you have no knowledge of whether the self-signed cert is legitimate or not without a substantial out-of-band communication of technical information to nontechnical people, which isn't cheap. A college network is a good example: it should be treated as a hostile network, so MitM against a self-signed cert within your private network is very much a reality.
Or the college provides an easy way for the BYOD people to acquire the college's cert.
Doing that at a large scale for technically-inclined people costs more than a public CA cert. Once you have to support regular users, it's way more expensive.
There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2
Certs don't include IP address. When you get a cert for server1.internal.unm.edu, they don't know what IP address(es) it will be bound to, and they don't and shouldn't care.
No need whatsoever.
There certainly is a need. It's to enable devices that want SSL but aren't configured to trust your internal CA to securely identify your server. There are lots of reasons for "aren't configured to trust your internal CA" to happen.
And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
They're going to require that certs they issue are for domains that are tied to an external domain. For example, mail.internal.unm,edu. This doesn't negatively impact people's ability to have public CA certs for internal resources. Nor should it.
Judging by how the police actually operate, a hard drive with that data will be put in a box and put into storage with a large collection of other such boxes, probably never to be seen again.
Oddly, it's not. That's where OP is coming from. "Treasure trove" comes ultimately from Latin via French (or at least, some language fragments the Normans brought over). The "trove" means "found", so it's "found treasure". That's why in the original (pre-English) phrase, the word order is backwards: "trove" is the adjective, "treasure" is the noun, and it follows the appropriate French/Latin word order. It was pulled directly into English without reordering (common for borrowed phrases). Eventually, "trove" (which had no English meaning at all) became a synonym (a shortening) for "treasure trove".
So by etymology, "trove" was originally an adjective. However, it means nothing in English. The phrase "treasure trove" is a noun phrase all by itself that can't really be broken into parts.
Slashdot Mirror
Are you implying that the rest of the world, except for the US, is on board with current climate-change science? Because that's certainly not true.
Do you mean things like: potassium, sodium, magnesium, calcium, and strontium?
No, things like molybdenum, tantalum, lanthanum, and platinum.
Also hydrogen, boron, carbon, nitrogen, oxygen, fluorine, neon, silicon, phosphorous, sulfur, chlorine, argon, manganese, iron, cobalt, nickel, copper, zinc, arsenic, bromine, krypton, silver, tin, iodine, xenon, gold, mercury, lead, bismuth, astatine, radon.
In current usage and also in the Latin names for the elements, both -ium and -um are used frequently as endings for metallic elements.
does not have return receipt functionality
No, just subpoena-able usage logs.
High Fructose corn syrup is called HIGH fructose because it contains a higher concentration of fructose
Higher than what?
I'll answer that for you. It's called high-fructose corn syrup because it has more fructose than the preexisting product "corn syrup" (from which it is made). Corn syrup is all glucose (and water), made by hydrolyzing corn starch. High-fructose corn syrup is made by using an isomerase enzyme to convert glucose to fructose.
Meanwhile, fructose in sucrose is bound to glucose at 50 to 50 mix which must be broken in the body through the use of a(n) enzyme(s).
This is true, and there are probably subtle metabolic effects between sucrose and a mixture of glucose and fructose. However, sucrose is not "sugar later". While it needs to be hydrolyzed into monosaccharides, that's a fast process. "Sugar later" is more like starch, which is a glucose chain that actually takes some time to digest.
On top of that, fructose which occurs naturally tends to be bound to fiber, i.e. indigestible cellulose.
Bound to? Not necessarily. "In the presence of?" Sure, often, but that's the difference between natural foods and processed foods. Soda is flavored sugar water without any of the other products that normally come along with sugar -- regardless of whether you make it with beet sugar, cane sugar, high-fructose corn syrup, or honey.
That's like saying salted almonds occur naturally.
High-fructose corn syrup is a 1:1 solution of glucose and fructose (except for the 80-20 kind). You'll find 1:1 solutions of glucose and fructose in honey, figs, and grapes (yes, along with a bevy of non-sugar chemicals). It's corn starch that's processed by enzymes into sugars that you find everywhere in the natural world. Chemically speaking, there's nothing strange, sinister, or synthetic about it.
It is a natural sugar, but is ~300 times sweetener than sucrose.
It's not a sugar, it's a non-sugar sweetener. Chemically, it's a glycoside, rather than a sugar.
It's real sugar. Here, they're making the distinction between "natural sugars" -- substances that are chemically sugars -- and "artificial sweeteners" -- sweet substances that contain no sugar compounds. (Artificial sweeteners might include some sugars, if they're indigestable. All of them have some feature that make them zero or low calorie -- like being extremely sweet per weight.)
HFCS is a ~50/50 mix of glucose and fructose. Both of those occur naturally. HFCS can be produced by natural means, even: corn starch plus the right enzymes. It's very close to the sugar composition of honey (minus the maltose) and is the same as invert sugar (hydrolyzed sucrose).
It's bad to eat a lot of it, but there's absolutely nothing interesting chemically about HFCS.
Inbound with Tor is not so bad, but it requires a two-machine setup that's nontrivial for a non-sysadmin to do correctly. Getting the server's outbound (new connections, not return traffic) to transit over Tor exclusively is less easy. Ideally, you don't make outbound connections from your server.
You know Silk Road actually used reCAPTCHA, yes?
You hit login 100 times
That's a coy way of saying they were trying to do SQL injection and it didn't work.
and it spits out the IP address for no reason.
In the course of trying to do SQLi, they generated a ton of different error message. The HTML source of one of the error message contained the server's real IP address. Pretty easy mistake to make if you unwisely put your hidden-service Web server and your Tor proxy on the same physical machine (thereby running your Web server on a device that has a public IP address).
Such a configuration might be necessary if, for example, your website integrates a third-party system (like a captcha) and that third party happens to block Tor traffic.
They're saying the server leaked its own IP address. Unless you've set up your system so that your Tor hidden server is on a computer not connected directly to the Internet and it connects to a physically-separate Tor node that blocks any network flows other than ones going over the Tor proxy, then any Tor hidden server also has a leakable IP address. A Web server error message (or embedded error message from a third-party service, for example), header, or other piece of data might then contain the server's IP address.
That's pretty thin information by itself. But if any part of your server is configured to listen on all network interfaces (instead of, say, localhost), then someone making an HTTP request to that IP address gets a page from your server. That's fairly damning evidence.
Yes, wireless network security, network service security, and wireless data coverage are all solid enough that this is a great idea and definitely could not be easily hacked.
Hardcoded credentials aren't necessary. What they *mean* is that the *reason* for hardcoded credentials is "support". "Necessary" here doesn't actually mean "necessary", but rather, "deemed to be the best choice". Of course, it might really be the best choice. There's certainly a cost associated with making the support more complicated. You have to weigh that against the difficulty of using the hardcoded credentials and what you can do with them. There are lots of potential tradeoff points, from "using hardcoded credentials was the stupidest choice you've ever made" to "it's technically offensive, but also the best option".
Doesn't require physical access. Firmware reprogramming is easily over-the-wire with many USB devices. It just requires logical access to the device. A computer running malware is a malicious third party with logical access to the USB device.
Yes, devices have updateable firmware. How is this a "sneakernet issue"? The firmware update does not cause Windows to install anything. Those are orthogonal features.
Sure. Depending on your device (iPhone works differently from the standard USB fast-charging spec), you should be able to easily look up what resistors need to go where. (As mentioned, non-iPhone devices use an informal standardized spec. A circuit diagram of something like a Samsung charger should show you.)
What sneakernet issue? Be more clear. USB devices do not contain installable software, except for the obvious and well-known case of a mass-storage device happening to contain files that can be intentionally or inadvertently executed by the end user after the MSD is connected.
You just need a resistor or two. Almost any USB-charged device will charge at 500 mA if it is connected to a dumb charger (no data lines), but in order to charge at a higher current (as many devices do), it needs to sense that it's connected to a charger that supports the higher current draw. So that it can be implemented without real USB-supporting electronics, that's just done with some simple electrical components. So you can make a charger that blocks the data lines but permits full-speed charging.
If you're okay with the slow version, just go out and buy a "power only" USB cable. They already exist. Alternately, this.
It'd probably be easier to implement a little hardware device that places restrictions on device classes that can connect through it and limits hybrid devices (e.g., keyboard+mouse = ok, keyboard+webcam = reject).
A couple NSA letters later and MS is now sending NSA payloads.
Because they couldn't already do this with network-distributed software updates?
1. A ton of USB devices are actually implemented as general-purpose components with programmable firmware (attached to whatever support hardware, like a network card or a webcam, is necessary). So they're more common than you think.
2. Smartphones are an excellent reprogrammable USB device that lots of individuals have.
3. This is difficult enough to really engineer well that it is probably a bigger threat as a targeted attack against a big organization for now. Until someone does the engineering to make it easy to deploy widely. Then, it'll be a threat for everyone. Kind of like automated hacking of consumer-grade routers to modify the firmware to participate in an Internet-wide portscan. It's the Metasploit effect: it's not a big problem until someone makes it automated, then it is.
The whole point of this is that the malware reprograms the firmware of existing, trusted devices to make them malicious.
None. Now you've identified and understand the problem.
They are bugged only once, and then they accept the cert locally.
Not necessarily. On Chrome, for example, accepting a self-signed cert long-term isn't the default behavior. Even that isn't a great idea: you have no knowledge of whether the self-signed cert is legitimate or not without a substantial out-of-band communication of technical information to nontechnical people, which isn't cheap. A college network is a good example: it should be treated as a hostile network, so MitM against a self-signed cert within your private network is very much a reality.
Or the college provides an easy way for the BYOD people to acquire the college's cert.
Doing that at a large scale for technically-inclined people costs more than a public CA cert. Once you have to support regular users, it's way more expensive.
There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2
Certs don't include IP address. When you get a cert for server1.internal.unm.edu, they don't know what IP address(es) it will be bound to, and they don't and shouldn't care.
No need whatsoever.
There certainly is a need. It's to enable devices that want SSL but aren't configured to trust your internal CA to securely identify your server. There are lots of reasons for "aren't configured to trust your internal CA" to happen.
And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
They're going to require that certs they issue are for domains that are tied to an external domain. For example, mail.internal.unm,edu. This doesn't negatively impact people's ability to have public CA certs for internal resources. Nor should it.
Judging by how the police actually operate, a hard drive with that data will be put in a box and put into storage with a large collection of other such boxes, probably never to be seen again.
Oddly, it's not. That's where OP is coming from. "Treasure trove" comes ultimately from Latin via French (or at least, some language fragments the Normans brought over). The "trove" means "found", so it's "found treasure". That's why in the original (pre-English) phrase, the word order is backwards: "trove" is the adjective, "treasure" is the noun, and it follows the appropriate French/Latin word order. It was pulled directly into English without reordering (common for borrowed phrases). Eventually, "trove" (which had no English meaning at all) became a synonym (a shortening) for "treasure trove".
So by etymology, "trove" was originally an adjective. However, it means nothing in English. The phrase "treasure trove" is a noun phrase all by itself that can't really be broken into parts.
Oh, sure, act against the status quo and they ship you off to Slashdot Gitmo.