Paper is a security nightmare. Every document is automatically accessible publicly if you know the url. You need to set each document individually to private. At least for the Personal/Pro plans.

The URLs contain a long random string in them, no? This makes them unguessable. Public-by-default seems to enable easy sharing of documents. I would hope that corporate plans would impose stricter privacy controls, but for personal use, being able to share a document just by sharing its URL seems very convenient. Though I suppose defaulting the permissions such that anyone with the URL can edit the document seems maybe too permissive.

This is security by obscurity, it's still technically possible to access the documents. Like if you accidentally revealed the URL somehow. You shouldn't have to worry about things like that.

Surprisingly, it turns out that using security based on a URL with a random string is /not/ security by obscurity.

The security pattern of a URL with a random string is security-equivalent to a pubic username and a random string password, and also equivalent to the security pattern of a bearer token: so long as the URL is shared only with authorized users, it's the same security hardness.

The pattern can tune the security by using more randomness, such as more characters. There are implementation areas to consider, such choosing a random number generator with high quality randomness like /dev/urandom. There are some access control areas to consider, such as all the people having the same bearer token, which means there's no way to do finer-grained permissions per-user or per-role or per-attribute. There are some user interface areas to consider, such as if a user/agent doesn't treat the URL as secret, because it shows content rather than masking characters such as "*".

For comparison, "security by obscurity" means there's a weakness in how the security is built, such that if you saw the source code, or the physical insides of a lock, then you would understand more about how to crack the security.

In URL pattern, an example of security by obscurity would be if the URL string was not actually random but instead was simply incrementing, or was based on a reversible function of the time or username, etc. If you read the source code, you would discover that there's guessable sequence or guessable trick, and thus become much more likely to break the security.

Edit: I strongly favor higher security, and fine-grained access control, and multi-factor authentication, and UI/UX masking, etc. This post is just to look at security by obscurity.

Browsers do not treat URLs as secure. If you just go to the page and happen to be live-streaming on Twitch or whatever, anyone can access the document because the information is printed visibly on the screen. This makes it starkly different from a password.

And if you type your password onto a keyboard and happen to be live-streaming your physical self on Twitch or whatever from an angle where people can see your hands, they know your password too.

I did not know this distinction, thank you, it makes sense!

Whatever the semantics of security by obsucrity, it's still not ideal that an unintentional screengrab or screen share could reveal the fully editable path of a doc

(i much prefer the google docs method of being able to limit to specific orgs or people)

It’s obscurity in the same way a password or a bearer token is obscurity. Which is not what anybody would reasonably call security by obscurity, as your definition includes any use of a secret.

And easily accessible to Dropbox employees?

Well, I guess they do have access to all of your files anyway?

If they do it right some Dropbox employees might have access to it, but it should definitely not be easy.

Think putting shards of encrypted data together and then decrepyting it by hand to get to the actual file. That's definitely (highly senior) dev level access and a lot of manual work.

Literally all I want from Dropbox is to sync files between my various devices. I am not interested in doing anything else with it.

I think improving on the syncing-workflow and enhancing it to offer more then just syncing would be something useful. Something like automated actions, or filters.

I store sourcecode in my dropbox, and I really would prefer a way to not sync certain junk-files from compiling-process. Or let it automatically commit to a git-repo if there are changes in certain folders. Something like IFTTT for files seems a sane solution that dropbox seem to miss for a long time now.

I do something like this with their CLI to ignore node_modules folders for js dev on mac/linux:

    exclude_folders=$(find . -type d -name "node_modules")
    dropbox exclude add $exclude_folders
    dropbox exclude list # Sanity check

Incron[1] is pretty great for "do X when file Y changes"-style rules.

[1]: http://inotify.aiken.cz/?section=incron&page=about&lang=en

Thats what I wanted it for. Then a single license magically turned into 5 enterprise licenses, became impossible to cancel, and drove me away from the company forever. I mean...$750/yr to sync files?

Please dont mess up HelloSign like you did with the parent company!

It needs a lot more work, the search is horrible, and there are a number of features needed to take it to the next level. So far their feature velocity has been tepid. I like a lot of the ideas, and appreciate a viable google docs alternative, but I fear a Dropbox-level of feature development will doom Paper long term.

I'm forced to use Paper as a wiki now. Search, discoverability and extensibility is so bad that I miss Confluence....

Ouch. Have you used something in that space that is better?

Paper is excellent.