Change in the way Gravsearch results are filtered according to permissions

Following the discussion in issue 1344, and further discussion with @lrosenth, we’re going to change the way permission-checking affects Gravsearch results.

Currently, if the Gravsearch WHERE clause mentions a value that the user doesn’t have permission to see, we return ForbiddenResource. The rationale for this was privacy-oriented. For example, if you’re not supposed to know that a painting sold for a million francs, it isn’t enough just to hide the price. You also shouldn’t get that painting’s title in the results of a search for the titles of paintings that sold for a million francs or more.

This creates problems, though, as discussed in the issue, and in any case, since we can’t filter by permissions in SPARQL, it’s not really possible to make this policy work as it should. For example, if you want to know the price of Van Gogh’s painting A Wheatfield with Cypresses, you can just do a count request, to get the number of paintings that have that title and whose price is at least X, and keep increasing X until the count is zero.

Therefore we’ve decided to change the policy as follows: the purpose of permissions on resources and values is to respect copyright, not to protect privacy. An example of the intended use case would be that you can find out which texts contain the word ‘science’, even if you don’t have permission to read the texts. Gravsearch will filter results the way the /v2/resources route does: if you asked about a value that you don’t have permission to see, Knora will return the resource without that value.

@loic.jaouen
@mrivoal
@gfoo

2 Likes

Thanks for keeping us updated!

Do you already know when the implementation of this change is planned ?

@t.schweizer Could you help me with this in November?

Yes, absolutely! First half of November would be better because I will be busy with moving at the end of the month.

@benjamingeer, @t.schweizer do you think this could be implemented in the next release (2019-11)?

Because @gfoo needs it quite soon for Lumières.Lausanne application. We can’t have his application tested by users unless this is resolved because the current behavior would make the existing data look inconsistent for users.

I should be able to work on this with @t.schweizer next week.

@t.schweizer do you have time to start on this without me?

That would be really great. Many thanks.