Time to Encrypt the Cloud
blog.cryptpad.fr
blog.cryptpad.fr
Even if the operator is not malicious they could receive a court order or the connection loading the code could be MITMed even if you think you're secure[0].
[0] https://medium.com/@karthikb351/airtel-is-sniffing-and-censo...
So right now on web or mobile you simply have to trust the app developers.
Apple & Google could easily fix this by copying the docker registry. Just run a build process themselves directly from a specified git SHA. Publish that & name the repo & git SHA they used for the build. That way security researchers could go read the sourcecode and know that its the actual code running on everyone's phones.
Mind you, doing this would make it easier for the US government to compel apple or google to modify a binary for just one user. But apple and google can already do that if they want to.
Another approach would be to make the whole toolchain build reproducible binaries, so a researcher can run the build process themselves and verify the binary hashes match.
But lets not pretend that somehow apps are more secure because you download a sandboxed app from an app store instead of sandboxed JS + HTML. The tech stacks used to deploy code are more similar than they are different.
But at least for opensource, if you are willing you can build your own binary, using your own tools, from the source in the commit history, and get an app that matches the commit history [1].
[1] Exclusive of the issues detailed in "Reflections on Trusting Trust" by Ken Thompson regarding the actual build tools themselves (https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)
The page itself can still be modified, but there are mitigations that can be performed if you're paranoid enough.
1. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
I created a Firefox extension that can check signatures both in the certificate and (in the meantime) hardcoded in the extension. [2]
[1]: http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of...
[2]: http://blog.airbornos.com/post/2016/02/23/The-first-web-appl...
And it does not necessarily address the compromise of the hoster either, since the attacker who has control over that may also have access to the signing keys. Especially in the case of a court order.
That effectively is a silent, user-targetable auto-update of software to which you entrust your secret data.
Auto-updates for crypto software should be verifiable through other channels, require user confirmation and use a distribution method that is difficult to scope to a single user to make targeted attacks harder.
It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution.
It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.
SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use.
It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective.
But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.
Trackability would be nice though. Imagine if web data served off a domain could be dug through like a git repo. If you could see every commit and diff, and if proof of malice would be indisputable. Then, even if bad people did take over the domain, it would be detected immediately, and its reputation rating would drop so low that browsers would refuse to connect to it.
How to achieve this, no idea. Or, several ideas, but nothing general enough ¯\_(ツ)_/¯
Or have some, say, third-party hash proof of the download? (Essentially signed downloads.)
Or if the system is blind to the identity of the user requesting information? Reads need not be authenticated, only writes, which would have to match some signature, say.
(I'm aware of numerous browser problems, I'm looking at ways around them.)
In other words, you must ensure that the frontend treats the entire backend as a hostile actor, not just the code it serves, but also the data.
Not all web frontends are written like that; many serve HTML snippets that get pasted into the DOM unchecked, instead of passing JSON data and rendering on the client side. You can sign the static frontend code all you want, and you're still owned by the service itself in this case.
https://hacks.mozilla.org/2017/01/using-immutable-caching-to...
For security you don't need an immutability-hint, you need it enforced.
I'm starting to think that Spider Oak has destroyed the meaning of the term. Apparently Zero knowledge now means E2E.
Keybase's entire purpose is to make a public database of people. They know who you are, therefore, they have some knowledge.
Not that complicated. If you store user profile data and therefore link the data they store to that profile, it is not zero knowledge.
Arguably, if you have to charge money for a service, you might need a way to do that, but then you're not zero knowledge. Or you just a flat rate with unlimited of whatever your service provides.
I don't think it makes a lot of sense to trust a company that claims to be secure when they don't understand even the terminology, let along the complexities, of providing security and privacy.
Spider Oak has also dropped the term and now goes with "no knowledge."
If the system can work with Victor knowing anything else about Peggy, e.g., entirely taking the question "who are you" out of the equation, well, then, we've got an interesting situation.
Unless the anonymity set is very small or bandwidth is infinite, accomplishing metadata privacy requires some kind of zero knowledge proof.
I don't think such systems necessarily require E2E encryption. If the term zero knowledge continues to be misused, it's going to cause more confusion later when services get around to protecting metadata.
A phrase like "military grade" is now and was always a meaningless, nonsense phrase used to suggest robustness. No military has actually defined any "grade" of encryption to measure with. It's like saying that your ladies deodorant is "Strong Enough For a Man". Sure, whatever.
End to end encryption (E2E) on the other hand means something specific: The secrets critical to the security of the system live on the end user devices. If a standard webmail service claims to be E2E, it's not marketing, it's lying.
Likewise, zero knowledge has a well defined meaning. It's a protocol where a Prover convinces a Verifier that it has some information, without actually revealing what that information is. For example, Peggy could have a set of public keys, whose order she has randomly shuffled. She can prove to Victor that the output of her Shuffle is a valid permutation of the keys, without revealing to Victor what order they were in before she shuffled them.
Zero knowledge protocols are useful building blocks for such tasks as:
- Mixing messages in a way that prevents a global passive adversary who also maliciously runs some of the routers in a network from learning the social graph of users (Tor cannot do this, because it is not zero knowledge)
- Verifiable secret ballots. Voting systems where you receive proof that your ballot was cast as you intended, but you can't use the proof to convince anyone else. (To mitigate vote buying/voter intimidation)
- Offering a database where users can query information, but the database operators cannot know what records have been requested
If a product doesn't provide such features, or doesn't make use of a zero knowledge proof, then calling it zero knowledge is nothing more than a brazen lie.
Ok so my desktop is device #1, and mobile is #2. I encrypt a note on desktop, then "query information, but the database operators cannot know what records have been requested" with device #2, it seems this concept fits to end-to-end definition you gave?
I really think both terms are so vague that can be bended in a way that they look interchangeable. And nothing wrong about it.
E2E is a term that dictates that when I send information, only the intented reciepient can decrypt it, under the assumption that the keys are safe.
Zero knowledge proofs is a constuct where I can prove something to you, without leaking any information. For instance, you want to buy a house, but before the seller wants to sign, he wants proof that you can actually pay x $ in down payment. Traditionally you would go down to your bank, get a piece of paper stating that you have x $ locked and only usable for this purchage for the next 60 days. It doesn't say how much you have in your account, where the money is from or anything else. A zero knowledge proof is the same, just digital.
E2E would not help here, because it doesn't prove anything, it's just a term about the comunication being safe.
But misuse of the term is most likely just because they didn't understand it in the first place. It is well defined, but rather abstract.
Take your example, you upload 10 notes to a server with device #1 and then retrieve a few of them with device #2. The server knows exactly what 10 notes you uploaded and exactly which of 3 of the 10 were read by the second device. It also knows when the uploads and downloads occur. Since it knows #2 downloaded a subset of what #1 uploaded, it can conclude that #1 and #2 have some kind of relationship. (eg. Both are your devices, or one device belongs to your friend with whom you have shared 3 of your notes) This is E2E but not zero knowledge.
Now imaging incorporating both E2E and zero knowledge techniques into a note sync system:
1) All notes are encrypted end to end. That is, the servers that store and route notes never learn the secrets necessary to decrypt them
2) Notes sent into the system are routed through a mixnet that uses verifiable shuffles so no one passively watching all of the users and system (or actively running malicious servers or clients) can learn who is sending which note ciphertext.
3) Note ciphertexts are retrieved from the system using private information retrieval so that observers and cheating servers don't learn who is receiving which one or when it's been received.
This system isn't going to learn anything about how many devices you have or who you share with. And it's going to prevent further analysis of metadata: For example, device #1 and #2 keep matching sets of notes and they frequently connect from the same IP addresses, therefore it's safe to assume these devices are owned by the same person. Device #3 requests a subset of notes that were uploaded by #1 and #2, but always from a different country. Now #3 retrieves a note posted by #2 from the same IP address that #1 used recently. Therefore it's safe to assume that the owner of #3 is visiting the owner of #1 and #2.
I recently suggested to add a frontend for collaborative agile retrospective boards, similar to Retrium. CryptPad seems pretty pluggable in that regard, and actually TIL it can even edit presentation slides now :)
We do this by adding a hash character (#) to a link.
By design, browsers don’t share anything after this
character.
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?!
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.
Above is from the researchers: https://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-in...
If indeed this is possible then the internet is totally broken. "Reduce the effectiveness" implies that it is still possible though.
It's not only ordinary people who don't care about privacy. Even businesses who have a great deal to lose from loss of privacy, still use Slack and Gmail. (Indeed, I bet even Google competitors use Gmail).
The real angle is theft, not privacy. Companies are always stealing all of our data, which is why it's so cheap. If we took steps to protect it, serious steps that actually denied companies the knowledge that drives their growth, then we'd have gained something valuable. The unfortunate truth is that people won't protect what they've come to believe is worthless, and so it will remain worthless. A chicken-and-egg problem, to be sure.
Thing is, when people do realise they care about privacy, they're going to really care about it.
https://cryptpad.fr/pad/#/1/view/+VGaPJa1oHnDhNfGTugy+Q/gTSc...
But some might say that because it's not open source you can't trust them.
Personally I trust the money I give them, they promised me privacy, I pay monthly, if I am ever betrayed I'll leave apple ecosystem forever and they will get less money. So they basically have no incentives to lie to me. Yes it's all based on trust but this always come to that at some point.
If forfeiting icloud privacy gives them access to a billion new hardware customers (hello China!) as iphone sales are dwindling, do you really believe they will stick behind icloud privacy ? The point being that they may have more incentive to break their privacy promises than you think.
But still, at the moment apple being a hugely succesful hardware company gives it less incentives than say an advertising network (hello google), a "give us all your data and we'll make it available online for you, also ads" (hello facebook Inc.) as their revenue depends mostly on hardware not on ads or software licencing or investor story time. This may change when profits and sales go down, we have already witnessed other hardware vendors making moves such as lowering item sale price with a strategy to recoup the loss with exploiting/reselling user data later (hello samsung).
And should it not be the case? Theoretically.
As for the reasoning why they do not have incentive to lie to you goes same for anyone and pretty much anything where a wrongdoing takes place that shouldn't have happened in the first place. It could be anything. If we go for examples it will be stretching it just too far.
The middle ground can be - an easy backup/sync/mail service that does the heavy lifting - the transport work and we encrypt decrypt on the client side. For example, we can't have a transportation company if all we have to do is send a few packets every month across the company or globe. But we can have an unbreakable lock/safe/package in which package the stuff and the receiver is the only person how to open the stuff. I have never really been good at analogies but I hope you get the drift.
If only they could write an easy app that uses the service APIs and code for that app is open source and all it does is encryption decryption (generally speaking) on the client machine. Something BackBlaze and CrashPlan claim to do (they are closed source btw) and so does Tarsnap (haven't used it - too complex and pricey for my use case; and not sure if it's open source).
FWIW, Tarsnap is not under an open source license, but you do get the client source code (and you're encouraged to audit it before compiling).
I'm not quite sure what you mean by "free of charge (via up-front subscription fees, of course)" here. Do you mean an extra "free" feature on top of your paid subscription or do you mean a freemium model where everyone gets the feature but the free users are subsidized by the paid users? Or do you mean totally free?
In the first two cases, I'm afraid the answer is that the only economic incentive is people making purchasing decisions based on the feature being present. If there's no increase in demand, there's no economic reason to implement it. Unfortunately, aside from the HN crowd, not many people seem to care much about privacy.
In the last case, I think it's never going to happen. Nothing can live long without money and if your users aren't your customers, they have to be your product in order for you to survive.
> Is there a business model that is able to ignore the advertising and marketing value of your data, yet still provides enough value to fuel the growth that Google, Facebook, and others have experienced?
I think WhatsApp has demonstrated this no? It's been a paid subscription from the start and as far as I know, the data hasn't ever really been used for marketing or advertising. It's fully encrypted now too.
> Asked another way, would these cloud/social services still be able to exist as we know them if their providers were not allowed to collect and exploit this data?
In terms of collection, some services require access to this data. For example Google can't send you a notification telling you about your flight status if it can't read your email to get your flight confirmation. It also can't recommend videos on YouTube or pay creators without access to watch histories. I also doubt that more basic products like Google Search can work as well as they do without knowing which links you're clicking to tell them how good the results are.
In terms of exploitation, I think there's definitely an argument for users paying to, for example, not be advertised to or have their data withheld from marketing exchanges, however there's no demand for it.
No. It's been bought out by facebook Inc. in 2014.
excerpt from whatsapp legal info:
If you are an existing user, you can choose not to have your WhatsApp account information shared with Facebook to improve your Facebook ads and products experiences. Existing users who accept our updated Terms and Privacy Policy will have an additional 30 days to make this choice.
But for new users, well tough luck !
Their encryption was criticized when it was shown that it is implemented in a way allowing whatsapp to replace the key transparently without notifying the user.
Bonus excerpt from whatsapp legal info:
As part of the Facebook family of companies, WhatsApp receives information from, and shares information with, this family of companies. We may use the information we receive from them, and they may use the information we share with them, to help operate, provide, improve, understand, customize, support, and market our Services and their offerings. (...) Facebook and the other companies in the Facebook family also may use information from us to improve your experiences within their services such as making product suggestions (for example, of friends or connections, or of interesting content) and showing relevant offers and ads.
Where do you get the idea that there is no demand for this ? It's a recurrent demand and it is consistently declined for business model reason by the facebook-like (see investor storytime[1]).
Then there is a compelling argument that paying not to be advertised is only going to make you a more valuable target to be advertised to.[2]
Likely paying for having your data withheld from marketing exchanges will increase the price of your data on the market while not providing you any way to be sure it has effectively been withheld.
The only way is for this data not to be collected in the first place.
[1]: https://www.theatlantic.com/technology/archive/2014/08/adver... [2]: http://zen.lk/2015/07/19/Why-you-will-never-escape-ads-by-pa...
A free, open source, peer to peer infrastructure is the only way out.
Not for profit organizations have self-interest too. We just don't always know what it is.
I think what we should be looking for is alignment of self-interest and where that is not possible we need good balance of power.
I don't see how any of that is aliged with the users' interest. Of course, they will also spend quite a lot on marketing, trying to make you believe the opposite.
Also, in addition to the business model, the whole entity of a for profit corporation is rather transient. And when we're talking about an infrastructure for storing, relaying and accessing information, that's definitely not a good thing. I don't think google, facebook, dropbox or github will be around in a couple of decades, due to political and economical reasons. It's hard enough to keep information around the face of technological advancements (new hardware architectures, protocols, algorithms, data formats, etc), so we really don't need these additional obstacles.
Not sure why GP assumed this must be free of charge; tech-savvy consumers also tend to have money.
If there was a cloud provider with solid infrastructure, full transparency and insight to the network down to server cams, all based on free software, would you have paid extra for it?
Think about MSP models for a moment. Consider how they morphed into SaaS models over time. That "morphing" involved moving the data from an on-prem location to the "cloud". If you look under the hood of infra while this was going on, you see lots of innovation occurring with networking, compute resource allocation, security, storage, etc.
Now think about SaaS moving on-prem. A company has a bunch of their own infrastructure spread across both public cloud and private cloud systems. They want some of that software to have the benefits of SaaS. They want some of that software to be as secure as running it on-prem.
If we can manage to create the right software to enable it, there will be a new business model based on running someone's SaaS software on your own machines. There needs to be a way to deploy this software, and do updates and maintenance of course, but there also needs to be a way to pay for use, updates and that maintenance.
Older models of using license keys isn't very secure and doesn't scale the way SaaS services do. So, you might end up seeing a model like Splunk's, where usage defines license costs. Trouble is, that licensing engine is a pain in the ass to maintain for companies and requires what most to be considered obfuscation to make it secure, guaranteeing payments for use.
If you add cryptocurrencies to the mix, then you have a way to implement a lightweight federation across all types of infrastructure and tie it to the deployment. I won't go too far into the details of that here, but that's what I'm working on currently, and have been working on for a while.
It's not an easily solved problem. The best solution I've seen is Tor, but then, using that will put you on several watch lists. If that is to ever change, we need something like Tor built into a browser as incognito mode to make it widely accessible.
If everyone clicked on stuff they aren't interested in that helps solve the problem.
Also try getting children to use your computer and click ads - that really confuses them. :)
It confuses the children? :)
Name one "watch list" that you get put on for using Tor. That's ridiculous. Even with Rule 41 there aren't any additional watch lists. It's this exact fear and unfounded self censorship that destroys a society quicker than any actual oppressive regime could.
In a traditional "watch list", those listed can expect to automatically encounter more scrutiny or problems from government officials in some kinds of interaction, like trying to board a plane, trying to enter the country, or maybe interacting with law enforcement or trying to file taxes. The XKS rules have in common with this that some people get more and different attention than others (which I can readily agree implicates their rights), but maybe in a particular moment as part of an analyst's activity, rather than in a way associated permanently with their identities.
While I certainly don't think anyone should have the power to perform searches like these, I feel like different senses of "list" are being conflated here, especially in the grandparent post's notion of "several watchlists". (I've been a part of the Tor community for a long time and have never heard of a report of anybody receiving adverse treatment from a government that could be attributed to Tor use this way... though it's certainly plausible that Tor users do get singled out in various ways by various governments for further spying.)
Encrypted storage is a great tool to have, but because the consequences of losing keys are so severe it should usually be an opt-in choice where the user has to positively acknowledge the consequences of losing their key. For most consumers that's going to be for special cases.
It's probably the reason why Apple, which has been at the forefront of E2E encryption with iMessage, does not offer general E2E encryption of iCloud. It does however offer it in the form of encrypted notes in their Notes app. So you can opt in to encrypted storage of secrets, but you'll still recover your photo library if you forget your keychain password.
It is expected that encrypted data will be lost when the key is lost, security comes at the price of convenience.
I disagree that this should be an opt-in choice for an encrypted online data storage service, the whole point of it being encrypted is to make sure it cannot be accessed without the key thus preventing the service provider from being a potential privacy breach point. In post-Snowden times where online privacy requires encryption, always-on encryption for a third party data storage service makes sense and caters to the growing demand for online privacy.
You mean FileVault, their disk encryption? Time Machine backups are not encrypted by default. You have to opt in.
If you mean Keychain, their password manager, that's a good example of a high-security special case. And there are usually ways of resetting lost passwords so you may still survive the loss of your Keychain key.
This is not a matter of "convenience"... Apple does not want a million customers crying at the Genius Bar over the permanent loss of a lifetime of photo memories because they lost their key, ok? You have to design systems expecting that normal people will lose their key at least once in their life. Have you ever lost the keys to your home? For most people, if you offered to improve the security of their home at the cost of incinerating the house if they lose their key, that would not on balance be a good default setup. Maybe for their safety deposit box it would, and only in cases where they'd rather destroy the contents than let them get into the wrong hands. But certainly it's not a one-size-fits-all good default config in all cases.
Witness the popularity of Facebook and tell me the average person cares about privacy.
So which one is it in this case?
I think if you're offering something that isn't actually zero knowledge then the way to create trust is to use something our societies have invented a long time before web apps: Legally binding contracts that give sensible privacy guarantees and support a viable business model.
I fear that's the best we will ever be able to do when it comes to web apps that do more than just backup or data transfer.
There were few practical problems that could not be easily resolved, the main one being that the server could send a different javascript payload (by modifying the HTML src) that leaks everything for specific clients and they wouldn't even know.
The most reasonable solution would be a plugin of sorts that freezes the front-end code and checks that the html+javascript has not been modified since last time, but this wouldn't be practical and has a totally different set of problems.
This scenario could happen if we consider real-world scenarios (imperfect/bad actors):
- Rogue hosting or admin: someone who controls the server decides to change the javascript. They are smart enough to change the checksum in the <script> so things still validate.
- Cracked ("Hacked"): there is a vulnerability in some part of the stack and the javascript gets changed unknowingly by the server admins.
- MITM for a badly configured server that accepts "http:" instead of "https:" and the user connects through a public network. Actually, the fact that it redirects http to https has its own set of problems for the people who might need this: http://security.stackexchange.com/q/44849/9161
Did you solve this? If so, how?
*I did the proof of concept mixing front with back-end and never fully ported it to front-end for the problems explained above.
- Send HSTS header in your code, instead of relying on the server). - Drop the connection if it is not secure. This breaks a reverse-proxy setup though.
There are many services which attempt to base their security on in-browser javascript cryptography.
What could be really valuable is not building Yet Another Service That Helps Privacy (but really, doesn't), but investing effort into building trusted execution models within the browser any website could utilize.
Secure apps will follow just instantly.
There's also https://github.com/ncw/rclone if you would rather do it more like rsync.
https://monod.lelab.tailordev.fr/
I've been using it as a private, sharable wiki for quite a while now.
You can do this with an app like VeraCrypt https://veracrypt.codeplex.com for DropBox or SyncDocs https://syncdocs.com for Google Drive.
Relying on cloud providers to protect your data is not a great idea - just ask Hillary Clinton about Podesta. Adding a separate layer of security and another means of authentication is more secure.
1. Don't just use cryptography, understand how Zero Knowledge encryption works. These 1 minute animated explainer videos do a good job: http://gun.js.org/explainers/data/security.html
2. We used the URL hash method they mention in the cryptpad article to create a beautifully simple P2P payment system (direct bank to bank deposits, no fees), completely end-to-end encrypted: checkard.com
It works and is a lot easier than people may think / expect to build!
"Most websites you use today have fake security. When you log onto their service, your password gets sent up to their proprietary servers. There they check to see if it is correct and grant you access to YOUR data."
"Sure, their servers might be in a top secret location. But the problem is that they know your password. Which means any bad actor, like a rogue employee, a hacker, or a government agency can snoop on your data without you knowing."
This manages to both mis-state how good password practices (hashes and salts) work[1], or what their ultimate failure mode is: your data are still sitting on someone else's server unencrypted. The password, however well hashed or salted, isn't proof against a warrant, hack, insider actions, or poor media disposal.
But given the elementary errors in the text, I'm pretty confident the video is not worth watching.
________________________________
Notes:
1. See e.g., https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
The text is the transcript, which is intentionally conversational not a formal essay. Maybe it is a good idea for us to change it though.
If your philosophy in life is to ignore learning ideas because you are offended by a grammar error, then you are probably right to skip out, the video isn't targeted at people like that.
Given issues of the modern Web, including the absolute deluge of information, finding credible and worthwhile sources is itself a challenge.
Communication -- writing or otherwise -- should be done for the benefit of the reader or audience. To borrow from another item on HN presently (concerning writing manuals).