Whe we share a space, we must be able to choose whether this space is exportable or not
HOW COULD IT BE DONE?
Add an option “Set space as exportable”.
Like Notion (no time to find the option this morning, but Notion allows you to authorize or not the duplication of a space)
REAL WORLD USE CASES
I don’t really need this for me but in many case we may want to share a space without giving it to our guests.
If I share a “My trips” space, it’s not so that anyone can export it.
In the corporate world, as pointed out by @MikeyPhere, it’s also important to control data: an (ex-) employee shouldn’t be able to simply “export” all the data to himself!
We can also imagine an art gallery to be visited, not given away, etc.
Export remains useful in other cases, of course.
This is a bit unorthodox in this community but I would like to provide a counterpoint to this feature request. I think the current behavior is exactly how it should be and should be preserved.
Platforms that try to hide the fact that users can in fact just grab all the data often end up in users being surprised when exactly that ends up happening. Any user with the smallest amount of technical expertise or a bit of free time will be able to export all the data from a shared space. This is true for other platforms like Notion or even something like Discord as well. There’s no actual way to stop data sent to a person from being saved by that person. You COULD slow them down, for example in cases like Discord there are rate limits to how many messages can be queried over a short period of time, but that’s merely a speed bump not a roadblock. And even that speed bump is not realistic with the way AnyType shares its data between users, end to end encrypted.
If this feature was implemented all it will do is give people a false sense of security, that they can just pull the access from their employees at a moment’s notice. And it will not stop malicious actors from creating malicious clients that don’t respect “delete this data” requests. What’s best in this case is to keep the risk very blatantly clear like it is now and to educate users.
Agreed with @Mathspy. I think any information accessible by potentially untrusted actors (coworkers who can be fired) should be treated as exposed to public.
There is the same problem with codebases in smaller companies, when coworkers do git clone to their local machines. You can’t control what happens with the codebase after they are fired.
A measure of protection against leaks is NDA, but again, it will not undo leaks. So it’s probably better when we treat any such information as potentially leaked or abused.
Coda do a pretty good job of this if you want an example.
I absolutely need to be able to choose whether an editor or a viewer can export the entire space or not. I have employed many people and it’s important to remove their access to potentially sensitive data or intellectual property or ideas held by the company. For many years I have had a policy where if an employee leaves the company (whether resigned or fired), we immediately remove their access to company software , Google drive , air table etc. it’s important.
Even If we want to give access to our space, we can do so in Read-Only Mode. Like how the file permission works in Linux.
Like how aws IAM works.
Give least amount of permission. Can only read the content but is not able to figure out the relation between objects and how the space is created.
I would like read only and editor options but the ability to restrict full space downloading in both cases (maybe it’s an option the space owner can decide ).
And with regards to users being able to download it after their usage has been revoked - HELL NO. ABSOLUTELY NOT!
And another point. What is the point of the encryption Anytype aspires to if people can just freely download your entire space !
Any user with the smallest amount of technical expertise or a bit of free time
This is exactly the point. The overwhelming majority of people on the planet do not have the technical expertise to do this.
And this is why friction is very important. Making a space ‘non-exportable’ adds friction. Most of the time, a little bit of friction is enough to discourage people from doing something. It’s not a perfect solution, but it helps. Thinking about shared spaces by organizations, with thousands of objects, this friction makes a huge difference.
Although I was expelled (“removed”) from his Space I was able to export his Space. :-/
In my humble opinion this definitely shouldn’t be this way!
If we expel one of our Viewers (or even Editors) there will be in most cases a good reason for it.
As Space owner we should have the option to allow / disallow him the export, at least in the moment we expel him.
And “disallow” should be pre-selected.
In past I have experienced some trouble with once “trustworthy” business partners.
In the moment you realize that someone betrays you, you definitely want to restrict any further damage he could do. Immediately!
That such a false friend may have older files from our Space is one thing an bad enough.
But in the moment we kick him from our Space we need to have an option to block him from downloading a last time the freshest content from our Space.
In this dialogue …
… there could be an additional checkbox: “Allow the user for a last time to download the whole Space”
(or something like that.)
I’m agree that all information can be copied/recovered/stolen by visitor.
But here, we propose to do it directly for the visitor.
In a company, when someone leaves, you get a pop-up saying “Hey, you’re fired, do you want to steal all the data? We’ll export it for you in one click”.
Clearly, I wouldn’t deploy this in my business (not to mention RGPD, PSSI, etc.).
And personally, I would think twice before personally sharing anything (if that’s what you want, you’ve got it ;-)).
The solution proposed by Notion seems relevant to me…
I suppose any restrictions after kicking members out of space is meaningless… since they can simply go offline and export or copy, then Anytype don’t receive the ‘kicking instructions’
Perhaps restrictions need to be placed before entering into space
Or only authorisation for a certain period of time, and must be reviewed to continue accessing.
Alternatively, I asked if it is possible to allow access only when owner/editors are online.
P.S. These days even if we have copy preventing mechanisms, we have OCR which makes it very easy to ‘steal’…
There are indeed ways of stealing, but it’s like any law, any rule after all (and I leave it to everyone to draw the parallels they wish).
But in business (from a system admin/ ciso’s point of view) :
it can have repercussions (disciplinary and legal).
users sign charters.
we have control tools in certain cases (and clearly, no, exfiltrating a large knowledge base isn’t done “by accident” or easily).
Except that in this case, Anytype “gives” the data to the visitor. Why not, it’s a philosophy, no more problems of theft, responsibility, charter or private data, it’s a gift.
Accept or not, depending on needs and constraints.
In fact, you might want to make it clear when you share:
“Warning: your data will be given to the user, even if he or she opts out
Continue / Stop"
Edit…
Et tu as raison, surtout en voyage, si un voleur veut ton matos, il y arrivera, le deal c’est avant tout de ne pas lui envoyer une invitation !
And you’re right, especially when traveling, if a thief wants your gear, he’ll get it, the deal is above all not to send him an invitation
Just seen on a photo forum, about bag theft… it reminded me strongly of this topic here
Exactly! And also, in this moment when they have just been kicked out of the space, is potentially exactly when they will be thinking of doing something like stealing all the data - especially if they haven’t left on good terms for whatever reason
I’m commenting on this as someone who, as a freelance project manager, has been going in and out of different organisations since about 1990, ranging from small business with about 10 employees to major international corporations with tens of thousands. I learned many things about sharing data, but one above all - only share with people you can trust. If you want them to be productive they have to have access; if they have access, they can steal it.
Nothing wrong with making it harder to copy/share, but that’s a waste if you can’t trust them in the first place
And yes, of course you trust team members when you invite them to share the space, and while they are part of your team. But once they leave, it could very well be a different story.
For shared spaces, if the purpose is to provide a “viewer” (i.e. not editor) option, then that purpose will be meaningless if the viewer can export the entire shared space and import all the data back into the viewer’s own vault.
Because all material is replicated/plundered and available for editing by the “viewer”.
Of course, we cannot 100% prevent shared space/data from being replicated, but disabling the export function of shared spaces can certainly significantly reduce the possibility of data leakage.
I support to disable the export function for a shared space.
Or, at least allow the source owner to make the decision allowing export space or not.
This is a very tricky problem, rooted fundamentally in what it means to have a local-first p2p sharing model. It’s not obvious (to me) what the correct solution is, for reasons that @Mathspy has articulated.
While Anytype could try to add “friction” to prevent exports, it’s important to keep in mind that some other client side software that could easily scrape content from a shared space. Such a software might actually not be too hard to write, and in a future where Anytype becomes popular such software might almost surely be available. So we need to think deeply about what it even means to “revoke access” conceptually. If you trust and share a secret with someone, you cannot later make them forget it; they can forever hold a copy in their mind (or some other storage medium). I don’t see a better answer right now.
Cloud-based software manages to “revoke access” only because the data is stored in the cloud (on someone else’s computer). The same mechanism that allows revoking access to someone else also allows revoking your access to your own data. The current p2p model behind Anytype makes it conceptually/fundamentally hard to revoke access once you have granted access to some data – and that is necessary for ensuring that your access to your own data cannot be revoked.
Just because it’s possible for someone to steal your data, doesn’t mean you should invite them to. It is absolutely ridiculous that when someone leaves a shared space, they are immediately presented with an option to download (aka steal) all of the data.
It is not a tricky problem. Just don’t send the download invitation!
The vast majority of people don’t know how to code, or scrape data or anything like that. The vast majority of people aren’t going to steal your data either - but, if they leave on bad terms, and then they’re immediately invited to freely take whatever data they want, and crucially, they are given this invitation at the very moment they leave, then they are more likely going to take it.
Yes, ideally, once access is revoked, they should of course lose all access to the data, but until this is figured out, they could, please for the love of god, at least not send them an email explicitly inviting them to steal all of the space owner’s data.
Agree.
That would be easier.
As a company, having a package with all the data offered when you leave.
For movies or games, a link to download them.
With this, goodbye piracy and spying, a new era.
Anything that can be stolen has to be offered. Does that apply to material objects too? Cool.
I’m joking of course, I’ve already given my opinion above (understood as a professional).
I stand by my position: “I can” doesn’t mean “I have the right” and I want to be able to not give that right.
