3 ms·
> If an attacker has access to your server, why should I believe that they wouldn't be able to update your github repository? I don't have my GitHub password/k
by twiss 9y ago
> If an attacker has access to your server, why should I believe that they wouldn't be able to update your github repository?
I don't have my GitHub password/keys on the server. Why would I have them there?
> I have to trust you _regardless_ of any of your technology, and that's the problem.
Yes, but it's trust-on-first-use. There's a big difference between
1. Trusting me today when I say that the GitHub keys are not on my server,
2. Trusting me today when I say that I'm not sending your password to the server, and being able to verify that by checking the code on GitHub
and
1. Trusting me every time you open the web app
2. Trusting me and my hosting company that I won't ever get hacked
- jimktrains2 9y ago> I don't have my GitHub password/keys on the server. Why would I have them there? Because you only need an SSH key to push to github and it's not uncommon for people to leave those laying around (or to forward them with a connection!) on a server. The better question is not "Why would you have them there?" but "How do I know you don't have them there?" > Yes, but it's trust-on-first-use. There's a big difference between You're showing a very fundamental misunderstanding of trust and security. I trust your code every single time I load the application. I don't care what measures you _think_ you've put into place, I will _guarantee_ you they are not fool-proof if you have a compromised system. You're insistance that it is is very disheartening and continues to degrade any trust I would have placed in you. > 1. Trusting me today when I say that the GitHub keys are not on my server, No, it's trust that you will never ever ever ever place them on any device you ever own where it is accessible or that said device will never ever ever be hacked. > 2. Trusting me today when I say that I'm not sending your password to the server, and being able to verify that by checking the code on GitHub And when this changes? Must I audit the code every single time I load the code? Because yes, I need to do that to ensure you havn't changed anything. > 1. Trusting me every time you open the web app I still need to do this. > 2. Trusting me and my hosting company that I won't ever get hacked I still need to do this too.
- twiss 9y ago> And when this changes? Must I audit the code every single time I load the code? Because yes, I need to do that to ensure you havn't changed anything. No. The whole point of what I've done and made is to make sure you don't have to do this. The Service Worker checks all code that is coming from the server. If you've opened Airborn OS before on a computer, and don't see a notification saying that Airborn OS has been updated, it is guaranteed that it's still the same code. If it did change, you get a notification with a nice link to GitHub, where you can inspect the commits since last time. That code is guaranteed to be identical to the new code that you will be running if you refresh Airborn OS.
- jimktrains2 9y agoI'm glad you think that. I still don't trust you, nor do I trust that you will never be breached in such a way that a malicious update will be pushed. Everything you're saying still depends on me trusting you. What if this is my first time loading? How do I know you're not serving up new files that don't contain checks to be visitors? Moreover, are you insinuating that you will never update any code and that expect that pop up saying you've updated the code to never appear? Do you expect people to check commits multiple times a week or a day? So, ok, let's assume you're 100% trustworthy and a malicious actor changes the code and I get an error. Am I now forever unable to access my documents? How can I be sure that the code I'm running is really the code on GitHub after a breach? How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly. But again, this all assumes that your 100% trustworthy, and you're not. You're just some person asking me to believe you'll never ever make a mistake or be coerced into a malicious action. Also I haven't seen a mention of the aes mode you're using. Your security pages is laughably shirt given that it's literally your main selling point.
- twiss 9y ago> What if this is my first time loading? Like I said, it's trust-on-first-use. This is no different from installing a desktop app. > How do I know you're not serving up new files that don't contain checks to be visitors? The Service Worker is installed on your own computer, and is still there the next time you open the web app. > How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly. https://developer.mozilla.org/docs/Web/API/Service_Worker_API https://developer.mozilla.org/docs/Web/API/Service_Worker_AP...