Our VR surgical training startup has been working for the last few months towards a big medical conference this week where we're showing multiple training procedures for multiple customers on Oculus Rift, as well as having our own booth. The headsets all stopped working the morning of the conference.
Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days. This could have been a huge disaster for our company if we hadn't found that workaround though. Pretty annoyed with Oculus about this
This does not bode well for real VR surgery. Imagine if this were surgery day for someone, and because of an expiring certificate the rift shuts down ...
Wow! I'm glad you were able to get it figured out. Sounds like a nightmare scenario.
By the way, do you have any links to your surgical training startup? I'm doing some research into VR/AR for surgical telementoring and training and would be interested in seeing how it's in use.
Why are you basing medical appliance on such a walled-garden technology you aren't in control of, while there are more accessible alternatives? Oculus was already known for locking up fiascos, this really shouldn't be a surprise for you.
Hardly original, kids have been using this to extend the trial periods of shareware since forever. Most Rift users have been using RunAsDate which hooks the kernel's time APIs.
This is not how Windows code signing is supposed to work. Normally you'd get a countersignature from a timestamp server so that the verification process can prove that the certificate was valid at the time of signing. It would appear that Oculus signed their binaries without using a timestamp server, so without a way to verify when signing happened they become invalid as soon as the cert expires.
Something like that. Certificates aren't supposed to stop working just because they've expired! That would destroy all abandoned or poorly maintained software within a couple of years.
This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.
I don't see enough info in the article to conclude what happened. But I have a hypothesis.
I bet they use certificate pinning.
Process A launches process B and checks against a pinned certificate. This is even more secure than just using the windows code signing stuff.
Problem is, when their cert expired, they were supposed to renew the same cert. Instead, somebody got a new one and signed the build of process B.
The device automatically downloads process B, but then the certificate pin check fails when it tries to launch it.
All the security guides that tell you to do certificate pinning need flashing neon signs explaining this problem. You can't pin certs if you intend to ever change certs.
According to one thing I read (which I will admit was third party comments) there was a countersignature present up until version 1.22 and then in 1.23 it disappeared. I am not familiar with Oculus' binaries though so I don't know how far back that would be.
The Windows signature tool, signtool.exe, makes the timestamp an optional parameter. There are no warnings if you don't supply it. I'd suggest this is a poor design--do most signatures not want the timestamp by default?
One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware design, optics, display technology, manufacturing, user interface design, etc etc. Also, they apparently needed expertise in managing the ins-and-outs of the Windows driver security system. Adding one more subject to their already crowded curriculum wasn't very nice of Microsoft.
A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.
I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up."
When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something and two of them are not recommended OOTB. Or is primarily documented by third parties.
This one will hopefully be solved quick by the company, but think of what would have happened if this was a piece of technology sold in hundreds thousands pieces by a company now out of business: instant tons of electronic junk that would be instead perfectly useable if there was a law mandating all software/hardware details to be released if either of these conditions are met: IP owner going out of business, company declaring the product obsolete and stopping any technical support or upgrade, product sales plummeting due to competing or new models. The first two are obvious while the third one would allow some of the devices to be repurposed instead of thrown away.
I've saved a good number of old access points / routers from the landfill by installing OpenWRT/Lede where possible o their latest available firmware,pairing them together, adding homemade external antennas (small Wifi antenna enclosed in white PVC pipe plus self bonding tape, silicone sealant and heatshrink, RF240 cable and RP/SMA or N connector: => years exposed to sun, rain and snow with zero problems). I install them at really low prices to customers who need a cheap wifi bridge from point A to B. I would love to do a similar "afterlife" service to old cellphones, but none of them could host a true native Linux install because of how tightly closed the underlying hardware is, and all of them sooner than later are doomed to be thrown away.
The problem lays in the IP. It's considered to be a vital asset so that when a company goes belly up it will survive kept years or decades in a safe by law firms in the hope someone will buy it, or just to make profits through litigation against infringers. Unfortunately this has a deleterious effect on products derived from that IP, the people who bought them and the people living where the unusable products will be trashed.
They let their certificate expire, essentially bricking all of their devices. And now the app running it won't start, so they can't push an update.
Just recently picked up a Rift. I love the hardware and their exclusives are top notch, but this confirms my suspicions that their backend is super goofy.
They sell Rifts at Best Buy and want to pretend that it's a consumer-ready product, but here's why I am recommending people stay away for now:
- Non-existant repair or service out of Warranty.
- Basic things in the platform like changing your name or photo don't exist.
- Lots of non-response over other basic features requested by the community.
- Questionable future investment in the platform or hardware. It sounds like they are moving their efforts towards "lighter" experiences.
In short, it feels like being a legacy customer for a new product.
I see the exclusives as a negative. I don't want to support their efforts to build a closed ecosystem around what should be an open API that any headmounted display + tracking can expose.
< They let their certificate expire, essentially bricking all of their devices.
This also suggests that if the decide they stop supporting it, eventually the software will stop working due to these certificate errors for which will then there be no fix.
Call me when it's a wireless & self-contained unit. Until then, I just cannot honestly see it taking off in the commercial space. Industrial & enterprise-ish use maybe, but to regular consumers hell no. It's still a mess of wires and sensor installation, not to mention you still need that high-end gaming PC (and with the prices of GPUs being what they are it's a no-go for the vast majority of people).
I feel like kicking out the actual founder of the company may have been a bad idea. Politics or whatever, I get it, but it doesn't feel like there's a vision guiding what VR is supposed to become.
> - Non-existant repair or service out of Warranty.
That.
My Rift is scratched since first use (I swear it came scratched) and I've never been able to have them acknowledge that the device can be scratched into a blurry mess. "Oh, that's only regular use wear and tear" ...
Lens cannot be replaced or repaired (and they could during rift dk1 era).
It's more complex than a display; it's a display plus a collection of USB sensors and some low-level hooks into display management. This requires kernel-mode drivers, for good technical reasons, where a normal monitor wouldn't.
This kind of stuff worries me as well. Security experts generally don't seem to give a fuck about things being unusable due to security systems "Working as Designed". It just doesn't factor into their analysis. As long systems are not "compromised" in some narrowly defined sense, everything is considered fine.
Generally this attitude doesn't backfire, because individual users loosing access to their data, their accounts or their software can be simply dismissed. But in this case it happened to everyone at once, so it's suddenly a big deal.
Saw this, opened Oculus Home, there's a message in the Updates tab saying "An update may not have installed correctly", and indeed, VR apps didn't work.
Nate Mitchell of Oculus posted on Reddit saying "We're working on resolving this issue right now. We'll keep everyone posted on progress here." https://www.reddit.com/r/oculus/comments/82nuzi/cant_reach_o... . Top-level of that thread has a workaround involving setting the clock back or using a utility called RunAsDate to fake the clock for a single application.
What a horrible design decision. Instead of making a system that simply works or doesn't work Microsoft allowed everyone to produce apps which break at random times in the future. It's one of those "what could possibly go wrong?" cases.
This, and many incidents like it, makes me think that running tests 1/10/100 years in the future should be a standard feature of test runners and CI systems. (on by default)
I work with time a lot and have always advocated running practical simulations, especially over year changes, leap year changes, leap year days, etc. with the junior engineer I mentor as well as the hardware company that partners with us -- it's only recently after we got bitten by a time-based bug that people have started listening.
The kicker of course is that if you set the date to something in the future you may have a pile of other services fail before your code is run — Basically any /other/ services that happen over TLS may fail (correctly as their certs have expired ;) ).
I had a bunch of tests fail at the start of this year because someone had hard coded 2017 into the tests.
Fortunately it was a problem with the tests, rather than the code itself, but these things do happen.
At my old job, we had a bunch of tests fail when daylight saving ticked over. For some reason, some things were using local time, rather than UTC. We also had a test that would fail if the minute was the same as the hour.
I borrow the office Rift every couple of months to play around for a weekend and see how the field is progressing. Unfortunately what I've mostly seen is a bunch of regressions, technical and ux, as they update their platform.
The new home 2.0 and especially Dash are leaps and bounds above what home was like before I think. You do have to enable it (still beta) but I think it'll be really nice once it's finally released.
It sounds like the same expired certificate is also used to sign their autoupdater's exe, so they can't just roll out an update using a new certificate.
I'm -constantly- seeing 'certificate expired' in my browser. This certificate stuff is so hard that they can't pay some Chief Certificate Officer $15/hr. to -do nothing else- but assure that stuff is renewed in a timely fashion?
We furry 'self-reproducing' (YMMV) mammals are simply not ready for all of this.
This seems to be a somewhat common type of problem. I wonder if companies should routinely test on machines with the clock set one year into the future to catch them before they hit customers.
I think you'd run into other problems then, for example if your test machine needs to communicate with https sites powered by letsencrypt, all those sites will appear to use certs that "expired" at least 9 months ago.
It’s not even necessary to test. Once you’ve done it a few times codesigning is a piece of cake. But there a few flags you absolutely pay attention to or else it’s going to bite you in the ass way down the line.
Has anyone got a good way of managing certificates in the wild? With no real management and staff turnover I've seen a bunch of expired certificate problems.
EDIT: presumably you need your client apps/libraries in the field write back when they use a cert that is <X months away from expiry.
I'd say someone very high up and "tied to the company", probably the CTO, should make sure a signing certificate is renewed when needed and make sure it's rotated every time it's about to hit expiration. For a company as big as oculus with the backing of Facebook, this is a pretty big issue.
I use simple Nagios checks for keeping an eye on certificate expiration. It's simple to set up checks for new hosts/services and I have them set to trigger an e-mail alert 30 days before expiration (20 days for certificates from Let's Encrypt). It does the job; I have yet to wake up one day to an expired certificate.
Apparently, this ("send me an e-mail before my certificate expires") is also the sole reason some companies even exist (i.e., it is their only product/service). It amazes me that this is something folks will pay for.
Rotation due to expired keys should be frequent, enough to pretty much require automated methods to handle the changes. (One of the many great things in LetsEncrypt.)
If it’s a much longer time scale, people start to forget that it’s even possible for stuff to expire.
If my fridge filter can display a little reminder light on a timer every few months, cryptography-dependent devices might need something similar. That way, your customers could know in advance and be asking you for an update.
In 2091, an overworked developer will accidentally let the certificate expire for the Planetary Shield Defense Matrix, and the Zylorts will finally conquer Earth.
OK. The issue arose because the expired certificate wasn't countersigned by a timestamp server.
So many comments agree that (a) security is hard, (b) countersigning with a timestamp server is easy to miss, (c) countersigning makes build processes difficult, and (d) they've done or seen similar things in other apps/companies.
This sounds like a classic UI/UX issue for developers around a literally mandated and mission-critical requirement of the OS.
At the least, MS should provide a validation tool to surface errors or risks before production. Better, signtool.exe should make omissions (like a timeserver) very difficult and make them an override, not a default. Best, they would do both.
I don't agree that the OS should reject non-timestamped signatures as faulty per se (and throw an error), as that puts the burden on the user to understand a developer's mistake. Sometimes running without a timestamp may be desirable - ultimately that's the dev's choice.
It's not phoning home (or at least if it is that's not the issue here). The cert used to sign the actual binaries expired, and Oculus signed the binaries in a half-assed fashion that tells windows not to run the code with an expired cert-- what they should have done is timestamped[0] when the signature was created. Since the binaries were signed before the cert expired, nothing should've broken. This is one of those cases that required a perfect storm of multiple mistakes/oversights.
So you're saying Rifts and Windows 10 drivers do not work offline? That basically Windows 10 will be functional only while Microsoft keeps the update servers on?
Edit: I don't follow Windows, I'm really curious what the consequences for stuff like this can be generally.
No. The certificate in question is a code signing certificate, not a TLS certificate. Oculus incorrectly used an expiring certificate instead of a timestamped certificate here; if timestamped certificate was used, then the Rift driver would work offline forever.
Oculus says you will receive $15 store credit if you used Oculus between Feb 1st and when it went kaput.
I don't see credit on my Oculus account? Am I supposed to have received it already? Or is this maybe because I don't have payment method added to my account?
At the core of the issue, yeah, they just need to publish the same driver with a different signature.
It looks like their auto-updater used the same cert though, so they can't distribute it as a normal update. They're probably figuring out the least sketchy/most automated way to distribute it right now.
When this is all said and done, there will be a handful of people who will never, ever forget to use the /t flag in signtool.
Something similar just happened to me. I have a windows computer I only Use for gaming. After the last update My Samsung display is no longer usable. It has a polarized effect now only when using the windows Computer. However the Computer Works fine Connected to another brand monitor. So much money, yet windows still sucks when it comes to most basic things
It seems like the commenters here are still shrugging it off. At least facebook and the oculus division are still around to fix the issue, imagine if this was a company that was now defunct, which could easily have been oculus if facebook hadn't purchased them. You're hardware would now be bricked and you would have no recourse because no one is left to create a new certificate. Or imagine if the occulus 2 was out and they decided that they no longer wish to support the old one, this is the ultimate vehicle of planned obsolescence.
It's not just people shrugging it off, many are defending this as being a perfectly fine state of affairs.
Beside the fact that you should be concerned about whether the controlling company goes out of business, or sells your data, here stands yet another reason to never trust devices that require an internet connection to activate in the first place, or phone home periodically to remain active.
This includes phones, cars, self-driving cars, watches, farm equipment, computing devices and anything marketed as an IoT appliance.
One glitch, as minor as an improper system time, and you’re dead in the water.
The problem here is that kernel drivers have to be signed and drivers will stop working if the signature expires because the vendor didn't use a time stamp server during the signing process. The drivers were clearly indended to keep working so I assume this happened by accident.
The big question is why on earth can drivers that have been verified and are already installed in your system can suddenly stop working? If this mechanism is intended to protect against malware disguised as drivers then it's already too late. The malware had several years to exploit your system.
Expiration after installation simply doesn't make sense for code signing. The signed executable won't change unlike a website. The driver is always going to have the same file hash, forever.
Some comments were deferred for faster rendering.
mattnewport|8 years ago
Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days. This could have been a huge disaster for our company if we hadn't found that workaround though. Pretty annoyed with Oculus about this
barkingcat|8 years ago
tudorw|8 years ago
fijal|8 years ago
DanAndersen|8 years ago
By the way, do you have any links to your surgical training startup? I'm doing some research into VR/AR for surgical telementoring and training and would be interested in seeing how it's in use.
seba_dos1|8 years ago
retox|8 years ago
The real MVP of this story. Sometimes a dirty hack is good enough.
borispavlovic|8 years ago
AboutTheWhisles|8 years ago
corndoge|8 years ago
r1ch|8 years ago
lopmotr|8 years ago
This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.
Someone1234|8 years ago
https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
zzbzq|8 years ago
I bet they use certificate pinning.
Process A launches process B and checks against a pinned certificate. This is even more secure than just using the windows code signing stuff.
Problem is, when their cert expired, they were supposed to renew the same cert. Instead, somebody got a new one and signed the build of process B.
The device automatically downloads process B, but then the certificate pin check fails when it tries to launch it.
All the security guides that tell you to do certificate pinning need flashing neon signs explaining this problem. You can't pin certs if you intend to ever change certs.
51Cards|8 years ago
jasonlotito|8 years ago
dockd|8 years ago
midnitewarrior|8 years ago
maxander|8 years ago
A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.
majewsky|8 years ago
I think we're waaaay past the "wondering" part.
andrewmcwatters|8 years ago
When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something and two of them are not recommended OOTB. Or is primarily documented by third parties.
squarefoot|8 years ago
The problem lays in the IP. It's considered to be a vital asset so that when a company goes belly up it will survive kept years or decades in a safe by law firms in the hope someone will buy it, or just to make profits through litigation against infringers. Unfortunately this has a deleterious effect on products derived from that IP, the people who bought them and the people living where the unusable products will be trashed.
legitster|8 years ago
Just recently picked up a Rift. I love the hardware and their exclusives are top notch, but this confirms my suspicions that their backend is super goofy.
They sell Rifts at Best Buy and want to pretend that it's a consumer-ready product, but here's why I am recommending people stay away for now:
- Non-existant repair or service out of Warranty.
- Basic things in the platform like changing your name or photo don't exist.
- Lots of non-response over other basic features requested by the community.
- Questionable future investment in the platform or hardware. It sounds like they are moving their efforts towards "lighter" experiences.
In short, it feels like being a legacy customer for a new product.
p1necone|8 years ago
sebazzz|8 years ago
This also suggests that if the decide they stop supporting it, eventually the software will stop working due to these certificate errors for which will then there be no fix.
stryk|8 years ago
whywhywhywhy|8 years ago
It's not bricked, bricking means it's as useful as a brick as in the actual firmware is corrupted beyond repair.
omg_ketchup|8 years ago
Gargoyle|8 years ago
But meanwhile my 10 year old nephew is having life shaping experiences with the Rift I set up for him.
driverdan|8 years ago
- Owned by Facebook, who will use it to gather as much data about you as they can.
Raphmedia|8 years ago
That.
My Rift is scratched since first use (I swear it came scratched) and I've never been able to have them acknowledge that the device can be scratched into a blurry mess. "Oh, that's only regular use wear and tear" ...
Lens cannot be replaced or repaired (and they could during rift dk1 era).
dmix|8 years ago
Can you explain what this means in practice? I'm not super familiar with Rift but I'm curious.
StavrosK|8 years ago
jimrandomh|8 years ago
ThatPlayer|8 years ago
booleandilemma|8 years ago
nerpderp83|8 years ago
Kenji|8 years ago
That's not the future. That's the present! Which is even more worrying.
gambler|8 years ago
Generally this attitude doesn't backfire, because individual users loosing access to their data, their accounts or their software can be simply dismissed. But in this case it happened to everyone at once, so it's suddenly a big deal.
aphextron|8 years ago
Because Mark Zuckerberg said so, that’s why.
Kikawala|8 years ago
hughes|8 years ago
jimrandomh|8 years ago
Nate Mitchell of Oculus posted on Reddit saying "We're working on resolving this issue right now. We'll keep everyone posted on progress here." https://www.reddit.com/r/oculus/comments/82nuzi/cant_reach_o... . Top-level of that thread has a workaround involving setting the clock back or using a utility called RunAsDate to fake the clock for a single application.
unknown|8 years ago
[deleted]
lunch|8 years ago
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
gambler|8 years ago
scrollaway|8 years ago
sdrothrock|8 years ago
olliej|8 years ago
toomanybeersies|8 years ago
Fortunately it was a problem with the tests, rather than the code itself, but these things do happen.
At my old job, we had a bunch of tests fail when daylight saving ticked over. For some reason, some things were using local time, rather than UTC. We also had a test that would fail if the minute was the same as the hour.
Time is hard
m_fayer|8 years ago
yobrien|8 years ago
FrantaH|8 years ago
Rebelgecko|8 years ago
8bitsrule|8 years ago
We furry 'self-reproducing' (YMMV) mammals are simply not ready for all of this.
draw_down|8 years ago
mikeash|8 years ago
0x0|8 years ago
yardie|8 years ago
retromario|8 years ago
Grollicus|8 years ago
> If your antivirus software restricts the file from opening, temporarily disable your AV and continue.
Good Patch Procedure, 2018.
Angostura|8 years ago
Please, please don't say: "Our teams apologize for any inconvenience this may be causing you"
instead opt for "Our teams apologize for any inconvenience this caused you"
boobsbr|8 years ago
draw_down|8 years ago
[deleted]
rb808|8 years ago
EDIT: presumably you need your client apps/libraries in the field write back when they use a cert that is <X months away from expiry.
judge2020|8 years ago
jlgaddis|8 years ago
I use simple Nagios checks for keeping an eye on certificate expiration. It's simple to set up checks for new hosts/services and I have them set to trigger an e-mail alert 30 days before expiration (20 days for certificates from Let's Encrypt). It does the job; I have yet to wake up one day to an expired certificate.
Apparently, this ("send me an e-mail before my certificate expires") is also the sole reason some companies even exist (i.e., it is their only product/service). It amazes me that this is something folks will pay for.
ahelwer|8 years ago
(disclaimer: work for Azure, but not on Key Vault)
draw_down|8 years ago
[deleted]
makecheck|8 years ago
If it’s a much longer time scale, people start to forget that it’s even possible for stuff to expire.
If my fridge filter can display a little reminder light on a timer every few months, cryptography-dependent devices might need something similar. That way, your customers could know in advance and be asking you for an update.
khazhoux|8 years ago
Natsu|8 years ago
smaili|8 years ago
jest3r1|8 years ago
dpflan|8 years ago
milhous|8 years ago
mancerayder|8 years ago
Edmond|8 years ago
agar|8 years ago
So many comments agree that (a) security is hard, (b) countersigning with a timestamp server is easy to miss, (c) countersigning makes build processes difficult, and (d) they've done or seen similar things in other apps/companies.
This sounds like a classic UI/UX issue for developers around a literally mandated and mission-critical requirement of the OS.
At the least, MS should provide a validation tool to surface errors or risks before production. Better, signtool.exe should make omissions (like a timeserver) very difficult and make them an override, not a default. Best, they would do both.
I don't agree that the OS should reject non-timestamped signatures as faulty per se (and throw an error), as that puts the burden on the user to understand a developer's mistake. Sometimes running without a timestamp may be desirable - ultimately that's the dev's choice.
It should just be a choice made explicitly.
navium|8 years ago
AHTERIX5000|8 years ago
Rebelgecko|8 years ago
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
na85|8 years ago
juanmirocks|8 years ago
However, this affected only one single customer of ours and we had a fix within a couple of hours. -- I certainly learn from this mistake.
logicuce|8 years ago
dharmab|8 years ago
toomasr|8 years ago
I thinks IT is used to managing HTTPS certificates, domain name auto-renewals but app level certs are more of a new thing.
nottorp|8 years ago
Edit: I don't follow Windows, I'm really curious what the consequences for stuff like this can be generally.
dharmab|8 years ago
sneak|8 years ago
Piskvorrr|8 years ago
rixrax|8 years ago
I don't see credit on my Oculus account? Am I supposed to have received it already? Or is this maybe because I don't have payment method added to my account?
boojums|8 years ago
acd|8 years ago
Robotbeat|8 years ago
kakarot|8 years ago
robmaister|8 years ago
It looks like their auto-updater used the same cert though, so they can't distribute it as a normal update. They're probably figuring out the least sketchy/most automated way to distribute it right now.
When this is all said and done, there will be a handful of people who will never, ever forget to use the /t flag in signtool.
melvinmt|8 years ago
gruez|8 years ago
theonewhocanfly|8 years ago
bakli|8 years ago
[deleted]
detaro|8 years ago
crowbahr|8 years ago
1. Automated the certificate process to auto-renew at least a year before expiry.
2. Have counter-signatures
3. Have anyone at all use any sort of calendar system to just check in on it to be sure.
But I guess being one of the largest tech companies on earth doesn't mean you don't have massive oversights.
intoro|8 years ago
taspeotis|8 years ago
[1] http://www.brucebnews.com/2017/11/look-at-the-red-flowers-wi...
aiecompany12|8 years ago
[deleted]
peterwwillis|8 years ago
flukus|8 years ago
It's not just people shrugging it off, many are defending this as being a perfectly fine state of affairs.
unmole|8 years ago
tritium|8 years ago
This includes phones, cars, self-driving cars, watches, farm equipment, computing devices and anything marketed as an IoT appliance.
One glitch, as minor as an improper system time, and you’re dead in the water.
imtringued|8 years ago
The big question is why on earth can drivers that have been verified and are already installed in your system can suddenly stop working? If this mechanism is intended to protect against malware disguised as drivers then it's already too late. The malware had several years to exploit your system.
Expiration after installation simply doesn't make sense for code signing. The signed executable won't change unlike a website. The driver is always going to have the same file hash, forever.