This is especially likely now that memory controllers and GPUs and other formerly-motherboard components are now sharing a die, or at least a package, with the CPU. The latency savings cannot be denied; but it does mean that the CPU package needs rather more pins/lands than it otherwise would, and increases the number of things that can make a given socket design either fully obsolete or 'works; but not as designed'.
There is certainly a point past which changing sockets all the time is just about extracting rents; but there are plenty of reasons why a a new CPU design might either require a new socket, or be sufficiently poorly supported by the old one that buying a new CPU for an old motherboard wouldn't increase performance.
It isn't a sure thing; the entropic forces of the uncaring universe are almost poetic in their creative destruction; but black boxes trade density for robustness in a pretty serious way.
The classic ones, at any rate, are well sealed and record magnetically onto loop of stainless steel wire. Seriously retro in terms of data density; and you don't just plug it into the nearest USB port(which is why many aircraft also have flight data recorders designed for non-emergency use, which are much less survivable; but much more convenient for routine diagnostics); but anything not involving serious corrosion or an excursion above the Curie temperature of the recording loop should be pretty much irrelevant...
How does iOS approach this problem differently?(Honest question, not trolling)
Their review process and willingness to revoke applications are a bit tougher; but history suggests that they don't tend to detect hidden behaviors all that well(ie. the C64 emulator that had a secret basic interpreter mode hidden behind a couple of keystrokes...) They might drop the banhammer faster; but they wouldn't detect something like this either.
Do they simply prevent all 3rd party applications from interacting with the text-messaging subsystem? That would solve the problem; but also make the application in question impossible, which doesn't seem like a good solution.
Among other abominations. I'm pretty sure that the latest versions, as defined by Adobe authoring tools, have nearly arbitrary embedding support, for such wacky fun as Flash(and, of course references to external URLs are supported, for PDFs that won't work without an internet connection...)
It's too bad, really. They've taken what was an at least adequate page description language and(through some combination of a desire to keep its status as an open standard as dead a letter as possible, and some Quixotic quest to defeat HTML at its own game) turned it into a horrible monster. Standardized subsets, like PDF/A, are safe enough; but "PDF" defined as "whatever Acrobat N spits out" basically has all the worst attributes of HTML from the bad old days(monstrously limited, many sites supported only by a single vender's renderer, security is fucked); but without basic features like text reflow that actually works, or decent style/content separation.
We can only wait in breathless horror for them to add an x86->actionscript bytecode recompiler and a network TUN device to the Acrobat Reader install, to support delivering entire virtual machines, with full network access, embedded in PDFs...
As much as I loath Adobe's ghastly "features" on top of the (comparatively) functional PDF core, it seems only fair to point out that web browsers spend their operational lives loading and interpreting a mixture of page-description markup language and 'active' elements that do all sorts of things. This is why they are such a security headache; but the market for browsers that don't do javascript is pretty tiny.
Arguably, having somebody who (A) Isn't Adobe. and (B) Spends all their time developing a rendering engine for a combination markup language/scripting environment/embedding system, handle support for a second very common one seems fairly reasonable.
Obviously, any browser maker who doesn't provide a configuration interface to enable/disable various renderers, if desired by advanced users, deserves to spend eternity with Bonzibuddy in the 8 cold hells; but the notion of browsers rendering PDFs in addition to HTML/JS/CSS seems reasonably logical, on the whole.
Not that Adobe doesn't have enough on its shame-plate at the moment; but the fact that browser makers are rolling their own PDF viewers(or, at very least, putting adobe provided ones on a much shorter leash than generic plugins are given, as with Chrome's integration of Flash, also an Adobe product) really should give their software engineering guys pause. As should the fact that "(pdf warning)" is considered a standard element of internet politeness when linking to things...
FFS, Postscript was designed back when the raster image processor had to live in firmware and run on a 12MHz m68k. PDF (c. 1993) was supposed to be the lessons-learned variant of postscript (1984) with a bit less of the turing-completeness and better suitability as a static document format.
On modern hardware, PDFs should fucking fly. And, in renderers not produced by Adobe, they often render about as quickly as web pages do(particularly if said web pages are gimped by excessive javascript or slow adservers...) Acrobat, though, just keeps on sucking, even as Adobe continues to add random security-flawed features that make it harder to rely on 3rd party alternatives to render the stuff that Adobe authoring tools put out...
In broad strokes, it looks like they've more or less managed a modern retake on a roughly WWII-era diesel electric design, with substantial tradeoffs of durability and attack capability in favor of stealth and low cost. Not something you would want to take on a carrier group in(even a much fancier stealth hull isn't going to save you from active sonar if you got close enough to actually do anything, and I'm sure that being inside when a shockwave cracks the epoxy portion of your composite hull and the water starts coming in would ruin your whole day...); but "over $5 million" is crazy cheap by submarine standards.
The only potentially interesting military application (particularly in combination with present day and/or reasonably expected future advances in low-cost autonomous robotics technology) might be area denial spamming... Even a relatively modest diesel-electric submarine for military use will run ~400-500 million. The nuclear superpower toys are a billion plus. If somebody with minimal interests in international shipping and a bad attitude were to do a "liberty ship" style low cost/high speed standardized design spin of unmanned or very lightly crewed plastic subs, with actual shipyards instead of clandestine swamp construction, they could probably put an alarming number of them in the water for comparatively little money and time, with instructions to Roomba around attacking anything large and ferrous.
Each individual encounter with an actual military force would be pitifully one-sided; but(as with the Somali pirate situation), the world doesn't have all that many Big Serious blue-water navies compared to how many logistically vital civilian shipping boats it has....
Yeah, that's the tricky bit. There are certainly arguments to be made that the Android security model isn't quite as granular as it might be, and arguments to be made that smartphone applications in general are getting pretty grabby about what permissions they demand in order to work. However, in this case, the privileges required to wreak havoc are pretty nearly identical to those required to do what the app says on the tin. One could always parse out endless compromises with rate-limiting or per-text OS imposed nag boxes; but that is a bit of a quagmire.
If this were some random game or something, it'd be easy to say "clearly the OS security model is broken and/or the user is paying no attention, see to that."; but that isn't really the case here.
Honestly, I'd be more concerned about what it says about the difficulties(both any that are specific to android, and any that are more or less architecturally inevitable) of smartphone security models...
Since this application is designed to send text messages, it is a bit tricky to imagine a good security model that would allow it to send ones you want it to and prevent it from sending ones that you don't; but that doesn't make the fact that potentially hostile code has access to both your contacts and a (not infrequently billed-per-use) telcomm service any more comforting.
The problem isn't attack, this thing has a crush depth of under 100 feet and is 'armed' only to the extent that the cartels probably send a heavy or two along to make sure that the crew don't decide to find a higher bidder for the cargo.
The tricky bit is detection: There's a lot of ocean out there, and a composite-skinned boat barely sticking out of the water is going to have a comparatively minimal radar presence, a worthwhile thermal signature only if they are running on diesel, and probably count as fairly quiet by the standards of all but substantially more expensive combat subs.
An underground fight club is the sort of thing that Broadcom's Henry Nicholas would have been a much more plausible pick for.
Sure, you barely count as a CEO these days if you don't have the SEC on your back; but not everyone mixes wild parties, hard drugs, doping clients, and building a secret sex dungeon under his house while his wife is on vacation, with run of the mill options backdating...
Being a terrorist leader, on the other hand, is pretty much a combination of the best parts of being a cult leader and being an extreme sports enthusiast: Groupies, adulation, adrenaline, explosions, sponsors, probably more burqa-babes than you admit to in public...
I read in the article that someone said they employed "five levels of encryption". I wonder how that compares with the effectiveness of say, 5 x rot13?
I strongly suspect that the cops being quoted were judging level of super-double-ultra-security-ness with roughly the same enthusiasm for self-aggrandizement generally shown in such situations. Unless the public would be immediately capable of recognizing the perp as being a candidate for 'America's Funniest Home Videos: The Blooper Reels', they are typically accorded the status of 'terrifying criminal mastermind that yours truly managed to bring to justice; but might need more expansive powers to stop in the future, cough cough'...
The problem, of course, is that even people who are quite good(and this guy obviously wasn't) have the nasty habit of coming up with ciphers that they cannot attack and mistaking them for secure ones...
IIRC, they 'layman's historical introduction to cryptoanalysis' type overviews do often mention that more or less the earliest clearly recognizable use of frequency analysis cropped up among islamic scholars working on the problem of separating authentic Muhammad quotations from the assorted non-canon stuff that had crept in, by examining word frequency distributions across different passages...
The guy is a moron no matter who cracked the cipher, of course, because it doesn't really matter who, just whether somebody did or not(excluding the edge cases of certain comparatively modern ciphers, that might conceivably have been cracked in private).
Especially odd when most trans-oceanic flights offer calls(albeit at $10/minute) through seatback phones. It might well be, though, that the sort of conditions that cause aircraft to crash don't do much for reception...
What's the problem, your honor? The trademarked name of the experience enhancement bundle we included is, in fact, twenty consecutive 'space' characters followed by a line break. The presence of exactly that name on our contents disclosure should be evident to the informed consumer.
"Discretely" would be somewhat difficult. At best, if nobody examines the IR aperture for remote control all that closely, you'd have until the first backlight failed out of warranty and some geek cracked it open for a DIY repair.
Now, on the other hand, it would be rather easier to hide the exfiltration of data gathered by a camera that was prominently trumpeted on the box as being related to a feature of some sort(New 'Dynadjust'(tm) technology automatically optimizes Your HD Home Theatre Experience, in real time!)... Given the low cost of a chintzy cellcam and an IR LED or two, a design that adjusts the 'virtual 5.1 surround sound' or whatever variant of nausea3D is currently in vogue based on viewer position would be (rightly) seen as a gimmick by serious home theatre types; but wouldn't raise any flags on plausibility grounds.
I'm sure that that is the current buzzword for getting projects funded, and the item ticked on the brochure for these various devices(and I suspect that the majority of the iRobot chassis are being sold to bomb squad types with the occasional dose of hazmat) ; but the R&D for autonomy and radiation hardness definitely precedes 2001 by a fairly large margin. The "robots that can operate over rubble by means other than just making their treads bigger" thing, though seems to be more recent.
Besides the "cruel and unusual" issue, I'm not sure that condemned prisoners who have the exciting prospect of an even more unpleasant death in front of them would necessarily be all that motivated to get the job done...
Even if you were willing to offer them rewards sufficient to obtain their cooperation, you might run into some trouble getting them up to speed on what needs to be done in the time available.
I am a bit surprised that Japan didn't have a more robust robotic response handy(yes, delicate digital circuitry does not mix well with radiation; but RF-controlled large scale model vehicles can be had in fairly large sizes with fairly primitive analog, and thus comparatively rad-hard, controllers), I assume that the general mayhem of earthquake and tsunami had something to do with it.
On the other hand, though, it isn't a complete surprise that the US might have more radiation-specific robots: Since the US was among the earliest and largest-scale users of nuclear technology, they have a fair few "Christ, guys, what the hell were we thinking at the time?" sites and designs that need to be monitored(and, unlike the former USSR, who also has their share, didn't suffer a major economic contraction right about when they needed to start monitoring them). Plus, I suspect that rad-hard robotics control systems can borrow R&D and component economies of scale from the space program, which also has to send semi-autonomous systems into fairly energetic environments and have them not fail. Components designed for space use are not exactly cheap(BAE's RAD750 is essentially a $200,000 G3-era PPC board...); but cheaper than doing things in one-offs.
The "Derivative work" argument might actually be open for some rather novel abuse, depending on how much patience for bullshit the judge has.
Ripping a CD, for instance, into any lossy-compressed format is arguably creating a derivative work(albeit one that tries as hard as possible within the bandwidth limits to sound like the original). One could argue that even if "place shifting" or individual backup copies are legal, lossy-compressed versions are not copies but derivative works.
If one felt particularly nasty, one could even try to assert that (since different devices have different playback characteristics) playback on any device with less than perfect fidelity is the creation of a derivative work, and unauthorized unless licensed(the labels would ever so graciously grant you the license to produce up to (2) such derivative works; but no more...)
Slashdot Mirror
I'm guessing that she isn't gunning for the title of "small government Republican" here?
This is especially likely now that memory controllers and GPUs and other formerly-motherboard components are now sharing a die, or at least a package, with the CPU. The latency savings cannot be denied; but it does mean that the CPU package needs rather more pins/lands than it otherwise would, and increases the number of things that can make a given socket design either fully obsolete or 'works; but not as designed'.
There is certainly a point past which changing sockets all the time is just about extracting rents; but there are plenty of reasons why a a new CPU design might either require a new socket, or be sufficiently poorly supported by the old one that buying a new CPU for an old motherboard wouldn't increase performance.
It isn't a sure thing; the entropic forces of the uncaring universe are almost poetic in their creative destruction; but black boxes trade density for robustness in a pretty serious way.
The classic ones, at any rate, are well sealed and record magnetically onto loop of stainless steel wire. Seriously retro in terms of data density; and you don't just plug it into the nearest USB port(which is why many aircraft also have flight data recorders designed for non-emergency use, which are much less survivable; but much more convenient for routine diagnostics); but anything not involving serious corrosion or an excursion above the Curie temperature of the recording loop should be pretty much irrelevant...
How does iOS approach this problem differently?(Honest question, not trolling)
Their review process and willingness to revoke applications are a bit tougher; but history suggests that they don't tend to detect hidden behaviors all that well(ie. the C64 emulator that had a secret basic interpreter mode hidden behind a couple of keystrokes...) They might drop the banhammer faster; but they wouldn't detect something like this either.
Do they simply prevent all 3rd party applications from interacting with the text-messaging subsystem? That would solve the problem; but also make the application in question impossible, which doesn't seem like a good solution.
Do they do rate-limiting?
Among other abominations. I'm pretty sure that the latest versions, as defined by Adobe authoring tools, have nearly arbitrary embedding support, for such wacky fun as Flash(and, of course references to external URLs are supported, for PDFs that won't work without an internet connection...)
It's too bad, really. They've taken what was an at least adequate page description language and(through some combination of a desire to keep its status as an open standard as dead a letter as possible, and some Quixotic quest to defeat HTML at its own game) turned it into a horrible monster. Standardized subsets, like PDF/A, are safe enough; but "PDF" defined as "whatever Acrobat N spits out" basically has all the worst attributes of HTML from the bad old days(monstrously limited, many sites supported only by a single vender's renderer, security is fucked); but without basic features like text reflow that actually works, or decent style/content separation.
We can only wait in breathless horror for them to add an x86->actionscript bytecode recompiler and a network TUN device to the Acrobat Reader install, to support delivering entire virtual machines, with full network access, embedded in PDFs...
As much as I loath Adobe's ghastly "features" on top of the (comparatively) functional PDF core, it seems only fair to point out that web browsers spend their operational lives loading and interpreting a mixture of page-description markup language and 'active' elements that do all sorts of things. This is why they are such a security headache; but the market for browsers that don't do javascript is pretty tiny.
Arguably, having somebody who (A) Isn't Adobe. and (B) Spends all their time developing a rendering engine for a combination markup language/scripting environment/embedding system, handle support for a second very common one seems fairly reasonable.
Obviously, any browser maker who doesn't provide a configuration interface to enable/disable various renderers, if desired by advanced users, deserves to spend eternity with Bonzibuddy in the 8 cold hells; but the notion of browsers rendering PDFs in addition to HTML/JS/CSS seems reasonably logical, on the whole.
Not that Adobe doesn't have enough on its shame-plate at the moment; but the fact that browser makers are rolling their own PDF viewers(or, at very least, putting adobe provided ones on a much shorter leash than generic plugins are given, as with Chrome's integration of Flash, also an Adobe product) really should give their software engineering guys pause. As should the fact that "(pdf warning)" is considered a standard element of internet politeness when linking to things...
FFS, Postscript was designed back when the raster image processor had to live in firmware and run on a 12MHz m68k. PDF (c. 1993) was supposed to be the lessons-learned variant of postscript (1984) with a bit less of the turing-completeness and better suitability as a static document format.
On modern hardware, PDFs should fucking fly. And, in renderers not produced by Adobe, they often render about as quickly as web pages do(particularly if said web pages are gimped by excessive javascript or slow adservers...) Acrobat, though, just keeps on sucking, even as Adobe continues to add random security-flawed features that make it harder to rely on 3rd party alternatives to render the stuff that Adobe authoring tools put out...
In broad strokes, it looks like they've more or less managed a modern retake on a roughly WWII-era diesel electric design, with substantial tradeoffs of durability and attack capability in favor of stealth and low cost. Not something you would want to take on a carrier group in(even a much fancier stealth hull isn't going to save you from active sonar if you got close enough to actually do anything, and I'm sure that being inside when a shockwave cracks the epoxy portion of your composite hull and the water starts coming in would ruin your whole day...); but "over $5 million" is crazy cheap by submarine standards.
The only potentially interesting military application (particularly in combination with present day and/or reasonably expected future advances in low-cost autonomous robotics technology) might be area denial spamming... Even a relatively modest diesel-electric submarine for military use will run ~400-500 million. The nuclear superpower toys are a billion plus. If somebody with minimal interests in international shipping and a bad attitude were to do a "liberty ship" style low cost/high speed standardized design spin of unmanned or very lightly crewed plastic subs, with actual shipyards instead of clandestine swamp construction, they could probably put an alarming number of them in the water for comparatively little money and time, with instructions to Roomba around attacking anything large and ferrous.
Each individual encounter with an actual military force would be pitifully one-sided; but(as with the Somali pirate situation), the world doesn't have all that many Big Serious blue-water navies compared to how many logistically vital civilian shipping boats it has....
Yeah, that's the tricky bit. There are certainly arguments to be made that the Android security model isn't quite as granular as it might be, and arguments to be made that smartphone applications in general are getting pretty grabby about what permissions they demand in order to work. However, in this case, the privileges required to wreak havoc are pretty nearly identical to those required to do what the app says on the tin. One could always parse out endless compromises with rate-limiting or per-text OS imposed nag boxes; but that is a bit of a quagmire.
If this were some random game or something, it'd be easy to say "clearly the OS security model is broken and/or the user is paying no attention, see to that."; but that isn't really the case here.
Honestly, I'd be more concerned about what it says about the difficulties(both any that are specific to android, and any that are more or less architecturally inevitable) of smartphone security models...
Since this application is designed to send text messages, it is a bit tricky to imagine a good security model that would allow it to send ones you want it to and prevent it from sending ones that you don't; but that doesn't make the fact that potentially hostile code has access to both your contacts and a (not infrequently billed-per-use) telcomm service any more comforting.
A wiser man than I remarked "The wonderful thing about smartphones is that you don't have to talk on them."
As with any quip, it is a bit overbroad. As with any good quip, it still manages to come close to the heart of the matter.
The problem isn't attack, this thing has a crush depth of under 100 feet and is 'armed' only to the extent that the cartels probably send a heavy or two along to make sure that the crew don't decide to find a higher bidder for the cargo.
The tricky bit is detection: There's a lot of ocean out there, and a composite-skinned boat barely sticking out of the water is going to have a comparatively minimal radar presence, a worthwhile thermal signature only if they are running on diesel, and probably count as fairly quiet by the standards of all but substantially more expensive combat subs.
An underground fight club is the sort of thing that Broadcom's Henry Nicholas would have been a much more plausible pick for.
Sure, you barely count as a CEO these days if you don't have the SEC on your back; but not everyone mixes wild parties, hard drugs, doping clients, and building a secret sex dungeon under his house while his wife is on vacation, with run of the mill options backdating...
Being a terrorist grunt is a sucker's game.
Being a terrorist leader, on the other hand, is pretty much a combination of the best parts of being a cult leader and being an extreme sports enthusiast: Groupies, adulation, adrenaline, explosions, sponsors, probably more burqa-babes than you admit to in public...
I read in the article that someone said they employed "five levels of encryption". I wonder how that compares with the effectiveness of say, 5 x rot13?
I strongly suspect that the cops being quoted were judging level of super-double-ultra-security-ness with roughly the same enthusiasm for self-aggrandizement generally shown in such situations. Unless the public would be immediately capable of recognizing the perp as being a candidate for 'America's Funniest Home Videos: The Blooper Reels', they are typically accorded the status of 'terrifying criminal mastermind that yours truly managed to bring to justice; but might need more expansive powers to stop in the future, cough cough'...
The problem, of course, is that even people who are quite good(and this guy obviously wasn't) have the nasty habit of coming up with ciphers that they cannot attack and mistaking them for secure ones...
IIRC, they 'layman's historical introduction to cryptoanalysis' type overviews do often mention that more or less the earliest clearly recognizable use of frequency analysis cropped up among islamic scholars working on the problem of separating authentic Muhammad quotations from the assorted non-canon stuff that had crept in, by examining word frequency distributions across different passages...
The guy is a moron no matter who cracked the cipher, of course, because it doesn't really matter who, just whether somebody did or not(excluding the edge cases of certain comparatively modern ciphers, that might conceivably have been cracked in private).
Especially odd when most trans-oceanic flights offer calls(albeit at $10/minute) through seatback phones. It might well be, though, that the sort of conditions that cause aircraft to crash don't do much for reception...
What's the problem, your honor? The trademarked name of the experience enhancement bundle we included is, in fact, twenty consecutive 'space' characters followed by a line break. The presence of exactly that name on our contents disclosure should be evident to the informed consumer.
"Discretely" would be somewhat difficult. At best, if nobody examines the IR aperture for remote control all that closely, you'd have until the first backlight failed out of warranty and some geek cracked it open for a DIY repair.
Now, on the other hand, it would be rather easier to hide the exfiltration of data gathered by a camera that was prominently trumpeted on the box as being related to a feature of some sort(New 'Dynadjust'(tm) technology automatically optimizes Your HD Home Theatre Experience, in real time!)... Given the low cost of a chintzy cellcam and an IR LED or two, a design that adjusts the 'virtual 5.1 surround sound' or whatever variant of nausea3D is currently in vogue based on viewer position would be (rightly) seen as a gimmick by serious home theatre types; but wouldn't raise any flags on plausibility grounds.
I'm sure that that is the current buzzword for getting projects funded, and the item ticked on the brochure for these various devices(and I suspect that the majority of the iRobot chassis are being sold to bomb squad types with the occasional dose of hazmat) ; but the R&D for autonomy and radiation hardness definitely precedes 2001 by a fairly large margin. The "robots that can operate over rubble by means other than just making their treads bigger" thing, though seems to be more recent.
Besides the "cruel and unusual" issue, I'm not sure that condemned prisoners who have the exciting prospect of an even more unpleasant death in front of them would necessarily be all that motivated to get the job done...
Even if you were willing to offer them rewards sufficient to obtain their cooperation, you might run into some trouble getting them up to speed on what needs to be done in the time available.
I am a bit surprised that Japan didn't have a more robust robotic response handy(yes, delicate digital circuitry does not mix well with radiation; but RF-controlled large scale model vehicles can be had in fairly large sizes with fairly primitive analog, and thus comparatively rad-hard, controllers), I assume that the general mayhem of earthquake and tsunami had something to do with it.
On the other hand, though, it isn't a complete surprise that the US might have more radiation-specific robots: Since the US was among the earliest and largest-scale users of nuclear technology, they have a fair few "Christ, guys, what the hell were we thinking at the time?" sites and designs that need to be monitored(and, unlike the former USSR, who also has their share, didn't suffer a major economic contraction right about when they needed to start monitoring them). Plus, I suspect that rad-hard robotics control systems can borrow R&D and component economies of scale from the space program, which also has to send semi-autonomous systems into fairly energetic environments and have them not fail. Components designed for space use are not exactly cheap(BAE's RAD750 is essentially a $200,000 G3-era PPC board...); but cheaper than doing things in one-offs.
The "Derivative work" argument might actually be open for some rather novel abuse, depending on how much patience for bullshit the judge has.
Ripping a CD, for instance, into any lossy-compressed format is arguably creating a derivative work(albeit one that tries as hard as possible within the bandwidth limits to sound like the original). One could argue that even if "place shifting" or individual backup copies are legal, lossy-compressed versions are not copies but derivative works.
If one felt particularly nasty, one could even try to assert that (since different devices have different playback characteristics) playback on any device with less than perfect fidelity is the creation of a derivative work, and unauthorized unless licensed(the labels would ever so graciously grant you the license to produce up to (2) such derivative works; but no more...)
Yup. Users hate it; but that just gives my pitying stare some extra practice.