Clarify checkbox tooltip text

[richlander]

Some packages have a tooltip, like these two:

• https://www.nuget.org/packages/Microsoft.Net.Http/
• https://www.nuget.org/packages/Polly/

As a user, I expect this to mean something similar to twitter. The twitter concept is "Verified account", per twitter.

The tooltip on the NuGet.org checkmark reads:

The ID prefix of this package has been reserved for one of the owners of this package by NuGet.org

That is a lot of context to digest to determine what it means. The real question is how that text should provide a NuGet user with increased confidence in using the given package. I cannot answer that question. To me, all it says is that the Microsoft. or Polly. prefix has been reserved but I don't understand any of the requirements that come with prefix reservation that lead to me giving increased trust to a package.

I wouldn't expect that prefix reservation would a primary concept to expose to NuGet users, but that it would be one of the requirements of the checkbox.

Instead, I would expect the checkbox to mean the following:

The package is coming from who you think it is coming from

Maybe the text could be:

This package was published by one of its owners

[anangaur]

This package was published by one of its owners

All packages should be published by one of its owners. Otherwise, as a consumer, I would be alarmed 😄

[anangaur]

What about:

The owner of this packages has the 'Microsoft' prefix reserved

[richlander]

All packages should be published by one of its owners. Otherwise, as a consumer, I would be alarmed

True, but that's the analog of what the twitter checkbox means. The checkbox for shanselman means, "these tweets were published by the validated owner of this account". Perhaps it is the validated part that is different.

I don't know how reserving a prefix relates to trusting this package. It would be more helpful, but still odd, to say "The owner(s) of this package has 2FA enabled". I understand how that relates to trust.

Can you describe to me, or point me to the doc, that explains how prefix ownership relates to trust in a substantive way?

[anangaur]

There is history behind it. Taking an example of Microsoft.<package>, without the reservation feature anybody could have published such a package and there are quite some packages like that. Once we enabled the prefix reservation feature, now only microsoft account can publish a Microsoft.<package> id to nuget.org. But the older packages with Microsoft. prefix remain on nuget.org. So now when a consumer looks at a package with ID: Microsoft.Foo, the presence of the a checkmark helps the consumer trust this package as it states that it was indeed published by owner microsoft. Does this make sense?

[richlander]

the presence of the a checkmark helps the consumer trust this package as it states that it was indeed published by owner microsoft. Does this make sense?

Yes. It's very close to what I proposed, and doesn't include the word "prefix"! We need to come up with an explanation that doesn't include this term.

[shanselman]

I agree and I think @richlander has a point here

[anangaur]

I understand that “prefix” adds to the complexity in comprehension but sadly that’s what we do as part of this feature. We do not verify package, nor the publisher (may be to some extent). Lets see if we can refine to a better text without the work “prefix” in it. Will get more eyes on it.

[richlander]

I understand, but maybe it's not the right design point. It's not too late to re-consider the basis of this UX. I like the prefix concept, but to make it the only requirement and the fundamental basis of a checkmark is the problem. That's the part we need to change so that the text writes itself.

I'm in a neighboring team, and cannot grasp this, so imagine how @shanselman's "dark matter" developers must reason about this feature. Fortunately, they don't likely read the tooltip, so they go on their merry way taking away their own conclusions on the chechmark.

[anangaur]

Yes. This I can agree with 😈. It’s not just the text that needs change but we may need to relook at the feature itself. While talking to a few developers (during developer day), we found that many didn’t even realize the presence of the checkmark itself and those who did couldn’t explain what it meant. We do plan to do customer development to understand this better in the next quarter.

[richlander]

I just spent 20mins trying to come up with better text. I've concluded that the text cannot be improved given the design of the feature.

If I think about this feature in its most base form, it is saying this:

The Polly.Extensions.Http package has the same owners as the Polly package.

That's obvious if you take the time to look.

In the case of Microsoft, there is no Microsoft package, but there are other packages that users know to trust because we link to them in our blog posts, and they are free to a diff owners of other packages.

The prefix feature is really just a defense-in-depth feature to enforce that this is the case. Like all "x-in-depth" features, it's not something you can explain.

I think that the checkmark should be removed from the gallery. It's not really describing an interesting trust relationship. It's only saying what I described above.

What would be useful, and this is where defense-in-depth comes in, is to have an anti-checkmark on packages where the owners don't match the prefix owners. That would give users a clear idea that they should maybe apply a little more scrutiny to their choice. I know that's not perfect, but that's a clear use case of the prefix feature that provides more direct user value.

[anangaur]

What would be useful, and this is where defense-in-depth comes in, is to have an anti-checkmark on packages where the owners don't match the prefix owners.

👍🏽This is already planned. It’s also something we need to do for trademark reports which is related to prefix reservation. Currently we have deferred this to our effort to revisit the checkmark customer development. In my mind, this along with a checkmark (or it’s derivative) for verified owners (not packages) combined with showing owner name based on CN name for signed packages seems to be the way to go. Again, these are hypotheses regarding package trust that need further work, validations.

[richlander]

K. I'll close this issue. I don't see anything actionable for now, however, please take this whole conversation as more customer feedback.

[anangaur]

I would keep this open as the core issue that the text is neither clear nor easy to comprehend, is not resolved. Let me rename it, though.