2 ms·

> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. I should have the choice. This doesn't even give me

by lexman0 10y ago

> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software. I should have the choice. This doesn't even give me that. > Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better. This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated? > AFAIK, revocation isn't very good even with the current CA infrastructure[1][2]. I completely agree with you, so lets not make it any worse.

__david__ 10y ago
> I should have the choice. This doesn't even give me that. I don't understand why you say this. Can you explain more? > This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated? Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.
- rocqua 10y ago
  >> I should have the choice. This doesn't even give me that. >I don't understand why you say this. Can you explain more? Not who you replied to, but with this system, I need to trust everything between the kiosk and the website server to not be MitMed. With the certificate system, I only need to trust the kiosk itself. Specifically, I need to trust the browser does TLS right, and I need to trust the installed root certificates are correct.
  - lexman0 10y ago
    This is my thinking. >> Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me. Then that means each external domain has to tell all its linkers that its key will change whenever it does. Assuming it even has such a list. What if a party doesn't respond? I understand it would be said parties problem, but it sure does make re-keying difficult.

by lexman0 10y ago

__david__ 10y ago

> I should have the choice. This doesn't even give me that. I don't understand why you say this. Can you explain more? > This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated? Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.

rocqua 10y ago
>> I should have the choice. This doesn't even give me that. >I don't understand why you say this. Can you explain more? Not who you replied to, but with this system, I need to trust everything between the kiosk and the website server to not be MitMed. With the certificate system, I only need to trust the kiosk itself. Specifically, I need to trust the browser does TLS right, and I need to trust the installed root certificates are correct.
- lexman0 10y ago
  This is my thinking. >> Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me. Then that means each external domain has to tell all its linkers that its key will change whenever it does. Assuming it even has such a list. What if a party doesn't respond? I understand it would be said parties problem, but it sure does make re-keying difficult.