The main vibe I’m not clear on is we all understand ‘data is uploaded to the network’, but what is the default level of privacy for data and how are the levels of exposure communicated to people?
Some specific questions to illustrate my uncertainty:
Does safe files put <myfile> do a private or public upload?
How will the CLI differentiate between doing a public vs private upload, and what will be the default ‘no flags’ do?
Is private vs public exactly mapped to encrypted vs plaintext? Or is there some idea of permissions to also account for?
Is ownership different to permissions or is it just a particular value the permissions are set to?
Is anonymous uploading a different concept to private / public uploading?
How does the visual UI currently differentiate between the concepts of public vs private, anonymous vs owned vs permissions? What are the concepts in play here, am I mixing some things together or assuming too much separation?
On the one hand we want it to be really easy for publishers to get their stuff online for others to view, but on the other hand we want it to be easy for privacy oriented people to keep their data private and help them avoid that ‘one accidental [permanently stored] screwup’. Any thoughts on how this might work?
Imo the safest thing is to always upload private. Once the data is on the network, a “publish” command would convert it to public if that is the client’s ultimate goal.
A command something like :
safe put file (local path) (remote path)
would be private and :
safe publish (remote path)
would make it public.
p.s. You could always have a shortcut command too that uploads and publishes in one shot.
safe publish file (local path) (remote path)
Whenever the publish command is used, it would be best to have a confirmation like:
Are you sure you want to make this data public? Public files cannot be removed and will be available to 3rd parties forever. Type YES in all caps to confirm…
The cooling off period should then kick in to give them a last chance to change their mind.
Edit: For people that are sure of themselves they could have a “–force” or “–now” option flag for the publish command that bypasses the confirmation and cooling off period in order publish the data immediately.
Based on some of the ui features JimCollison has presented, it seemed like the cooling off would be client side. So the upload is just cued until the cooling off period expires, and then it is actually sent to the network. (Reminds me of a print cue where you can cancel sending a document to your printer if you are quick enough.) Wouldn’t a clock timer be ok here?
OR the new owner can take the content to a new location with him as the owner. We have some options here. I like the copy option as it’s easy, but we have data types now (like the Lseq @bochaco added to rust-crdts) that handles permissions changes. That allows great flexibility.
There’s a fair bit to the user flows around all this, but i’ll do my best to describe what we’ve worked up for the UX.
First off, the default is that uploaded data will be in the private realm (this is of course notwithstanding specific public first use cases e.g. making a public comment on a blog etc).
So, adding some data would look something like this:
But of course, I could choose to drop a file into a public folder—thus publishing it. We make sure that a user is aware of this, and goes through the publishing workflow when they do:
You’ll notice that there is an As identity row in the publishing manifest in the middle. This is the identity I’m publishing as and I can swap that out if I need to. The default is to have no identity while publishing though, publishing anonymously.
I can change that default though, if I want to make it easier to publish regularly under a specific identity. I do that from the identity screen:
You’ll notice that the Publish capability has been given a rule of Ask every time. This is will be the default for apps when publishing. It means the user will be shown a consent dialog each time, prior to the file being published, like this:
Of course, once a user becomes more comfortable with an app and how it works, they might want to change that rule, so they aren’t prompted each time. That could be for a session, or perhaps permanently.
A user can also ringfence specific files, folders, or data labelled in a certain way, and give apps specific capabilities for that. E.g. don’t ask me before publishing music files, but always ask before publishing photos.
Labels can also be used to change capabilities and rules based on whether the data was created via an app, vs data created elsewhere. So as an example, that would allow someone to use a social media app to add public comments via the app without any hurdles, but have to individually consent each time they wanted to publish an existing photo.
These default setting can be set up for new apps too, so I could lock things down a bit further for new apps, and open the up later on etc.
When it comes to sharing data with other individuals things will work in a pretty similar way. I’d have a permissions manifest through which I could grant another user or group permissions to view, edit, share, publish a given set of data, and apply rules to that in the same way.
Superb Jim. The UX flows for such a complicated set of paths and options are exceptionally clean and straightforward. I can’t wait to play!
One thing I’ve been wondering about, is how people will grasp and deal with the fact that once published, data will be very hard to hide if published by accident or after a change of mind.
If shared privately, no problem you can actually delete the data.
But anything ‘published’ has a container with is entire history available, so removing its entry from the container still leaves the data accessible to anyone who knows of the container or can discover its location.
The action “publish” implies this, but uploading to a public folder definitely doesn’t because what people believe about public folders is that they don’t hold a history and effectively have an ‘undelete’ feature accessible to anyone. And tbh, “publish” doesn’t exactly make this clear either.
Q1 are there other words we could use for the action that hint that there’s more to this? Is there a word for “are you sure… do you feel lucky punk?”
Q2 should there be a bit more in the confirmation dialogue, with a link to more info?
Yup, it’s a fair point. In other publishing flows we do labour the point a bit more, so perhaps it requires more here.
It’s a fine balance between being concise and pointed so the message gets through vs. ‘T&C fatigue’ type of skipping. But I agree we should probably link through to more info on what exactly the implications of publishing are.
It’s a tough one, and I can see trying to address it could do harm in itself.
I think the problem is that of expectation - almost everything with computers has been undoable, and files and stuff on the web have never really been permanent in most people’s experience (even if folks here know a bit more about ferretting stuff out that has ‘disappeared’ than most).
Add to that the consequences of accidentally putting something out by accident, never intending it for publication and you have a pretty painful learning curve in the offing.
It’s like the: accidentally send your nude photos to everyone in your contacts list gotcha, but where “everyone” is literally “everyone forever and ever”!
It will happen of course, no matter what we do. Maybe Publish → Publish Forever will be enough to give people pause.
Although that doesn’t handle the “upload to public folder” case, which is IMO the bigger mantrap. So “Public Forever” folder?
But in this case, we’re deliberately putting the same end on the flow as you would get when publishing a file on it’s own. You get the warning dialog, and then still have to go through the Publish manifest and consent. Plus you get the timed cancellation snackbar after.
But yeah, we could perhaps do with some refining of the language.
I missed that! Although in the user’s head they are already “just putting a file in a public folder” so the words need to be aimed at jolting us out of that trance of expectation.
public library; private safe… or some such simple visual imagery?
That public is immutable is a huge difference…
I wonder most use cases might even tend to never publish because they want control over option to delete?
Which tempts whether websites would ever be able to access notionally private data?.. or does that not make sense??.. perhaps there is a use case that an intranet is wanting limited access?.. the oddity there will be that such private space would be mutable and public websites would not… maybe that is ok.
[Edit undo] is a feature and [oops no you can’t], is a new world… which has good reason but people don’t like discontinuities to catch them by surprise.
This post will be public permanently! Are you sure!? Really??! ok then.
I am certain someone will create a wrapper to allow all types of public data to be uploaded in a standard deletable way, some wrapper around the map type I suppose.
But if your account is compromised somehow then you can lose all your data. There are real risks to being impermanent too.
It’ll be interesting to see how this balance plays out, the risk of accidental permanence vs the risk of accidental deletion.
There may be an opportunity here to present the user with icon cues that represent permissions types and impacts. After initial familiarization/education, these icons can clearly and unobtrusively convey that information instead of displaying important text that will be ignored as T/C. These icons can be used frequently in workflows without overloading the user with text.
The visual in my mind depicts the relationship between data and access. Examples: owner/data, owner+other users/data, owner+world/data.
If the user does not know or forgets what an icon means, then selecting the icon presents the detailed explanation.
“default safe”.
