We do this by adding a hash character (#) to a link.
By design, browsers don’t share anything after this
character.
...and I stopped reading there.
It is astonishing to read that. Just absolutely mind blowing.
Browsers absolutely can and DO share things coming after the hash (#) character in a URL. How?
JavaScript! It's absurdly easy to siphon anchor hashes out of the address bar with JavaScript, and send them back to the mothership, or anywhere else for that matter. It's basically how oh-so-many Very Big Websites work.
I think you're being overly obtuse. The point they're making is that browsers don't automatically send anything after the # to the server.
This makes it possible to implement apps where all decryption is done on the client and the server never sees either the plaintext or the key (which they are mistakenly calling 'Zero-Knowledge' apps).
Whether this is beneficial, and how easy it is to bypass (court order to modify the JavaScript, MITM to modify the JavaScript, extensions which dial in to the mothership with all URLs including the hash fragment), is another question.
But if you assume that your browser or that app are compromised and arbitrary scripts are running in it, then the attacker already has access to all the data anyway, and the location hash itself becomes irrelevant.
They don't claim it's a silver bullet, but they rightfully claim that this at least has the benefit of protecting your data in case someone leaks or sub-poeanas it from the servers hosting it.
Many web apps successfully use this model, most notably client-encrypted pastebin clones like privnote and password managers like KeePassWeb and LastPass.
It's not the browser sharing the hash content, but the javascript in the page. In something like this you clearly have to trust the javascript you download each time in the page.
Is that attack possible over https, without compromising a CA or a local hack like sslStrip? If a page is doing secret stuff over http it's even more broken.
>> "The usage of HTTPS in combination with HSTS can reduce the effectiveness of QI. Also using a content delivery network (CDN) that offers low latency can make it very difficult for the QI packet to win the race with the real server."
It's not clear to me how it is possible over https only sites without forging a certificate or MITMing the connection. The new content would have to be encrypted with the correct key.
If indeed this is possible then the internet is totally broken. "Reduce the effectiveness" implies that it is still possible though.
Took the words out of my mouth. Glad to see someone else commenting on this. As soon as I saw that I was thinking..."well, gee, that seems like a terrible idea".
It is astonishing to read that. Just absolutely mind blowing.
Browsers absolutely can and DO share things coming after the hash (#) character in a URL. How?
JavaScript! It's absurdly easy to siphon anchor hashes out of the address bar with JavaScript, and send them back to the mothership, or anywhere else for that matter. It's basically how oh-so-many Very Big Websites work.
Are you kidding me?!