3 ms·
How could this even possibly be mitigated, though? At some point you have to trust something, right? This argument could extend all the way down to your OS, chi
by joekrill 8y ago
How could this even possibly be mitigated, though? At some point you have to trust something, right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.
- NewEntryHN 8y agoTrusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.
- fro0116 8y agoFor this use case, authenticating is a one-time effort as well, per browser. If you're authenticating again, you're almost certainly doing it on a different device/browser, at which point you'd have to verify the new browser binary anyways.
- eadmund 8y agoSign-ins to Firefox Accounts (used to access Mozilla services as web pages) don’t expire after some time? I didn’t know that.
- Faark 8y agoEven one-time, comparing the hash of a git commit or an installer is annoying but practically doable. I'd have no idea how to safely do something like this for a website. And I for sure ain't able to audit those ~200kb js by myself.
- IshKebab 8y agoSo you never update Firefox? For most users it automatically updates itself.
- joekrill 8y agoBut my point is you also have to trust that your underlying OS, or chipset, or even some other software on your computer doesn't have some way to thwart the entire effort. If the thing you're using the do your verification is itself compromised, then you're just as screwed.
- raffomania 8y agoIf you include this code in firefox itself, you can review the code and verify that the official firefox binaries use that code.
- joekrill 8y agoBut what about the code you run to verify the binaries? You have to trust that. Or are you reviewing every bit by hand?