In principle I would agree, however, the idea of parking this nuanced distinction on the desk of a regulatory bureaucrat makes my neck hairs stand at attention.
While I'm admittedly not an expert in cryptography or trusted computing schemes in general, I don't see how this differs on a technical level from numerous other code-signing schemes with a central certificate authority (CA) (and its chain of delegations) blessing "good" code and revoking such blessings. Well known examples include Securicode / Windows Driver Signing, the anti-consumer bits of UEFI, etc. Can anyone shed some further light on how this is different?
As with other such systems, it assumes the existence of a benevolent authority that cannot be hacked, the cooperation of all packer vendors, the cooperation of all packer *users* (who are not malware authors)... and all packer users who *are* malware authors never hearing of it.
The only main difference I can see (and its potential downfall for its purpose) is that end-users don't pay for certificates. While that's great for end-users (driver signature enforcement in x64 Windows versions is pretty close to extortion IMO), this seems to break down for any packers that are not a licensed commercial product where an explicit, one-on-one packer-vendor to packer-user relationship exists. This excludes any freeware and open-source packers*, where any schmuck can just download and run it (and even modify it) without key exchanges or other communication with its author.
Conversely, if any old schmuck can obtain a fresh signature at any time ("it's free!"), what's to stop any old schmuck from doing exactly that? The stipulations that the system is free to both end-users and packer vendors, bankrolled entirely by A/V vendors out of the goodness of their hearts, suggests any background-checking that occurs as a condition of generating a signature can't be very exhaustive.
* While the IEEE materials refer to the proof-of-concept running on "a modified version of UPX", a well-known F/OSS packer, this almost certainly has to do with the ability to quickly bodge this feature in due to easy source code access, and very little to do with whether the actual author of UPX is complicit in or aware of the system, or whether this scenario can possibly work in the real-world for open-source packers with anonymous downloads.
Still does. I just bought, and then returned, a Moto X after discovering that Motorola's "unlock your bootloader" page is a sham. Tried it on a brand-new, retail, unlocked device and got "Your device does not qualify for bootloader unlocking" . The better part of an hour going round in circles with their tech support and they are unable (or unwilling) to even state the criteria that would, theoretically, make a device "qualify".
(An aside: While most companies might claim unlocking or rooting a device "could" void the warranty, it's usually with a wink and a nudge as long as the device is factory-restored before RMA'ing or at least not obviously bricked. A couple have software tamper flags that can likewise be reset. Motorola, on the other hand, uses the device serial # to generate and return - by email - a bootloader unlock code, and immediately blacklists the device for warranty service the moment they do so, whether you actually use the code or not.)
Hackaday had a similar discussion just over a month ago. The consensus there seems to be likewise that it is probably a scam. (Or *extremely* optimistic kid who has seen a few of the technologies involved work on paper. But more likely a scam.)
Heh. For our military this seems very counterintuitive. AFAICT the push in recent years has been toward anything that reduces unnecessary cognitive loading in heated situations, and frees up their tactical senses (eyes & ears) generally. At my day-job a recent project was a tactile display vest specifically to replace voice and hand-arm signaling, keeping soldiers' eyes and ears free for other matters. Basically a dense array of vibrotactile drivers (like what makes your phone buzz) that can display messages on the skin, which is basically "unused bandwidth" thus far. Blocking vision with AR, and in a very obvious way, seems counter to this trend.
I'm not remotely interested in Chrome, but I want to see what's in store for Firefox about 2 releases from now.
Another popular option is to route prank calls through a Deaf relay service (TTY). Whatever you type, the operator HAS to repeat it to the called party. This gets around voice identification - even more relevant if the callee is someone who knows you or you pull this shit regularly.
A friend discovered a new employee at his work was doing this, and got his cell # somehow. We had lots of fun with him.
Also: TFA verbed 'onboard'.
It looks like there is only one extremely narrow independent claim (calling out a specific ISO and lens) - claim 1 - but it's a red herring. The real meat of it is Claim 2, which is much more broad and from which every subsequent claim through Claim 24 derives. Claim 25, the only remaining independent claim, is also much more broad.
Indeed, sounds like a non-compete-clause type of snit... the old "you can't work in the field you work in because you learned lots of stuff while working for us".
All (valid) complaints about the continuing dumbing-down of the interface aside, have they fixed the FF28 behavior where opening a new tab/window gets progressively slower with use, until after a few days of use, opening one freezes FF and pegs the CPU for upwards of 20 seconds before it appears? (Or just crashes.)
Closing and re-opening FF resets the molasses clock, but that's a poor substitute for just working correctly in the first place.
Indeed. Specifically, they are taking the approach already found by at least one previous court decision to be lawful. The one off the top of my head is Cartoon Network vs. Cablevision; digging up the actual decision will reveal a goldmine of related cases and the nuances (at least to the 2nd Circuit) of how the ugly "rented, remotely hosted DVR, separate redundant copies per user" technical workaround differs from more logical approaches. IIRC the Cablevision decision as to whether transmitting video from a remote-rented DVR was a public performance or other infringing use hinged on whether it was the cable co or the customer that "pressed the button" that initiated the recording (copy).
Ha ha, apparently proselytizing about the "Internet of Things" is trendy again. Don't hold your breath kids; until IPv6 is a thing that's really a thing, enjoy your "small home network of things", where your game console, thermostat and toaster have 192.168.x.x IP addresses dangling from your cablemodem, and require a 3rd-party cloud service to mediate contact with your neighbor's toaster.
Seriously though... if anybody but major datamining companies are going to get remotely enthusiastic about this IoT shenanigans, two things need to happen: IPv6 and dirt-cheap low-bandwidth wireless uplinks (think cellphone plan with pay-by-the-byte or 512kb/month dataplans and low/no monthly maintenance fees) so that all the applications (smart stoplights, weather/pollution sensors, whatever) that would benefit from not dangling off someone's cell plan or cablemodem don't have to do so. Maybe on the 3rd revival of the IoT hype, about 10 years from now, it'll really catch on and be actually kind of useful. (See also: "M2M".)
The 'threats of violence' thing appears to be a naive misunderstanding of German, if not an intentionally sensationalist one: have a look at the comment by user "Required" following the article, which explains the original German idiom.
The actual "curbstone" quote in question is:
"Ein geistiger Tiefflieger, er soll aufpassen, dass er nicht mit dem Kinn am Bor[d]stein hÃngen bleibt."
It's not a threat to curbstomp anyone, but a colorful insult that loosely translates as "someone with such a low-flying intellect, they have to watch out for curbstones lest they hit their chin on one". Indeed, Google auto-translates it as:
"A spiritual low-flying aircraft, he should be careful that he does not hang with the chin on the curb."
There are definitely some interesting ideas mentioned in the 1996 patent (e.g. tying playback stats back to a billing system; voice commanded playback), but much of it sounds similar to the systems commercial radio stations used at the time to schedule programming and handle royalties. But the patent claims are written so broadly as to cover just about anything. For example, Claim 1 could easily encompass a playlist feature in any audio program. I can't imagine there wasn't a single audio program in 1996 with playlists. In fact, this claim would appear to cover plain Audio CDs, which have been around since the mid 70s and include just such a "playlist" (TOC data) at the beginning of each disc, with the player providing the customary play/next/stop/repeat controls. The CD-changer I had in the early 90s allowed programming an arbitrary playback order as well. Interestingly, the more advanced CD-Text specification, which includes human-readable track listings and other metadata in the TOC, was officially released a month before the priority date of the patent.