Describe use case.

[andre-d]

The user will be properly protected if using an extension which contains the entire client code (coming soon) or in the case of uploading one of the existing third party clients.

I suggest revising this to be a warning about trusting browser downloaded code rather than a blanket statement about up1 On Jan 25, 2016 3:40 PM, "Juerd Waalboer" notifications@github.com wrote:

---

You can view, comment on, or merge this pull request online at:

https://github.com/Upload/Up1/pull/43 Commit Summary

• Describe use case; protecting users is not it.

File Changes

• M README.md https://github.com/Upload/Up1/pull/43/files#diff-0 (2)

Patch Links:

• https://github.com/Upload/Up1/pull/43.patch
• https://github.com/Upload/Up1/pull/43.diff

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43.

[Juerd]

No, read-only visitors without the extension will still be a liability if they have the key. They run server-provided code in a context where the key is available.

[andre-d]

As soon as you give the URL to someone that data is already a liability regardless of what client they use. On Jan 25, 2016 4:02 PM, "Juerd Waalboer" notifications@github.com wrote:

No, read-only visitors without the extension will still be a liability if they have the key. They run server-provided code in a context where the key is available.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174661774.

[joepie91]

You seem to be confusing two threat models.

When you give the URL to someone, it is only a liability for the uploader, if the recipient turns out not to be trustable. The server operator plays no role here.

However, if the server operator were to serve maliciously modified scripts that send the plaintext data back to the server, then any non-verifiable client would end up being a liaility, as the moment they load an image, it will be sent to the server operator. This only has to happen once for an upload to become 'compromised'.

In other words: the encryption protects the server operator, not the uploader, as the server operator can subvert if it they so desire, even if some users use a browser extension.

Even an extension would not necessarily be perfect - in any browser that allows automatic extension updates, the same capability of adding malicious modifications would be available to the extension maintainer.

[ultramancool]

Of course this does not protect against a malicious host, nor can anything protect against giving your keys to a malicious user.

I don't think the wording in this is particularly bad, I thought we mentioned this or at least something about potential dangers already? If not, merge this, maybe add a bit about the browser extensions protecting against this and a warning about linking people who don't use them (though these should be obvious, the model of up1 was designed to make these clear to users through use of simple string encoded keys). On Jan 25, 2016 4:03 PM, "Andre d" notifications@github.com wrote:

As soon as you give the URL to someone that data is already a liability regardless of what client they use. On Jan 25, 2016 4:02 PM, "Juerd Waalboer" notifications@github.com wrote:

No, read-only visitors without the extension will still be a liability if they have the key. They run server-provided code in a context where the key is available.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174661774.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174661947.

[Juerd]

Like explained, extensions cannot protect against malicious hosters as long the regular browser interface is preserved (and frankly, I don't see much value in any software that fully depends on browser extensions because standalone apps would probably be better in that case).

Also, indeed recipients need to be trusted. However, unlike in regular end-to-end encryption using verified client side software, this mode of operation also requires trusting the hosting party, and as such, it cannot protect against malicious hosters.

This is very useful software, but please let's be clear about expectations, preferably in clear and not-very-technical wording.

[ultramancool]

Standalone apps can be updated and often are updated automatically, so can extensions. Do you inspect every update to your OS? Every automatic extension upgrade? Anyone using anything in a less than perfect fashion presents a vulnerability, this being a web app increases that risk in only the slightest way. On Jan 25, 2016 4:16 PM, "Juerd Waalboer" notifications@github.com wrote:

Like explained, extensions cannot protect against malicious hosters as long the regular browser interface is preserved (and frankly, I don't see much value in any software that fully depends on browser extensions because standalone apps would probably be better in that case).

Also, indeed recipients need to be trusted. However, unlike in regular end-to-end encryption using verified client side software, this mode of operation also requires trusting the hosting party, and as such, it cannot protect against malicious hosters.

This is very useful software, but please let's be clear about expectations, preferably in clear and not-very-technical wording.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174665801.

[joepie91]

None of that changes that creating the impression that this will protect you from the host, is a wrong and dangerous thing to do. "They do it too!" (and I'm not sure that that many applications even do so) has never been a valid argument.

[ultramancool]

Nothing can ever protect you from a developer that you do not trust.

It's pointless to note things which we obviously can't protect against - should we start listing OS vulnerabilities too?

Up1 does protect you from the server, with the obvious assumptions that the server is secure and you trust the developer. If you are unable to trust these things then you probably shouldn't be using a computer, how can you trust that CPU manufacturer? On Jan 25, 2016 4:24 PM, "Sven Slootweg" notifications@github.com wrote:

None of that changes that creating the impression that this will protect you from the host, is a wrong and dangerous thing to do. "They do it too!" (and I'm not sure that that many applications even do so) has never been a valid argument.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174668830.

[Juerd]

This is true, but with standalone software, in general the hosting provider and the developer are different people. Besides that, automatic updates happen less frequently than downloads using the software, and require verification from the developer or distributor, both of which are often separate from the party that happens to host the communication services.

Given a web service like this one, the hosting provider has the opportunity to modify the software that is run on the client's computer. The hoster now has the same possibilities that usually only the developer and distributor have, and the update frequency will (nearly) equal the frequency of http requests.

Since clearly not everyone knows about this risk, I think it's a good idea to be explicit about it in the Caveats section. That's what Caveat sections are for...

[ultramancool]

If you look at the current readme there's a section addressing this titled "By its very nature, this uses cryptography in Javascript.", it admittedly could be clearer - but at the same time, it's possible to chase this "who don't you trust" problem way too far, most users would have to address this for every application on their system so I don't feel it's worth addressing further. CPUs nor OSes nor web browsers ship with warnings about their own developers.

[joepie91]

Up1 does protect you from the server, with the obvious assumptions that the server is secure and you trust the developer.

This contradicts itself. If you trust the server and the developer, then why would you need 'protection' from it?

Something only 'protects' you when it can withstand adversarial situations. This application cannot. Which is fine in and of itself, but you need to be abundantly transparent about it.

[Juerd]

You say "it admittedly could be clearer" and then close the pull request that specifically makes it clearer.

If you weren't about to get your users into serious trouble by being intentionally vague, this would have been very funny. Unfortunately, currently it's just sad.

[ultramancool]

There is a big difference between trusting the server with pseudo random noise and trusting the server with your data. That is the distinction that makes this not contradictory. On Jan 25, 2016 4:48 PM, "Sven Slootweg" notifications@github.com wrote:

Up1 does protect you from the server, with the obvious assumptions that the server is secure and you trust the developer.

This contradicts itself. If you trust the server and the developer, then why would you need 'protection' from it?

Something only 'protects' you when it can withstand adversarial situations. This application cannot.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174680638.

[joepie91]

You are trusting the server with your data here, as both of us have attempted to explain repeatedly. Not with "pseudo random noise".

[ultramancool]

If you trust the server to provide cryptographic code you are not trusting the server with your data. Similar to the way in which you don't trust Microsoft with every Word document you write for example. They could update Word and steal your document. You're just trusting that they won't. On Jan 25, 2016 4:51 PM, "Sven Slootweg" notifications@github.com wrote:

You are trusting the server with your data here, as both of us have attempted to explain repeatedly. Not with "pseudo random noise".

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174681521.

[joepie91]

And, again, as we have explained, you cannot trust the server with the cryptographic code either. You are making (implied) security claims that you cannot provide, by the very nature of how it is designed. That is what makes Up1 different from Microsoft Word.

[andre-d]

Just as word could write a patch to upload your documents we could write a patch to tell us your key, yes. On Jan 25, 2016 4:55 PM, "Sven Slootweg" notifications@github.com wrote:

And, again, as we have explained, you cannot trust the server with the cryptographic code either. You are making (implied) security claims that you cannot provide, by the very nature of how it is designed. That is what makes 1Up different from Microsoft Word.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174683508.

[ultramancool]

We do not make any claim to be able to protect against obviously impossible things.

You cannot trust the server, but you also cannot trust your browser vendor, OS vendor, your CPU manufacturer, etc. Distrust in this sense is useless to note as it results in an endless chain of distrust. On Jan 25, 2016 4:55 PM, "Sven Slootweg" notifications@github.com wrote:

And, again, as we have explained, you cannot trust the server with the cryptographic code either. You are making (implied) security claims that you cannot provide, by the very nature of how it is designed. That is what makes 1Up different from Microsoft Word.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174683508.

[Juerd]

So what exactly is wrong with the pull request itself?

[joepie91]

We do not make any claim to be able to protect against obviously impossible things.

And I quote from the README:

Up1 is a simple host that client-side encrypts images, text, and other data, and stores them, with the server knowing nothing about the contents.

This seed can be of any length (because really, the server will never be able to tell)

Yes, making (implied) security claims is precisely what you are doing. I am also becoming increasingly wary about your reasons for not wanting to clarify this.

[andre-d]

My issue (I cannot speak for other developers) is with the wording of the clarification not with clarifying. The clarification implies that using such a service is of no benefit to the user despite placing the same trust in it that you place on any other software with automatic updates.

The server does not know your key unless we update it to know your key any more than any other automatically updated software. You are correct in that it is more like an auto update every request but this is resolved with an extension which you dismissed due to distrust in auto updates. On Jan 25, 2016 5:01 PM, "Sven Slootweg" notifications@github.com wrote:

We do not make any claim to be able to protect against obviously impossible things.

And I quote from the README:

Up1 is a simple host that client-side encrypts images, text, and other data, and stores them, with the server knowing nothing about the contents.

This seed can be of any length (because really, the server will never be able to tell)

Yes, making (implied) security claims is precisely what you are doing. I am also becoming increasingly wary about your reasons for not wanting to clarify this.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174686866.

[ultramancool]

All claims any software makes rely on the trust of the developer, how can GPG or OTR say it provides any security? Do they hedge against themselves in their documentation? Just because Up1 is a Web application does not increase any of the reasons you've given. I simply do not wish to confuse users with this sort of trust all the way down game. If you don't trust anyone, don't use it. Simple as that. On Jan 25, 2016 5:01 PM, "Sven Slootweg" notifications@github.com wrote:

We do not make any claim to be able to protect against obviously impossible things.

And I quote from the README:

Up1 is a simple host that client-side encrypts images, text, and other data, and stores them, with the server knowing nothing about the contents.

This seed can be of any length (because really, the server will never be able to tell)

Yes, making (implied) security claims is precisely what you are doing. I am also becoming increasingly wary about your reasons for not wanting to clarify this.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174686866.

[joepie91]

The clarification implies that using such a service is of no benefit to the user

It isn't.

despite placing the same trust in it that you place on any other software with automatic updates.

This is irrelevant. Your software presents itself as something better than "any other software", which it isn't. Subvertible cryptography is not any better than zero cryptography. (EDIT: In fact, it is usually worse, because it creates a false sense of security.)

The server does not know your key unless we update it to know your key any more than any other automatically updated software.

Again, the problem is in presenting your software as being better than that, which the current README is doing, whether intentionally or not.

All claims any software makes rely on the trust of the developer, how can GPG or OTR say it provides any security?

Because they are open-source, run locally (ie. not auto-updatable), and are thus auditable. That is not the case for the Up1 code, as you cannot be sure that you are running the same code that you've audited in the past.

Do they hedge against themselves in their documentation?

They don't need to, because they're not prone to these issues.

Just because Up1 is a Web application does not increase any of the reasons you've given.

Yes, it does. It makes the crypto subvertible.

I simply do not wish to confuse users with this sort of trust all the way down game. If you don't trust anyone, don't use it. Simple as that.

Then just tell them that. Don't pretend that it's somehow more secure or keeps the server in the dark, because it can't.

[andre-d]

I suppose you will be asking TextSecure to be putting the same warning on their code since it can also update automatically if you run their copy? On Jan 25, 2016 5:10 PM, "Sven Slootweg" notifications@github.com wrote:

The clarification implies that using such a service is of no benefit to the user

It isn't.

despite placing the same trust in it that you place on any other software with automatic updates.

This is irrelevant. Your software presents itself as something better than "any other software", which it isn't. Subvertible cryptography is not any better than zero cryptography.

The server does not know your key unless we update it to know your key any more than any other automatically updated software.

Again, the problem is in presenting your software as being better than that, which the current README is doing, whether intentionally or not.

All claims any software makes rely on the trust of the developer, how can GPG or OTR say it provides any security?

Because they are open-source, run locally (ie. not auto-updatable), and are thus auditable. That is not the case for the Up1 code, as you cannot be sure that you are running the same code that you've audited in the past.

Do they hedge against themselves in their documentation?

They don't need to, because they're not prone to these issues.

Just because Up1 is a Web application does not increase any of the reasons you've given.

Yes, it does. It makes the crypto subvertible.

I simply do not wish to confuse users with this sort of trust all the way down game. If you don't trust anyone, don't use it. Simple as that.

Then just tell them that. Don't pretend that it's somehow more secure or keeps the server in the dark, because it can't.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174690354.

[ultramancool]

The crypto is no more subvertible in Up1 than it is in Chrome, Firefox, Ubuntu or Windows 10, all of which have automatic updates by default. Unless you manually verify every update to everything you run on your system, you have no way to trust these things.

If you are this concerned about automatic updates, simply run your own instance which you audit yourself. On Jan 25, 2016 5:10 PM, "Sven Slootweg" notifications@github.com wrote:

The clarification implies that using such a service is of no benefit to the user

It isn't.

despite placing the same trust in it that you place on any other software with automatic updates.

This is irrelevant. Your software presents itself as something better than "any other software", which it isn't. Subvertible cryptography is not any better than zero cryptography.

The server does not know your key unless we update it to know your key any more than any other automatically updated software.

Again, the problem is in presenting your software as being better than that, which the current README is doing, whether intentionally or not.

All claims any software makes rely on the trust of the developer, how can GPG or OTR say it provides any security?

Because they are open-source, run locally (ie. not auto-updatable), and are thus auditable. That is not the case for the Up1 code, as you cannot be sure that you are running the same code that you've audited in the past.

Do they hedge against themselves in their documentation?

They don't need to, because they're not prone to these issues.

Just because Up1 is a Web application does not increase any of the reasons you've given.

Yes, it does. It makes the crypto subvertible.

I simply do not wish to confuse users with this sort of trust all the way down game. If you don't trust anyone, don't use it. Simple as that.

Then just tell them that. Don't pretend that it's somehow more secure or keeps the server in the dark, because it can't.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174690354.

[joepie91]

I suppose you will be asking TextSecure to be putting the same warning on their code since it can also update automatically if you run their copy?

TextSecure no longer exists, but yes, I would expect Signal to provide the same warning if it does indeed auto-update.

The crypto is no more subvertible in Up1 than it is in Chrome, Firefox, Ubuntu or Windows 10, all of which have automatic updates by default.

None of which proclaim that they will "protect you from the server". How many times do I need to repeat this?

If you are this concerned about automatic updates, simply run your own instance which you audit yourself.

Which defeats the entire point of having client-side cryptography in the first place.

[andre-d]

You can host your own instance and distribute links to content how does that defeat the purpose? Do you not trust your own host? On Jan 25, 2016 5:16 PM, "Sven Slootweg" notifications@github.com wrote:

I suppose you will be asking TextSecure to be putting the same warning on their code since it can also update automatically if you run their copy?

TextSecure no longer exists, but yes, I would expect Signal to provide the same warning if it does indeed auto-update.

The crypto is no more subvertible in Up1 than it is in Chrome, Firefox, Ubuntu or Windows 10, all of which have automatic updates by default.

None of which proclaim that they will "protect you from the server". How many times do I need to repeat this?

If you are this concerned about automatic updates, simply run your own instance which you audit yourself.

Which defeats the entire point of having client-side cryptography in the first place.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174693164.

[ultramancool]

TextSecure no longer exists, but yes, I would expect Signal to provide the same warning if it does indeed auto-update.

Okay. This is done. When you convince Moxie to add such an obvious warning, we will also make this change. On Jan 25, 2016 5:16 PM, "Sven Slootweg" notifications@github.com wrote:

I suppose you will be asking TextSecure to be putting the same warning on their code since it can also update automatically if you run their copy?

TextSecure no longer exists, but yes, I would expect Signal to provide the same warning if it does indeed auto-update.

The crypto is no more subvertible in Up1 than it is in Chrome, Firefox, Ubuntu or Windows 10, all of which have automatic updates by default.

None of which proclaim that they will "protect you from the server". How many times do I need to repeat this?

If you are this concerned about automatic updates, simply run your own instance which you audit yourself.

Which defeats the entire point of having client-side cryptography in the first place.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174693164.

[Juerd]

☑ never be the first to do the right thing.

[joepie91]

You can host your own instance and distribute links to content how does that defeat the purpose? Do you not trust your own host?

Because then you don't need client-side cryptography (which introduces a dependency on Javascript and is thus better avoided). You can just set up TLS and point people to the image files directly. Client-side encryption doesn't add anything here, and only makes it more hostile towards eg. people who browse with Javascript disabled over privacy concerns.

Okay. This is done. When you convince Moxie to add such an obvious warning, we will also make this change.

Unbelievable. Are you seriously arguing that you don't need to do the responsible thing because a particular other person or company hasn't?

... Seriously?

[Juerd]

Client-side encryption doesn't add anything here

Not true. It adds protection for the hoster, which makes it easier to decide to run an instance of Up1.

[joepie91]

Not true. It adds protection for the hoster, which makes it easier to decide to run an instance of Up1.

Sorry, I should have clarified - it doesn't add anything for the client. But given that you are running your own instance because you do not trust others, it is unlikely that anybody but you will be using it, and there's no point protecting yourself (as host) from yourself (as user). So in the end, it's still of dubious usefulness, even from the perspective of a host, if you run your own.

[andre-d]

Even with the distrust of client updates you are granted forward secrecy on any links before such an update. On Jan 25, 2016 5:31 PM, "Juerd Waalboer" notifications@github.com wrote:

Client-side encryption doesn't add anything here

Not true. It adds protection for the hoster, which makes it easier to decide to run an instance of Up1.

— Reply to this email directly or view it on GitHub https://github.com/Upload/Up1/pull/43#issuecomment-174701351.

[joepie91]

Even with the distrust of client updates you are granted forward secrecy on any links before such an update.

What?

[k3d3]

What?

If a server gets seized, or someone gains read-only access to the database, they can't gain access to the data, even if nobody uses a browser extension or standalone client.

I'm sorry, but I'm not putting a message in the README that effectively states "Don't use this, it's useless", regardless of your opinions to the contrary. This is a webapp; in this context, this is as secure of an application as you can get without browser extensions (which is why we're trying to get them out there).

[ultramancool]

@k3d3 What do you think about a modified version of this message - the actual content is not as bad as what we've mostly been arguing about, if we just change "can always inject malicious code that reads the encryption key. This means that the data uploaded by the user can be seen by the server administrator. " to "can inject malicious code that reads the encryption key, allowing them to see data uploaded by users." I think it'd be clear and avoid sounding like it's guaranteed that server admins will backdoor you. I do like that it also presents the motivation for them to not backdoor you.

[andre-d]

https://github.com/Upload/Up1/commit/29c8ddc62059e3880a376b532527de312e00d017?w=0#diff-04c6e90faac2675aa89e2176d2eec7d8L85