GitLab Secure Stage, 19 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Secure UX iteration review: align license classifications to user expectations

Description

00:00 - 00:30 Introduction
00:30 - 02:50 Classification review
02:50 - 05:11 Current UX in Projects license compliance section
05:11 - 07:50 Current UX in merge request (newly detected licenses)
07:50 - 10:18 Latest proposal iteration review
10:18 - 11:07 Wrap up and next steps

Issue seen in video: https://gitlab.com/gitlab-org/gitlab/-/issues/196845
A related issue, displaying out-of-compliance: https://gitlab.com/gitlab-org/gitlab/-/issues/33870

A

Hi I'm Kyle and the secure UX team and today I, want to talk about this issue called aligned license compliance, deny classification outcome with user expectations. This is about our license compliance feature, which is currently at only the project level, to understand this issue. Let's take a look at some of the contexts in the current UX and then we'll look at the proposal here.

A

A while ago, we introduced new license classifications and we deprecated that the existing or the previous classifications, which were called approved and blacklist number of reasons why we did this we removed approved because that could easily get confused with the approvals feature.

A

The merge request, approvals feature which also there's a license: check, approval and a vulnerability security check, and also blacklist trying to get away from that type of language and use something more inclusive and also just a more precise about what the outcome would be for our media purposes.

A

The the classifications we landed on are deny, which is the call to action and then denied, which is once the selection of a classification is made, allow and allowed, which is again the call to action to allow and then allowed means it's it's an acceptable license and then Uncategorized and we'll see how these are displayed in the current merge request and the project level in the future. Some other classifications that are not yet needed but may be needed later, is flagged for review.

A

This could be a case when a license has a similar match to a denied license, and we want to surface that up for a project the person responsible. We want to surface it up for their review, that it could be a match to a denied license out of policy, maybe down the road. There's additional rules, like versions of certain licenses, like maybe this ones denied, but here a conditional rule this this version- and this version are loud, but this one's not and then one time the proved would be more for auditing purposes.

A

If a denied licenses due to license check was approved today, we're going to be taking a look at what deny means, and hopefully aligning with user expectations or at least communicating to them, what to expect if they choose that classification, I'm gonna jump over to a project now and just release at the project level is license compliance to be visible and it's accessible here in the left, navigation under security and compliance, and then license compliance and we land here and we see licenses in this tab detected in project.

A

These are the raw results from license scanning and, of course, the prerequisite for that to work is that configuration is made at the project level to turn on that scanner. So these are the raw results from there and the related component and then on this screen. We have currently a maintainer view, is what we're looking at and that's why we can add the actual policies and we'll take a look at the minute, but I just want to say that a developer.

A

If they came here to policies, they will see the licenses, they won't be able to add a policy, but it's at least awareness as to what the policies are for a project where this was previously under settings where only a maintainer could see at least now it's visible to all developers- and you know- there's certainly some UI polish here to be done in future steps and we'll look at that. But let's, if I were to add a license. Let's just do that. Really quick for BSD and I just delete this really quick.

A

So I can do this for this purpose, but now I'm gonna, add a deny classification to it and then add that to the list now. The problem here is: it's really not specific and explicit in the user interface to the person who just added this policy. What exactly would happen?

A

There is some notes about that here in the documentation, but we want to be explicit in the user interface when they're, adding this policy to a line with, what's actually gonna, be the outcome of it being denied and also like I, said earlier, if a developer lands here, we want to be explicit about what that means if something is denied. So let's take a look at what that would result in okay, so right now we're looking at a merge request and some new commits have been made here that introduced some new licenses.

A

Now, just as a side note currently in the merge request, only newly detected licenses will be displayed here. It doesn't show previously if a license is already existing.

A

It'll only show newly detected there's a separate issue for that as well as we continue to iterate, because that's important, because if an already existing license is there and it's denied, we need to resurface it, which it doesn't do right now, but there's a separate issue for that as well.

A

Just wanted to mention that, okay, so we see here license compliance detected new two new licenses and we expanded this, and this is the view where it's listing these two licenses, this one, you wouldn't be able to tell from the user interface, but it's an uncaring one, meaning that neither allow or deny has been assigned to it, but this one is actually denied one again.

A

You wouldn't know from the user interface and there's an issue here, that's looking to clarify that so at least we're using headers and presenting the licenses more explicitly as to what they fell under and, most importantly, that the nine ones. So we can be explicit about that user can actually understand like why these are being surfaced to them. Okay, so going back, this one is denied now. The problem is, though, is that this is the extent to what happens. If you put a denied classification, as you can see, it can still merge this.

A

So this is not aligning with user expectations. If this is their policy to deny it, it still can be introduced into the merge requests. So that's the problem. What you would actually have to do is further deny the classification and then add a license check and even then it can be overridden and approved. So in compliance. I think what we want to do is if someone, if the user puts deny here it, should actually disallow the merge request and be explicit to the user.

A

Why the merge request is unable to move forward is because it's out of compliance.

A

Okay, so going back to this issue, that's exactly what this is focused on like in in the current UX we saw when you apply the deny policy, it doesn't actually do anything other than show the it show it newly detected in a merger quest. This is what this is, and the proposal here is to actually then disallow it and to make it explicit to the user why the merge request is unable to move forward because of the out of compliance nature of it.

A

So in this case, if a newly detected license that is denied is detected, we will surface that here and be explicit in the language err. One license is denied and then similar to our merge request. Approvals rule is explained to the user. Here with a disabled merge, you can only merge once the denied license is removed, so they understand explicitly why this is the case now in terms of going back to when we're applying the deny or allow specification for the person responsible for compliance when they're adding the license.

A

We should be explicit here about what that policy will mean. So, in this case, deny means disallow, merge, requests if detected and will instruct developer, to remove and allow it's just dating that's acceptable license in the project and then this same action. This the same expectation that is later when the user ABS. The policy is then communicated and relaid to the developer when a policy is either out of compliance or if it's loud, we can communicate this back to them. Clearly and let them know the maintainer has said it this way.

A

So this aligns the developer or communicating to the developer exactly what we communicated to the maintainer when they applied the policy and then, if again, if the I mentioned earlier, that this screen at the policy level still shows to all developers across the project, if they land here we're letting them know in this tooltip. What exactly do these classifications mean so here denied and allowed we're resurfacing that here in the tooltip, so they understand the policies better?

A

Okay, so where we're at is we're just working with our technical writers. Now, on making sure that this is crystal clear and we will add that, certainly to our documentation as well and we'll also incorporate it in this issue, where we're clarifying the results in the merge request, as well so being explicit about what these classifications mean and why they're being surfaced to the user? That's what this issue is about clarifying results in the merge request, and then this issue aligning compliance classification, denying classification with user expectations when they're adding yeah thanks for watching.

A

If you have any thoughts, questions or things we should be considering, certainly give me a shot here in the issue. Thank you.