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.

I could do it, if I had access to the Telco rights of way that were "franchised" away to the local Cable monopolies during the early part of the 80s. We are 35 years later, and haven't improved the delivery model.

Actually, it has to do with Franchise agreements between _______ cable and the local municipalities, which is NOT Capitalism, but some bad version of utility.

Bring me fiber via local Municipality, and let me choose which set of services I can get, from whatever company that wants to offer for whatever price the market will bear. Municipal owned COLO that gives market access to any company that wants it.

No, it isn't a public utility. It is a "franchise agreement" between the Local Municipality and the Corporation. The fact that this is the way things have always been done doesn't mean it has to continue this way.

I propose that instead, we bring FIBER to a COLO, from where the citizens can CHOOSE (market forces) the options and features they desire from the multitude of companies that offer these services.

BY moving the issue of "last mile" ... to a COLO rather than neighborhood corner, it solves all sorts of market issues.

The question is, would you pay 1/2 the price if it was ... better?

OnePlus has a lot of detractors, but the issue of price and bloat has been answered, at least in the Phone Arena.

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.

Socialism requires forced compliance to government will under threat of guns, fines or other forms of governmental aggression to force compliance to arbitrary rules created by those government.

See ObamaCare; forcing people to buy a product they neither want or need, under threat of the IRS, Dept of Treasury and the full force of the US government, and calling it a "Tax", in an effort to create a "health care utopia".

Well there must be a balance between code reuse and custom solutions. To use the trusty car analogy: a car manufacturer doesn't create a new battery for every vehicle (or, indeed, make batteries at all). Unless it's top end, they don't create a different engine for every car, or a different transmission.

If you're making top-end software, then sure, spare no expense. But most projects will suffice just fine using existing libraries. Knowing when to go third party and when to stay in-house is a skillset that a good lead will have.

... or the one.