The whole point of my post was to suggest one method for causing trouble with URL requests, and I don't doubt that there are others.

However, that doesn't change the fact that, while basically every step of the process is potentially up for grabs, the URLs stamped into the disk are static. Short of replacing the disk nobody gets to change them.

If you control the JVM, you can rewrite them there, if you control the player's OS, you can rewrite them there, if you arrange for your host to be the one replying you can provide whatever response you wish, all true, all bad; but not the same as changing the URLs on the disk.

I think that the apps are supposed to be signed(at least to get useful elevated priviliges, like access to the network or to the player local storage); but if a signed, legitimate, app makes a network request to a server that is no longer friendly, then it becomes a question of input validation, even if the application signing scheme is 100% in order and nobody screwed any part of that up.

Call me a pessimist; but I'd bet nontrivial money that a lot of the 'interactive' cruft that is pumped out to bulk up 'special edition' releases is barely up to the challenge of presenting a helpful error message if it gets a 404 from the remote host, much less not falling over and wagging its tail against moderately clever malice. In that case, it'd be a fully signed and approved app doing the work, but taking action based on (ill-founded) trust in content it downloaded.

I'd not be terribly interested in the capabilities of the players themselves(routers make better zombies and are way more internet facing and unlikely to be turned off, and generally atrocious on security); but I would be very, very, nervous about anything that serves as a nice, subtle, persistent implant on a LAN.

Even enterprises have a nasty habit of pretending that they can get away with a little sloppiness 'inside the firewall', and consumer gear often can't be persuaded not be absurdly trusting of anything that happens to share a subnet with, in the interests of ease-of-use, 'autodiscovery', and similar. If you can get an implant on one device, especially one that nobody is going to suspect(and may have few options, short of replacing, if they do), you can reinfect other devices as they pop up more or less at your leisure.

Unfortunately, it's not just blu ray: 'BD-J' is their specific variant; but it is based on the so-called 'Globally Executable MHP', a truly horrifying acronym-standard-soup constructed to enable vaguely interoperable java-based UI atrocities for various flavors of set top box associated with DVB-T, DVB-S, and DVB-C(Basically, all digital broadcast and cable activity that isn't ATSC, ISDB, DTMB, or some fully proprietary oddball).

BD-J is North America's main point of contact with this delightful substance; but it enjoys near-total ubiquity in the parts of the world that also use DVB.

It doesn't rank terribly high on the list of choices, given that it would be a pain in the ass to get your malware pressed into a reasonable number of disks(without suitable insider access to the later stages of disk manufacture process, in which case you might have some real room for fun); but there is one little detail that might get rather ugly:

With 'BD Live', disks can be authored to include access to network resources, as well as locally stored assets, in their Java-driven interactive content stuff. Now, there is no way for an attacker to change the URLs a disk requests; but nor is there a way for anyone else to do so. Whatever was stamped into the disk at production will remain until the disk leaves use.

Given that companies come and go, and company interest in specific products tends to wane even faster, I would be very, very, very, surprised if the various companies releasing 'BD Live' disks have managed to always retain control of the domain names that their disks will attempt to access. It wouldn't be a terribly high value exploit; but since a disk will attempt to access exactly the same URLs until it dies, you might be able to score a steady trickle of reliable re-infections by snapping up any lapsed domains associated with BD Live disks and adding a little 'bonus content'.

I suspect that there are a number of ways in, given the usual attention given to firmware quality; but blu-ray isn't helped by having a security model marked by absolute paranoia about the precious 'content' escaping, combined with some amount of incompetence and a lot of pure apathy about any other security concern.

With both the BD+ vm and the BD-J stuff, there is a lot of attention paid to 'ooh, the an unauthorized player attempting to do unauthorized things with the content on the disk?!'; but the contents of the disk are largely treated as trusted and the playback device is treated almost entirely as a potential adversary, not as a potential target, either from the disk side or the network side.

If you have a large enough market, the simplicity and repeatability of dedicated controllers with buttons chosen precisely for your game's design and so on is attractive.

If you don't, you run into the problem that low volume production of such gear isn't going to make the price point any more attractive, and it's fairly bulky and expensive for something you can only play a few games with.

Anyone know what the feasibility might be of, instead, of taking advantage of what is already available? For mics, the attempt to make voice control a fad left a fair number of consoles already equipped with one, cellphones and tablets all have them and support wired or wireless headsets, and USB mics of unexceptional quality cover everyone else for not much money. On the guitar side, probably-awful 'beginner' units are $60-80(probably less if you get one used after buyer's remorse claims the original victim), and essentially any electric guitar will support putting out a low-level signal into a 1/4inch jack. If a device already has a line in, a simple mechanical adapter will do, if not, cables that are a USB audio-in on one end, 1/4inch jack on the other are quite cheap. Once you had that, your game could presumably crunch the guitar's output and (depending on how much 'game' and how much 'learning tool' you want) do anything from treating a few large contact areas as 'buttons' to actually grading you on the degree to which your results match the correct output.

I doubt that, if the user needs to purchase everything, particularly new, you could beat the package cost of a mass-produced controller pack; but if you don't think that you have the volume for a suitable production run of instrument-controllers, it seems like an approach that has very low marginal cost and can work with more or less any instrument floating around in the wild, might be less risky and more approachable.

Given that China has historically been the nominally-communist-but-attractively-cheap-and-open-for-business destination, they can't be entirely surprised that Vietnam is now cutting into their action.

That aside, though, I wonder if this is more or less purely cost focused, or whether the quasi-mercantalist Chinese government policies aimed at aiding domestic firms and speeding up acquisition of foreign firms' tech has a bigger role? They aren't necessarily irrational, given that competing on price and low environmental standards isn't exactly a fun game, even when you are winning it; but such policies presumably do encourage foreign firms to head for the exit more quickly at the same time as they reduce the impact of their doing so.

Oh, kazam! Andyring is shown up for the lying sack of shit he is!

The other problem with chlorine is that it's among the cheaper ways of bringing a semblance of sanitation to a municipal water supply.

Really classy first-world jurisdictions can use Ozone systems(which have the advantage of basically perfect decomposition into harmless oxygen by the time the water reaches customers, and need only electricity and occasional spare parts at the treatment plant, rather than big tanks of chlorine); but anywhere else is probably chlorinating the fecal bacteria out of the water supply, which saves a ton of lives(especially if the medical system is lousy); but also means that chlorine is basically just sitting around.

We ran into that issue in Iraq from time to time. Chlorine is a really lousy war gas, barely toxic enough to count as one at all; but just sending a couple guys with guns and a truck down to the water treatment plant could score you enough of the stuff to release in the nearest crowded area for some reliable freaking out and some casualties.

I'm no industrial process chemist, so I don't know how different the factories look; but my understanding is that that is part of why the lists of scheduled chemicals, and the multiple schedules, for the Chemical Weapons Convention, are as messy as they are. There are some that we've decided nobody has any legitimate reason to be playing with; but loads of dual-use chemicals.

The history gets a little muddled because different classes of chemicals were developed with different primary purposes at different times.

Various primitive fumigants (burning sulfur, various other 'noxious smoke' type stuff) date back approximately forever, and have been used to discourage pests; and also 'discourage' the guys digging a tunnel under your castle; but are pretty tepid war gasses in the open, more suffocating than overtly toxic.

Some of the WWI war gasses were substantially tailored for effect on humans(or, even where previously known, like Chlorine, pretty expensive and annoying to deal with as agricultural agents), though at least the arsenicals also overlapped with pesticide developments.

Nerve agents started as pesticide research(and to this day, the lesser organophosphates are used for the purpose); but(thanks to lousy benchtop practice that nearly killed a few of the scientists involved) it became clear that the peppier flavors were also...eminently suitable...for getting rid of large mammalian pests. Thankfully, in WWII, the Germans overestimated allied knowledge of nerve agents, based on a misreading of the patent literature, and didn't want to risk reprisal. Had this not been the case, V-2s full of sarin would have been technologically feasible, which would have really ruined some days.

There's also the basic difference that 'enterprise' MiTM-ing is potentially kind of a dick move, depending on exactly how hard HQ feels like squeezing somebody's innocent checking of their email over lunch or whatever; but it's a fairly clear exercise of control over hardware by that hardware's owner.

Seeding hardware with malware and then selling it? Not so much. Yeah, maybe there is some nonsense clickwrap EULA; but there is no real consent of any kind, or even a proper warning.

If only for your own sake(having your own employees getting fooled because your MiTM proxy re-signs bogus certs without flagging them would be counterproductive) odds are that 'enterprise' systems are also more competent; but even if they aren't it's a pretty major difference in scope.

In my own admin-ly capacity, playing content cop is something I do reluctantly, and only as much as network security requires; but we never tamper with devices we don't own(deny them access to the network, sure, touch them, never) and staff are proactively warned and welcome to ask in more detail, if they wish, about what we do and why we do it.

It's quite possible; but there definitely are web types(and, even more so, their 'content provider' masters) who think exactly this, so I was willing to take the risk.

Pretty much this exact attitude is why the "Encrypted Media Extension" 'spec' exists, to provide something that qualifies as 'HTML 5' (Don't call it a plugin! It's a 'Content Decryption Module' that just happens to be operationally identical to or worse than a plugin!); but allows the site operator full control over execution.

Pernicious nonsense. If you elect to put some mixture of code, markup, and art assets on a public webserver my user agent will handle the results as much in accordance with my desires as I can make it do so.

This is how the 'web' has always been supposed to work: support for flexible rendering and fallback to accommodate a variety of user agents with different characteristics and capabilities is built in(although often underused, unless one forces the issue). Were it designed to be all about you, the arrangement would be much more along the lines of a relatively rigid page description language(PDF style, say) and a more robust VM for you to do whatever you want in(like the late and largely unlamented Java Applet).

Yes, unfortunately, nothing short of fire and sword will rid us of people who want the internet to be more like TV; but a web developer claiming that the user agent must take it and like it is about the same as a writer or publisher saying that highlighting sections of a book, or cutting a magazine apart, are copyright infringement. Stuff it.