Live data from Hacker News

All of Oculus’s Rift headsets have stopped working due to an expired certificate

techcrunch.com

181–190 of 390 posts

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#181
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

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#182
post #148

Earlier quoted context omitted.

TLS certificate expiration tells your browser to stop downloading new pages from that site. It doesn't tell your browser to close the page that's already been rendered and is still on-screen.

But you are making new requests to the Oculus api and that part is failing. You wouldn't expect the ajax requests to continue to work just because you left your browser open for years.

It's more like you had your browser tab open, the certificate expired and now the page is completely and totally unresponsive and the browser has killed all javascript running on it.

It also won't let you refresh the page or close it since the certificate is expired.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#183

Earlier quoted context omitted.

Microsoft's driver signing model has a mode that is a giant footgun with no redeeming value. Oculus is a victim of Microsoft's bad design. They weren't trying to build in a self-destruct timer for their whole product stack, and if they were, they wouldn't have used the driver signing certificate as the lynchpin.

you can't guard against every imaginable stupidity. you try but users will inevitably find a hole.

That's not how APIs work. You don't eliminate stupidity by thinking of each and every way the user could screw up. You simplify your API so there aren't so many ways to use it in the first place.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#184

Earlier quoted context omitted.

It needs to exist in an untrusted environment.. it verifies that the driver which has low level access to the computer hasn't been modified by a third party.. MS signed system binaries are the same way; it's a safeguard against malicious entities.

I'm not arguing against the entire concept of driver signing, just one specific nuance of Microsoft's driver trust model. There is a place for driver signing and signature checking, but de-trusting a driver that you were perfectly happy to give kernel-level access yesterday doesn't make sense.

It's still Oculus fault because they didn't use a timestamped signature.

A timestamped signature on the binary would have it kept working and that's how MS intents it to work. You can leave it out if you have the desperate longing for having your software break suddenly without reason like Oculus just did.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#185

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.…

Imagine how terrible it would be for your customers once that happened in the production....

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#186

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…

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…

Cairo is currently desperately asking for development help, so uhh... https://people.gnome.org/~federico/blog/helping-cairo.html

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#187
post #185

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.…

Imagine how terrible it would be for your customers once that happened in the production....

He said it's a surgical training startup so I think it would have been fairly okay.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#188
post #185

Earlier quoted context omitted.

Imagine how terrible it would be for your customers once that happened in the production....

He said it's a surgical training startup so I think it would have been fairly okay.

Those things aren't cheap for simulators, either - not to mention knock-on costs. "What do you mean - I got the doctors in, which alone took a month of herding cats, and now it won't work, just because?"

How low has the SW development bar gone, if "it's okay" now means "at least it's not directly killing people"?

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#189
post #184

Earlier quoted context omitted.

I'm not arguing against the entire concept of driver signing, just one specific nuance of Microsoft's driver trust model. There is a place for driver signing and signature checking, but de-trusting a driver that you were perfectly happy to give kernel-level access yesterday doesn't make sense.

It's still Oculus fault because they didn't use a timestamped signature. A timestamped signature on the binary would have it kept working and that's how MS intents it to work. You can leave it out if you have the desperate longing for having your software break suddenly without reason like Oculus just did.

And that's where MS is at fault: drivers without timestamped signatures should be treated as faulty. This would prevent these errors in the first place.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#190

Earlier quoted context omitted.

There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these r…

Really? No reason whatsoever? I'm not being facetious, FWIW. I know a fair amount about PKI, in general (probably in more depth and intricate detail than the average HN'er, actually), but I'm not a developer and I know very little about code signing in particular (and even less when it comes to the Microsoft world of code signing). I do find it kinda hard to believe that there's no use case whatsoever for this partic…

> but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.

I can readily imagine a scenario where a driver with a signature but no separately attested timestamp should be acceptable. What I cannot imagine is a scenario where it is useful to treat a driver signed in such manner the way Windows currently treats the driver.

Post reply on HN