Only 45 replies and we are Godwin'd. On a serious note, I think your 2nd paragraph is unfortunately true on a practical level. So is your first, for that matter.

Suspected != guilty and if they go around publicizing suspects or even people who the police have named as suspects or "persons of interest" who turn out to be innocent, it will hurt Anonymous's own reputation big-time.

What they - and everyone else - can and should do is make sure that if you do run across child porn or links to what you think is child porn, you immediately report it to all relevant authorities and that if the authorities seem to be ignoring a case, that all relevant news outlets are notified. If the news outlets seem to be participating in a cover up, notify other news outlets, but be careful: What looks like a "news outlet conspiracy of silence" may be because the FBI is in the middle of a sting and the feds have asked the news outlets to keep quiet until the trap is sprung. If Anonymous's well-meaning attempts to bring things into the open result in the sting being aborted or going bust, well, that would be bad.

On a side-note:

* Do not go "looking for" child porn - you could wind up being charged and convicted yourself. If you are wondering what it's like, my best educated guess is it is like looking at images of concentration-camp children: 1) the underlying event that happened to land on camera haunts the person in the photograph for his or her life, 2) the image itself is likely to be so stomach-churning that it will haunt you for a long time, and even if it doesn't, 3) the knowledge of what happened to that child should haunt you for a long long time (if it doesn't, either you have grown jaded and I'm sad for you, or you need to talk to someone because your conscience may be less than that of the average adult's and this diminished conscience may lead you to hurt someone without realizing it and/or without caring)

* If you routinely do things in your fight against child-porn that put you at a higher risk of running across it, as some of these Anonymous guys likely are, take technical steps to reduce your risk (use a text-only browser, for instance), and have a lawyer on retainer. Ask your lawyer what steps you need to take so when the police do come knocking it's painfully obvious to the police, the jury, and to everyone else that you are not intending to actually download or possess the stuff but sometimes it gets through your technical barriers.

I have a cheap knock-off of the very box you pointed to.

It works fine as a DVR but as far as I can tell, it's just recording one of the programs not the entire stream. Also, there is no indication of whether it is recording meta-data and other data or if it's discarding it before recording it. In other words, it's not what I am looking for.

Anyone know of a sub-$1000 device that will record and play back "raw" ATSC signals?

In short,

* a recording device that will take an arbitrary digital TV channel, convert it from analog to digital (all airwaves are inherently analog at some level), and record the bits verbatim, along with some meta-data like the time of day, the frequency recorded, and maybe some extracted data like the digital sub-channels in the stream and information about what is playing on each sub-channel now and in the near future.

* ideally, DVR-like timer recording capability.

* a playback device that will put that recording onto a specific RF frequency. If the RF frequency is the same as the originally recorded frequency, my television should be fooled into thinking it is a channel that the TV already has mapped (e.g. RF channel 14, "display" as channel 20).

* ideally, a DVR-playback capability that would make the box act like a DVR, albeit one that uses a lot more disk space than your typical DVR. The output would go to the TV over a dedicated AV connection not the RF "CATV/Antenna" connection.

* ideally, the ability to recognize a USB device and copy the raw recording to it for storage or analysis/playback on a computer that can read the format.

Q: The use of such a device for legal and engineering purposes is obvious, but why would any normal consumer want such a thing?

A: Because at least then I'll KNOW for sure that I recorded what my receiver (or more specifically, the receiver in this magic box) received, not some partially-processed intermediate version. It will also allow me to record content encoded in formats that haven't been developed yet (as of January 2015), so I can play them back on a TV that supports that format.

I want large-data formats to succeed because I want my "boxed sets" to take up less shelf space. Give me an entire season at as-broadcast resolution on a single disk (13 episodes of HD or 3-4 times that for a very-good-quality digitization of old stuff that only exists on broadcast-quality NTSC tapes would be nice), including bonus material, and I'll be happier than if the large disks are used only for higher-definition content. My eyes aren't what they once were and neither are my ears.

For the same reason I wish all CD players (especially those in cars) were replaced with "audio disk" players that could play audio from video DVDs, DVD-audio, and all common computer audio formats in addition to the current CD-audio/MP3/WAV formats that seem common for new players today.

How about taking a Yacc-like approach and creating a meta-standard that has each "file" on the disk include a list of codecs required for that file and which has each disk include a description of the various video- and audio-decoding algorithms needed to play the "files" on the disk (excluding the common standards that existed when the "meta-standard" was finalized - those would be baked in to all players), then let the player figure out what to send to the output ports based on the data format, the data, the processing capability of the player, and if known (or presumed, for one-way "outputs" like analog) the capability of the display device.

This way the only "hardcoded" part of the standard would have to deal with the raw laser I/O from the disk to the laser pickup on the player, basic things like the layout of error-correcting code, slightly-less-basic things like the filesystem-layout or equivalent, and a standard way for the player to understand the disk and file meta-data. Then the player could take it from there, creating codecs (or more accurately, de-coders) as needed based on the information on the disks.

The same technique could be used for future-proofing display devices. For display-devices with 2-way communication, the display could communicate its capabilities to the player in a standardized format, and possibly even communicate as-yet-undefined capabilities to the player as well (UV/IR, specialized color gamuts, infra/ultrasonic capability, alarms and sensors, etc.). These capabilities could be matched up with the format of the disk.

Example:

If the disk has a codec that says "supports SENSOR_STD_2019a" and the meta-code for the standard "SENSOR_STD_2019a" says
"if SENSOR_STD_2019a data NO_WARM_BODY_PRESENT becomes TRUE then execute GO_BACK_15_SECONDS_AND_PAUSE"

and the display tells the player
"SENSOR_STD_2019a:NO_WARM_BODY_PRESENT=TRUE"
then the player can act on it, even if the player was manufactured well before SENSOR_STD_2019a even existed.

The speed hit would suck but steganographic protocols for getting things like encrypted email back and forth may be badly needed for countries like China.

http://www.seeminglyinnoculous...

might contain a bunch of images of pink ponies, which each contain stenographicly-encoded encrypted emails. If you want to send an email, you upload what appears to China's Firewall to be just another Pink Pony.

I can't be sure, but I think this may have already been done :).

While you could do a full-blown VPN with this technology, I would hate to think how long it would take to load a typical 0.1-5MB web page over such a VPN.

The same type of "deep inspection" firewall trick can and probably should be at least CONSIDERED for ANY mission-critical machine that is deemed "too risky" to put on the same network with "unacceptably high risk of becoming contagious" machines. In some cases it may even make sense to apply this technique to machines that ARE running supported OSes and which are BELIEVED to be very well protected all by themselves.

For example, if you are running an in-house web site to provide selected employees with a web interface to the corporate back-end data center, it may make sense to put a dedicated security box between the data server and the web server and another dedicated security box between the web server and the company's "office" network. This way if some employee's machine gets infected, the web server is less likely to become compromised, and if the web server is compromised it is less likely to compromise the back-end data server. Also, the security devices can watch for suspicious activity, such as out-of-the-ordinary traffic patterns from the "office" network to the web server or out-of-the-ordinary data requests from the web server to the data server and raise alarms where warranted.

I'm sure by now you are worried about "what if the security boxes get hacked." That is a concern. There are ways of making the security boxes be pass-through boxes which are invisible/non-addressable to the office network, the web server, and to the back-end data center, which would mean that the only ways to deliberately "hack" them would be through a different network connection entirely (such as the connection to a dedicated, otherwise-non-network-connected computer in your security officer's office) or by sending carefully manipulated traffic through them that was designed to "break the XYZ-brand security box that someone told you might be there" or "break the security box that your traffic-analysis pre-hack investigation made you suspect was there."

If you don't care about STOPPING bad traffic but just want to raise alarms, a traffic-splitter that feeds a copy of all traffic to your security boxes will do the job and it will be all but completely invisible to the networks they are monitoring (a splitter will not be completely invisible, but it can be made to look like a non-addressable/dumb repeater, switch or hub from the point of view of the networks it is connected to - the only hint of its existence to someone without physical access to measure voltage levels may be a very slight increase in latency).

If you have hardware firewalls that do deep-packet inspection and reject all traffic that doesn't match whitelisted traffic, AND your whitelist is detailed enough so that in practice it rejects all unwanted traffic, you should be okay.

So, unless the traffic of your specific can't-migrate-to-a-supported-OS application is too expensive to distinguish from unwanted traffic, you should be able to firewall a server so well that the fact that the OS is unsupported and otherwise vulnerable to attack is no longer a "must fix now" issue.

That doesn't mean it isn't an issue, and I would still recommend finding some way to phase it out, but it just means you won't have to fully decommission your Windows 2003 server this year or even this decade.

I'm pretty sure the first few BC's were "pre-mined" by the same person/group which invented BC in the first place, if not as a deliberate way to create BC then as a way to test the protocols, algorithms, and code.

I addressed this general terms in the original post when I said "The company that created and pre-mined the cards would be on the hook for all transaction fees."

In other words, the issuing authority would have to absorb the computational costs of adding all transactions to the blockchain for that currency. They would be "on the hook" because 1) without mining, nobody would validate transactions without imposing a fee, and 2) with transaction fees, fewer people would bother to use the crypto-currency as a "gift certificate."