It could just be that those goddamn perky "morning people" are up bright and early and polluting the dataset while sensible humans are still asleep, or wishing that they were...
That would probably actually make them a good bit less dangerous...
At 1000 times normal size, they would still be small enough to be vulnerable to manual blunt trauma(and pulling their wings off just to watch them crawl around and suffer would be much easier); but they would also be large enough to be taken down with BBs at modest range, or "snake load" handgun rounds at close range.
On 64 bit installs, they generally pay attention to the "OS refusing to install the unsigned driver" behavior, though... Luckily, Realtek isn't behind a gigantic fraction of the world's cheap NICs, so getting updated drivers won't be an issue...
At least, unlike HP and Creative, they have yet to master the art of making crappy drivers larger than entire operating systems of just a few years ago...
They may be pretty chintzy; but they are downright ubiquitous. Things are going to get comedic if every Realtek-equipped PC that also gets Windows updates suddenly starts throwing "unsigned driver" warnings because Microsoft revokes their trust of the Realtek signing key(which they might chicken out of; but they really should do if there are signed rootkit drivers floating around)...
Oh, it's eminently possible, from the architectural perspective of assigning ACLS and default-denies to all kinds of things(heck, you could assign ACLs to every DOM element of every page you load, per-domain control over all kinds of things and so forth.) It might be a chore technologically; but that part is entirely doable.
What I'm saying is that, because it is extremely difficult to know what elements of an arbitrary 3rd party webpage are sensitive, and what elements aren't, attempting to apply a meaningful permissions scheme to extensions that modify web pages is difficult or impossible in practice(unless you are willing to accept amounts of permission confirmation windows that would make a hardened noscript user cry).
Control over local program execution, local filesystem access, and local GUI are all quite doable; because those all consist of easily knowable, and known, sets of objects.
The trouble, is with web pages:
"Permission to modify headers- which headers" Ok, this wouldn't be too bad for some site-specific anti-nuisance plugin(assuming the site's design doesn't change unexpectedly, and break the plugin, or change frequently and habituate the user to accepting any demand for changes a plugin makes); but it doesn't help you too much for site-generic plugins(like the security testing tool in TFA, whose features pretty much include "modify any header on any site, at the user's direction" and secretly included a silent added header.)
Worse, since a fair few pages, in our Web 2.0 age, do a lot of sending and receiving on their own behalf, much of it script driven. This would mean that, in effect, on many domains, permission to modify scripts would imply permission to communicate more or less arbitrarily, just by making the web page communicate for you.
The other problem, with something like a web page, is that the line between "content"(HTML) "style"(CSS), and "scripts"(JS) might be fairly bright programmatically, in terms of the visual result that the user ends up interacting with, it gets pretty fuzzy. Even assuming freedom from sanitization failures and injection attacks, a malicious program that can "just" manipulate the CSS can pull some pretty crazy stunts with a fair few web pages. Now, there is nothing stopping you from having privilege granularity going all the way down to individual CSS elements(or even relationships between elements, say to keep a malicious extension from hiding foreground text by making it the same color as the background); but that would mean that any user would have to be a reasonably serious web developer just to comprehend the permissions list, much less know what is dangerous and what isn't.
I suspect that, if you told Verizon that "Boot-tay loader" was actually the hottest new single from ludacris, rather than a low level firmware reflash, they would probably add it to the V-cast store for you...
Oh, it would definitely be a "nuclear option" sort of thing; but I suspect that it is the only strategy that would have any chance of causing them to reverse their stance.
Companies don't drop their DRM systems because they love freedom and fuzzy puppies, they drop them because the engineering costs and customer support issues are more expensive than the perceived benefits. Thus, if you oppose DRM systems, you can either lower the perceived benefits(by cracking the systems and distributing tools for doing so) or raise the costs. Boycotts are the legal and ethically unproblematic; but generally not that effective, way of doing this. More, er, direct methods of raising customer support costs are less legal and ethical; but probably a lot more effective...
That's actually pretty much even with other smartphones in its class. The trouble is, most carriers(at least in the US); subsidize handsets but don't offer less expensive plans to those who BYO hardware...
If there were a "zOMG Free Phone* *(with $$$$/month contract)" option and a "Pay full retail phone price, or bring your own, $$/month for voice/data" option, the American preference for crippled carrier phones would be an example of the "stupid consumers, only looking at upfront costs" phenomenon. As it is, though, you pretty much choose between getting a subsidized phone, then having the subsidy(and some extra) gouged out month by month, or you pay full price, and then face exactly the same monthly costs. This adds up to paying a fairly major premium to purchase your own device.
If one were of the risk-taking sort, the best way to oppose this sort of crap would probably be to disseminate a trojan app that trips this "efuse" system...
A few hacker nerds whining probably just makes Verizon smile. 10s of thousands of angry customers demanding replacement of their bricked phones, along with massive bad publicity would not.
I hope the sarcasm in my use of "freetard" was sufficiently evident. I find the fact that it is considered normal for all sorts of software to report more or less whatever they want back to the mothership, in exchange for another few days of "You are only a suspected; but not yet confirmed, pirate. You may continue to use our software." rather disturbing.
Were any "respectable" software to be operating maliciously, this would probably be the easiest way to exfiltrate captured data. Because the phoning home is to stymie the wicked pirates, you can rationalize it being encrypted, and thus avoid trivial detection by network sniffing.
Unless Mr. Fusion has come on the market by then, you'll probably be attaching a power cable in any case, so having a standardized combination of power cable/high density PCIe connector would presumably be even easier..(except, of course, that the cellphone guys will standardize shortly after hell freezes over).
And, of course, the term "Tivoization" didn't exactly spring from the aether...
Embedded platforms in general tend to be pretty scary for anyone who values software freedom(or for the "too cool to be ideological" crowd, even the ability to do an OS update after the manufacturer has stopped supporting a device). Some implementations are far more evil than others; but all it really takes to turn "install an new OS" into a "nontrivial hardware hack" kind of project is a bootloader that can verify digital signatures before loading a firmware image, which is a feature available almost across the board...
In this case, though, I'm honestly confused about why Motorola(or Verizon, who has the power of the purse in this case) would spend the engineering dollars on being extra evil. If you get one of these on contract, Verizon already has you by the balls legally, so they don't need to use technology to keep you from carrier switching, and I can't see Motorola having any more interest in exactly what OS I want to run than Dell does.
Is this a play to allow Verizon to give certain of their apps (and associated monthly fees) an unremovable hold on the handset? Are they worried about nefarious baseband hackers buying expensive smartphons and service plans(with actual financial details that have to be stolen, or could be used to identify them) and then h5xx0ring the network, rather than grabbing cheap phones off ebay, or spending just slightly more for a software defined radio that won't even need to be hacked? What's the point?
No matter how many times I tried to teach my creature how to inspire belief through classic "good cop/bad cop" techniques, he never learned how to set the villages children on fire, throw their burning bodies at the village, setting it on fire, and then put out the fire with magical rain.(since the villager AI model rewarded you with more belief for giving them things that they needed, you could get more belief per unit manna by hurting them, and then magically repairing some of the damage, than you could by just helping them twice. Totally fucked up; but actually seems to be a pretty accurate model, given how things like abusive relationships, hazing, and just about every major religion, actually work).
I think the basic problem is that the nature of the browser makes it pretty difficult to create permission sets that usefully control behavior.
In this case, for instance, the extension was explicitly stated to be(and, as I understand it, was) an extension for examining and modifying HTTP/HTTPS headers, including stuff like GET requests, and the like. Because it was malicious, it was, in addition to whatever modifications the user was making, also issuing a separate little request of its own, with the contents of form fields, to an IP controlled by the author.
You could, on a permissions basis, do things like segregate "extensions that modify browser chrome and only browser chrome" and prevent them from modifying pages at all, and you certainly can(and should) draw a line between "extensions that muck about with pages" and "Extensions that do stuff to the local filesystem"; but given that most of the useful extensions tend to muck around with webpages themselves, that introduces a very difficult security problem.
With conventional permissions setups, you are applying permissions to a set of objects(usually files; but can also be database values, APIs, etc.) that you created and thus know the sensitivity of. A webpage, though, is a collection of objects that some third party created. Unless you have some very clever ideas about how to parse a webpage and automatically categorize the "sensitivity" of various parts of it, it is virtually impossible to meaningfully assign a permissions structure to it. An extension rewrites a script on a webpage: is it making the user more secure(by preventing doubleclick from learning something)? is it making the user less secure(by diverting information to a malicious host)?
Fine grained permissions are a good thing; but you really can't create a useful permissions system(no matter how well designed and granular it may be), if you have no useful way of knowing how valuable the various resources to which you are allowing/denying/conditionally allowing access are. Since web browsers do most of their useful work on masses of objects provided by third parties(currently without any sort of value metadata, and even if there were an adopted standard for providing such, 3rd party value judgments still wouldn't be at all trustworthy.) it is a really hard problem to build a permissions model that is actually useful rather than merely strict.
Is there? Apple's review process doesn't demand source(and, given the review volume, there is Absolutely. No. Way they would be giving proper attention to detecting subtle malice, even if they did). The review process seems to be reasonably good at weeding out applications that crash horribly often enough that the reviewer will run into a crash, which blatantly violate the rules, which seem likely to be fodder for stories that will tarnish Apple's PR, or which "duplicate" some feature that exists or is on Apple's secret roadmap. It has also been rumored that they have some sort of static analysis tool to detect use of private APIs.
Nothing in that process would detect any but the most blatantly unsubtle malice(and, given that reviews tend to occur fairly quickly, something as simple as recording the date of first run, and not doing anything evil until 1 month has passed would probably count as "subtle" for the purposes of this exercise).
If malice is detected by a third party, or by some after-the-fact spot-check; both Apple and Android have practically identical capabilities to "unpublish and remove" an application from any device that hasn't been divorced from the mothership. For that matter, Mozilla can also issue FF updates that disable add-ons(as they did a while back for that MS.NET one, and as they have announced they will do here).
It is impossible to be sure, all sorts of surprisingly devious side channels have been devised(that, and some fairly dramatically invasive behavior by vendors has become accepted as normal; after all, only a freetard would object to an application phoning home routinely...); but for something like Opera, where "non-malicious" network activity is fairly easy to characterize, checking for malicious network activity is far from impossible, without even touching the binary(something like Skype, on the other hand, where the network activity is a big, fat, blackbox, is a lot trickier).
In this case, for instance, the malice was flagged by somebody watching network traffic, which is pretty trivial on any platform that doesn't have a bad case of being a console/iProduct. A purely binary, closed source, application could have been caught in exactly the same way.
Don't worry, the "undisclosed Microsoft technology" will allow him to whisper 'why won't you... Love ME?' into your ear just as you are on the verge of falling asleep...
They want to be sure that none of their next-gen hardware survives user-inflicted destruction long enough to RRoD.
Can you imagine being the poor bastard at Lionhead responsible for making sure that these "virtual humans" can exhibit realistic suffering responses to griefers, gropers, and every other ghastly atavism that the Kinect users of the world will allow to roam free when they know that there are no rules and no consequences?
(Incidentally, I bloody well hope that Lionhead has had some time to learn a thing or two since Black & White. The "AI" in that game managed to suck every ounce of joy out of being a malevolent deity, something that I wouldn't have believed possible.)
I suspect that the main factor is not the price premium associated with powerful laptops(which is much more modest than it used to be, though still nonzero); but the heat/weight/battery life penalty.
A screaming gamer laptop is actually pretty reasonably priced these days, and only a bit slower than the screaming gamer desktop. However, it is still hot, heavy, and loud, and doesn't get thrilling battery life.
The convenience would be being able to buy a thin-and-light with excellent battery life, that can become a screaming beast if plunked down within range of a supplemental card...
I have no idea whether it will go anywhere; but I'd assume that the one major strike in its favor is that, unlike wireless USB, wireless PCIe addresses use cases that basic boring ethernet/wifi do not.
The performance of early wireless USB hardware was pretty shit, and it was uncommon and ill standardized, so you usually still had to plug a dongle in, just to get performance worse than plugging in a cable. Plus, basic NAS/print server boxes had become really cheap and fairly easy to use. Anybody who wasn't a technophobe or living in a box(and thus not the target market for pricey and sometimes flakey wireless USB) already had his mass storage and printers shared over a network, wired or wireless, and his human interface devices wireless via bluetooth or proprietary RF, if he cared about that. Wireless USB didn't really enable any novel use cases that anybody cared about.
On the other hand, there is basically no way of plugging in "internal" expansion cards over a network(in the home context, I'm sure that some quite clever things have been done with I/O virtualization over infiniband, or whatever). Particularly with the rise of various "switchable graphics" technologies, I assume that the use case is basically this: User has nice thin, light, long-running laptop. They come home, sit within a dozen meters of a little box(containing a graphics card or two, with one head connected to their TV), and suddenly their laptop has a screaming gamer's graphics card supplementing the onboard card, either usable on the built-in screen, or via the second head connected to the TV, or both.(Analogs could be imagined for professional mobile workstation applications, where simply sitting near your desk connects you to a quartet of CUDA cards and an SAS controller with 4Us worth of drives hanging off it.
Will the market care, enough to bring the volume up and the price down? I have no idea. However, it at least has the advantage of allowing things not otherwise possible, unlike wireless USB, which pretty much covered the same ground as a mixture of bluetooth peripherals and resource sharing protocols over TCP/IP; but years later and without the standardization..
Slashdot Mirror
It could just be that those goddamn perky "morning people" are up bright and early and polluting the dataset while sensible humans are still asleep, or wishing that they were...
Wow. That is some incredible quality there.
I'm assuming that this product is of the "Well, it sucks ass; but at least it was incredibly expensive..." school of enterprise software design?
That would probably actually make them a good bit less dangerous...
At 1000 times normal size, they would still be small enough to be vulnerable to manual blunt trauma(and pulling their wings off just to watch them crawl around and suffer would be much easier); but they would also be large enough to be taken down with BBs at modest range, or "snake load" handgun rounds at close range.
People get so much less worked up about genetic engineering in bugs nobody likes...
On 64 bit installs, they generally pay attention to the "OS refusing to install the unsigned driver" behavior, though... Luckily, Realtek isn't behind a gigantic fraction of the world's cheap NICs, so getting updated drivers won't be an issue...
I suspect that internationally-exported American action movies strongly over-represent the role of the FBI in US policing...
At least, unlike HP and Creative, they have yet to master the art of making crappy drivers larger than entire operating systems of just a few years ago...
They may be pretty chintzy; but they are downright ubiquitous. Things are going to get comedic if every Realtek-equipped PC that also gets Windows updates suddenly starts throwing "unsigned driver" warnings because Microsoft revokes their trust of the Realtek signing key(which they might chicken out of; but they really should do if there are signed rootkit drivers floating around)...
I figured that it was slightly less blatant than "Bit-Bang, by DJ TAG"...
Oh, it's eminently possible, from the architectural perspective of assigning ACLS and default-denies to all kinds of things(heck, you could assign ACLs to every DOM element of every page you load, per-domain control over all kinds of things and so forth.) It might be a chore technologically; but that part is entirely doable.
What I'm saying is that, because it is extremely difficult to know what elements of an arbitrary 3rd party webpage are sensitive, and what elements aren't, attempting to apply a meaningful permissions scheme to extensions that modify web pages is difficult or impossible in practice(unless you are willing to accept amounts of permission confirmation windows that would make a hardened noscript user cry).
Control over local program execution, local filesystem access, and local GUI are all quite doable; because those all consist of easily knowable, and known, sets of objects.
The trouble, is with web pages:
"Permission to modify headers- which headers" Ok, this wouldn't be too bad for some site-specific anti-nuisance plugin(assuming the site's design doesn't change unexpectedly, and break the plugin, or change frequently and habituate the user to accepting any demand for changes a plugin makes); but it doesn't help you too much for site-generic plugins(like the security testing tool in TFA, whose features pretty much include "modify any header on any site, at the user's direction" and secretly included a silent added header.)
Worse, since a fair few pages, in our Web 2.0 age, do a lot of sending and receiving on their own behalf, much of it script driven. This would mean that, in effect, on many domains, permission to modify scripts would imply permission to communicate more or less arbitrarily, just by making the web page communicate for you.
The other problem, with something like a web page, is that the line between "content"(HTML) "style"(CSS), and "scripts"(JS) might be fairly bright programmatically, in terms of the visual result that the user ends up interacting with, it gets pretty fuzzy. Even assuming freedom from sanitization failures and injection attacks, a malicious program that can "just" manipulate the CSS can pull some pretty crazy stunts with a fair few web pages. Now, there is nothing stopping you from having privilege granularity going all the way down to individual CSS elements(or even relationships between elements, say to keep a malicious extension from hiding foreground text by making it the same color as the background); but that would mean that any user would have to be a reasonably serious web developer just to comprehend the permissions list, much less know what is dangerous and what isn't.
I suspect that, if you told Verizon that "Boot-tay loader" was actually the hottest new single from ludacris, rather than a low level firmware reflash, they would probably add it to the V-cast store for you...
Oh, it would definitely be a "nuclear option" sort of thing; but I suspect that it is the only strategy that would have any chance of causing them to reverse their stance.
Companies don't drop their DRM systems because they love freedom and fuzzy puppies, they drop them because the engineering costs and customer support issues are more expensive than the perceived benefits. Thus, if you oppose DRM systems, you can either lower the perceived benefits(by cracking the systems and distributing tools for doing so) or raise the costs. Boycotts are the legal and ethically unproblematic; but generally not that effective, way of doing this. More, er, direct methods of raising customer support costs are less legal and ethical; but probably a lot more effective...
That's actually pretty much even with other smartphones in its class. The trouble is, most carriers(at least in the US); subsidize handsets but don't offer less expensive plans to those who BYO hardware...
If there were a "zOMG Free Phone* *(with $$$$/month contract)" option and a "Pay full retail phone price, or bring your own, $$/month for voice/data" option, the American preference for crippled carrier phones would be an example of the "stupid consumers, only looking at upfront costs" phenomenon. As it is, though, you pretty much choose between getting a subsidized phone, then having the subsidy(and some extra) gouged out month by month, or you pay full price, and then face exactly the same monthly costs. This adds up to paying a fairly major premium to purchase your own device.
If one were of the risk-taking sort, the best way to oppose this sort of crap would probably be to disseminate a trojan app that trips this "efuse" system...
A few hacker nerds whining probably just makes Verizon smile. 10s of thousands of angry customers demanding replacement of their bricked phones, along with massive bad publicity would not.
I wonder how possible that would be.
I hope the sarcasm in my use of "freetard" was sufficiently evident. I find the fact that it is considered normal for all sorts of software to report more or less whatever they want back to the mothership, in exchange for another few days of "You are only a suspected; but not yet confirmed, pirate. You may continue to use our software." rather disturbing.
Were any "respectable" software to be operating maliciously, this would probably be the easiest way to exfiltrate captured data. Because the phoning home is to stymie the wicked pirates, you can rationalize it being encrypted, and thus avoid trivial detection by network sniffing.
Unless Mr. Fusion has come on the market by then, you'll probably be attaching a power cable in any case, so having a standardized combination of power cable/high density PCIe connector would presumably be even easier..(except, of course, that the cellphone guys will standardize shortly after hell freezes over).
And, of course, the term "Tivoization" didn't exactly spring from the aether...
Embedded platforms in general tend to be pretty scary for anyone who values software freedom(or for the "too cool to be ideological" crowd, even the ability to do an OS update after the manufacturer has stopped supporting a device). Some implementations are far more evil than others; but all it really takes to turn "install an new OS" into a "nontrivial hardware hack" kind of project is a bootloader that can verify digital signatures before loading a firmware image, which is a feature available almost across the board...
In this case, though, I'm honestly confused about why Motorola(or Verizon, who has the power of the purse in this case) would spend the engineering dollars on being extra evil. If you get one of these on contract, Verizon already has you by the balls legally, so they don't need to use technology to keep you from carrier switching, and I can't see Motorola having any more interest in exactly what OS I want to run than Dell does.
Is this a play to allow Verizon to give certain of their apps (and associated monthly fees) an unremovable hold on the handset? Are they worried about nefarious baseband hackers buying expensive smartphons and service plans(with actual financial details that have to be stolen, or could be used to identify them) and then h5xx0ring the network, rather than grabbing cheap phones off ebay, or spending just slightly more for a software defined radio that won't even need to be hacked? What's the point?
You lucky bastard.
No matter how many times I tried to teach my creature how to inspire belief through classic "good cop/bad cop" techniques, he never learned how to set the villages children on fire, throw their burning bodies at the village, setting it on fire, and then put out the fire with magical rain.(since the villager AI model rewarded you with more belief for giving them things that they needed, you could get more belief per unit manna by hurting them, and then magically repairing some of the damage, than you could by just helping them twice. Totally fucked up; but actually seems to be a pretty accurate model, given how things like abusive relationships, hazing, and just about every major religion, actually work).
I think the basic problem is that the nature of the browser makes it pretty difficult to create permission sets that usefully control behavior.
In this case, for instance, the extension was explicitly stated to be(and, as I understand it, was) an extension for examining and modifying HTTP/HTTPS headers, including stuff like GET requests, and the like. Because it was malicious, it was, in addition to whatever modifications the user was making, also issuing a separate little request of its own, with the contents of form fields, to an IP controlled by the author.
You could, on a permissions basis, do things like segregate "extensions that modify browser chrome and only browser chrome" and prevent them from modifying pages at all, and you certainly can(and should) draw a line between "extensions that muck about with pages" and "Extensions that do stuff to the local filesystem"; but given that most of the useful extensions tend to muck around with webpages themselves, that introduces a very difficult security problem.
With conventional permissions setups, you are applying permissions to a set of objects(usually files; but can also be database values, APIs, etc.) that you created and thus know the sensitivity of. A webpage, though, is a collection of objects that some third party created. Unless you have some very clever ideas about how to parse a webpage and automatically categorize the "sensitivity" of various parts of it, it is virtually impossible to meaningfully assign a permissions structure to it. An extension rewrites a script on a webpage: is it making the user more secure(by preventing doubleclick from learning something)? is it making the user less secure(by diverting information to a malicious host)?
Fine grained permissions are a good thing; but you really can't create a useful permissions system(no matter how well designed and granular it may be), if you have no useful way of knowing how valuable the various resources to which you are allowing/denying/conditionally allowing access are. Since web browsers do most of their useful work on masses of objects provided by third parties(currently without any sort of value metadata, and even if there were an adopted standard for providing such, 3rd party value judgments still wouldn't be at all trustworthy.) it is a really hard problem to build a permissions model that is actually useful rather than merely strict.
Is there? Apple's review process doesn't demand source(and, given the review volume, there is Absolutely. No. Way they would be giving proper attention to detecting subtle malice, even if they did). The review process seems to be reasonably good at weeding out applications that crash horribly often enough that the reviewer will run into a crash, which blatantly violate the rules, which seem likely to be fodder for stories that will tarnish Apple's PR, or which "duplicate" some feature that exists or is on Apple's secret roadmap. It has also been rumored that they have some sort of static analysis tool to detect use of private APIs.
.NET one, and as they have announced they will do here).
Nothing in that process would detect any but the most blatantly unsubtle malice(and, given that reviews tend to occur fairly quickly, something as simple as recording the date of first run, and not doing anything evil until 1 month has passed would probably count as "subtle" for the purposes of this exercise).
If malice is detected by a third party, or by some after-the-fact spot-check; both Apple and Android have practically identical capabilities to "unpublish and remove" an application from any device that hasn't been divorced from the mothership. For that matter, Mozilla can also issue FF updates that disable add-ons(as they did a while back for that MS
It is impossible to be sure, all sorts of surprisingly devious side channels have been devised(that, and some fairly dramatically invasive behavior by vendors has become accepted as normal; after all, only a freetard would object to an application phoning home routinely...); but for something like Opera, where "non-malicious" network activity is fairly easy to characterize, checking for malicious network activity is far from impossible, without even touching the binary(something like Skype, on the other hand, where the network activity is a big, fat, blackbox, is a lot trickier).
In this case, for instance, the malice was flagged by somebody watching network traffic, which is pretty trivial on any platform that doesn't have a bad case of being a console/iProduct. A purely binary, closed source, application could have been caught in exactly the same way.
Don't worry, the "undisclosed Microsoft technology" will allow him to whisper 'why won't you... Love ME?' into your ear just as you are on the verge of falling asleep...
They want to be sure that none of their next-gen hardware survives user-inflicted destruction long enough to RRoD.
Can you imagine being the poor bastard at Lionhead responsible for making sure that these "virtual humans" can exhibit realistic suffering responses to griefers, gropers, and every other ghastly atavism that the Kinect users of the world will allow to roam free when they know that there are no rules and no consequences?
(Incidentally, I bloody well hope that Lionhead has had some time to learn a thing or two since Black & White. The "AI" in that game managed to suck every ounce of joy out of being a malevolent deity, something that I wouldn't have believed possible.)
I suspect that the main factor is not the price premium associated with powerful laptops(which is much more modest than it used to be, though still nonzero); but the heat/weight/battery life penalty.
A screaming gamer laptop is actually pretty reasonably priced these days, and only a bit slower than the screaming gamer desktop. However, it is still hot, heavy, and loud, and doesn't get thrilling battery life.
The convenience would be being able to buy a thin-and-light with excellent battery life, that can become a screaming beast if plunked down within range of a supplemental card...
I have no idea whether it will go anywhere; but I'd assume that the one major strike in its favor is that, unlike wireless USB, wireless PCIe addresses use cases that basic boring ethernet/wifi do not.
The performance of early wireless USB hardware was pretty shit, and it was uncommon and ill standardized, so you usually still had to plug a dongle in, just to get performance worse than plugging in a cable. Plus, basic NAS/print server boxes had become really cheap and fairly easy to use. Anybody who wasn't a technophobe or living in a box(and thus not the target market for pricey and sometimes flakey wireless USB) already had his mass storage and printers shared over a network, wired or wireless, and his human interface devices wireless via bluetooth or proprietary RF, if he cared about that. Wireless USB didn't really enable any novel use cases that anybody cared about.
On the other hand, there is basically no way of plugging in "internal" expansion cards over a network(in the home context, I'm sure that some quite clever things have been done with I/O virtualization over infiniband, or whatever). Particularly with the rise of various "switchable graphics" technologies, I assume that the use case is basically this: User has nice thin, light, long-running laptop. They come home, sit within a dozen meters of a little box(containing a graphics card or two, with one head connected to their TV), and suddenly their laptop has a screaming gamer's graphics card supplementing the onboard card, either usable on the built-in screen, or via the second head connected to the TV, or both.(Analogs could be imagined for professional mobile workstation applications, where simply sitting near your desk connects you to a quartet of CUDA cards and an SAS controller with 4Us worth of drives hanging off it.
Will the market care, enough to bring the volume up and the price down? I have no idea. However, it at least has the advantage of allowing things not otherwise possible, unlike wireless USB, which pretty much covered the same ground as a mixture of bluetooth peripherals and resource sharing protocols over TCP/IP; but years later and without the standardization..