As of 7.9 and thanks to GDPR we now have the notion of "Sensitive Data" for member fields (https://our.umbraco.com/documentation/Reference/Security/#sensitive-data).
I would like this rolled out to properties on Doctypes.
I'm not sure on how this was achieved for members but wondered if the same code could be rolled out to more areas of Umbraco? I'll be having a poke around in the commits to try to get my head about what this might involve.
My driver for this is our GraphQL work, we ideally want to make all the properties public but hide the sensitive ones (you wouldn't for instance want the cost price for an Amazing Japanese Kitchen Knife being available via your public API. If we could flag those fields as sensitive then GraphQL would know automagically not to make them public by default.
It would add another level of protection from fields leaking out where you might not want them.
Anyone got any thoughts on the viability of this one?
Interesting scenario, and I'm sure it would be possible.
I can't help thinking though that it feels to me to be a different use case and at this level, it's more about granular permissions for you API, than it really is about "sensitive data" from a GDPR perspective. I'm not saying it's a bad idea, I'm just wondering if it's the right solution for the issue you face?
Same thoughts, as in why wasn't it available for content/media - and yup, I haven't needed it either.
BUT I like the idea, Pete!
I agree with what Matt said about the intent of such feature. I'm thinking a more generic "property wrapper" approach (with checkbox, or whatever) could be something?
Not sure the example quite falls into the GDPR zone but totally see it being useful. Sounds more like a private property flag than a sensitive data (ala GDPR definition) property flag.
If data is sensitive, it would ideally be encrypted when stored at rest and only visible to users whose roles allow it in the backoffice. A private data flag at least for the way you intend it Pete, might need to be treated differently.
This is not the "you're doing it wrong" post.. or is it?
I find the example a little bit worrying: you're storing data that is not to be public in something that's eventually called PublishedContent.
This always worries me, there's only a small little thing that needs to happen to make this go wrong:
An editor puts the price in the wrong field
A developer puts the wrong field in a template
A developer didn't realize their RSS feed would include the private info
They didn't realize their GraphQL API would contain this info
They forgot to mark this private field as private and it leaked anyway
I know there's a million reasons of where you'd want to put this info in there but all levels of misdirection are (as usual) only as strong as the weakest link (in this case, the human factor).
Background: "sensitive data" was always meant as some help to prevent users with Umbraco access to view certain data (yes, also vulnerable to the "human factor") or export certain data.
It was never meant for this type of usage and I doubt if it would be great to use it as a way to prevent data that you're publishing from being published.
To take this even further, you're bound to confuse the editors as well: "when I click the Save and Publish button, I make everything I just typed public... except that special property "X" 🤔".
Don't get me wrong, I'm all for good hacks, but this is a difficult one for me.
Some excellent response on here folks, thanks for chipping in.
Just to be clear this isn't a GDPR thing more a "how can we leverage whats already there" thing (if we can at all).
More I ponder it the more I think a separate solution is the right way to go. This is a good thing but also causes me some headaches. We've built a rough and ready UI in a dash board to manage which fields should be public for our GraphQL work. Its enough to prove the point and get someone up and running real fast.
The more I think about it and work on it the more I think that this could be useful for any API really so I'm pondering pulling this out into its own package ("API Permissions for Umbraco") or something like that. This is again meta data about data, a common theme it seems.
So if the price example is to flakey for you then how about this one. In one of our client sites we have about 150 fields that you can use for a doctype (A hotel in this case). Some of which make little sense being exposed on the website or to a 3rd party who might be consuming our endpoint. Why clutter up the schema with a tonne of fields that will never get used (although they have internal meaning to us which is why they are there). So you could hide those fields from the schema of your API and make it nice and lean and to the point. That's the sort of thing we are aiming for, a quick UI that lets you choose which fields you want to expose.
So far we've got the idea of Accounts (think of these are users of the API) which in turn can have Account Settings (which fields can each account see and what can they do with it). You can have different permissions on a field (read or write or none). For now we are just rolling out with a Default user that you have to opt into which fields they can see, out of the box for now they won't see anything you have to use checkboxes via our UI to enable fields. The ground work is there and in to allow us to have different users with different permission (so you could update data for instance if you had the access rights and pass in a token).
My thinking with trying to leverage what was already there was to see if we could quickly make some informed choices about which fields we could whitelist automatically to save you having to click hundreds of checkboxes. We could do a bit of this already but allowing you to make Compositions public or certain common fields (bodyText, nodeName, id, etc.) out of the box. For now though we will go the simple root of you have to opt in for everything.
Some great discussions this week. One of the things I loved about retreat was chats like this, the best ideas come from a seeding of an idea and then having multiple people chime in with their experience and thoughts. For that I thank you :)
Could we have "sensitive data" flags for doctype properties?
As of 7.9 and thanks to GDPR we now have the notion of "Sensitive Data" for member fields (https://our.umbraco.com/documentation/Reference/Security/#sensitive-data).
I would like this rolled out to properties on Doctypes.
I'm not sure on how this was achieved for members but wondered if the same code could be rolled out to more areas of Umbraco? I'll be having a poke around in the commits to try to get my head about what this might involve.
My driver for this is our GraphQL work, we ideally want to make all the properties public but hide the sensitive ones (you wouldn't for instance want the cost price for an Amazing Japanese Kitchen Knife being available via your public API. If we could flag those fields as sensitive then GraphQL would know automagically not to make them public by default.
It would add another level of protection from fields leaking out where you might not want them.
Anyone got any thoughts on the viability of this one?
Interesting scenario, and I'm sure it would be possible.
I can't help thinking though that it feels to me to be a different use case and at this level, it's more about granular permissions for you API, than it really is about "sensitive data" from a GDPR perspective. I'm not saying it's a bad idea, I'm just wondering if it's the right solution for the issue you face?
I was a bit confused as first when this was only added for members, but not for content and media types.
I haven't had a need for it yet though, but I think it makes sense to add support for content and media types as well.
Same thoughts, as in why wasn't it available for content/media - and yup, I haven't needed it either.
BUT I like the idea, Pete!
I agree with what Matt said about the intent of such feature. I'm thinking a more generic "property wrapper" approach (with checkbox, or whatever) could be something?
In terms of packages, I've seen this done recently on this package: Nullable Types: https://our.umbraco.com/packages/backoffice-extensions/nullable-types/ ... although it's not wrapping existing properties.
Good ideas!
Cheers,
- Lee
Obligatory cross-linking to your Property Decorators thread...
https://our.umbraco.com/forum/umbraco-8/92510-could-property-type-decorators-become-a-thing
...which I meant to respond to at the time, (but didn't, curses time!)
Not sure the example quite falls into the GDPR zone but totally see it being useful. Sounds more like a private property flag than a sensitive data (ala GDPR definition) property flag.
If data is sensitive, it would ideally be encrypted when stored at rest and only visible to users whose roles allow it in the backoffice. A private data flag at least for the way you intend it Pete, might need to be treated differently.
This is not the "you're doing it wrong" post.. or is it?
I find the example a little bit worrying: you're storing data that is not to be public in something that's eventually called
PublishedContent.This always worries me, there's only a small little thing that needs to happen to make this go wrong:
I know there's a million reasons of where you'd want to put this info in there but all levels of misdirection are (as usual) only as strong as the weakest link (in this case, the human factor).
Background: "sensitive data" was always meant as some help to prevent users with Umbraco access to view certain data (yes, also vulnerable to the "human factor") or export certain data.
It was never meant for this type of usage and I doubt if it would be great to use it as a way to prevent data that you're publishing from being published.
To take this even further, you're bound to confuse the editors as well: "when I click the Save and Publish button, I make everything I just typed public... except that special property "X" 🤔".
Don't get me wrong, I'm all for good hacks, but this is a difficult one for me.
Some excellent response on here folks, thanks for chipping in.
Just to be clear this isn't a GDPR thing more a "how can we leverage whats already there" thing (if we can at all).
More I ponder it the more I think a separate solution is the right way to go. This is a good thing but also causes me some headaches. We've built a rough and ready UI in a dash board to manage which fields should be public for our GraphQL work. Its enough to prove the point and get someone up and running real fast.
The more I think about it and work on it the more I think that this could be useful for any API really so I'm pondering pulling this out into its own package ("API Permissions for Umbraco") or something like that. This is again meta data about data, a common theme it seems.
So if the price example is to flakey for you then how about this one. In one of our client sites we have about 150 fields that you can use for a doctype (A hotel in this case). Some of which make little sense being exposed on the website or to a 3rd party who might be consuming our endpoint. Why clutter up the schema with a tonne of fields that will never get used (although they have internal meaning to us which is why they are there). So you could hide those fields from the schema of your API and make it nice and lean and to the point. That's the sort of thing we are aiming for, a quick UI that lets you choose which fields you want to expose.
So far we've got the idea of Accounts (think of these are users of the API) which in turn can have Account Settings (which fields can each account see and what can they do with it). You can have different permissions on a field (read or write or none). For now we are just rolling out with a Default user that you have to opt into which fields they can see, out of the box for now they won't see anything you have to use checkboxes via our UI to enable fields. The ground work is there and in to allow us to have different users with different permission (so you could update data for instance if you had the access rights and pass in a token).
My thinking with trying to leverage what was already there was to see if we could quickly make some informed choices about which fields we could whitelist automatically to save you having to click hundreds of checkboxes. We could do a bit of this already but allowing you to make Compositions public or certain common fields (bodyText, nodeName, id, etc.) out of the box. For now though we will go the simple root of you have to opt in for everything.
Some great discussions this week. One of the things I loved about retreat was chats like this, the best ideas come from a seeding of an idea and then having multiple people chime in with their experience and thoughts. For that I thank you :)
is working on a reply...