Opinions sought: Too much info on tag usage available to styles?

[swaldman]

I've been working on Bug 1723, and while doing that I've noticed something that I don't think is right.

The following information on tag usage is exposed to the style system (via the TagDetail class):

1. use_count: The number of times that the tag in question is used in the journal (at present it's the total number of times, but bug 1723 will most likely change it to being an approximation of the number of times that it's used in posts that the current user can see. This isn't important now :-))
2. visibility: The most-relaxed security level that the tag is ever used in.
3. security_counts: How many times it is used at each security level, including security levels that the current user does not have access to.

(1) is fine, and is used by all styles (there is a privacy leak at present, but bug 1723 is meant to fix that)
(2) seems like info that styles don't really need to know, but it can't hurt
(3) concerns me, because it exposes information that the current user shouldn't have.

For example, let's say that user A has not been granted access by user B. User B posts a lot with the tag "hatemyboss". Most of these posts are protected or private, but one of the posts is public. Because of the public post, user A is able to see the "hatemyboss" tag. If user A were to go away and write his own style that used the info in (3) above, he would be able to find out how often user B has used "hatemyboss" in protected, private and filtered posts.

I'm told that none of DW's official styles use the info in (3). This doesn't mean that a custom style doesn't use it somewhere, on DW or another site using the code.

I think that there are three options:
(a) Leave things as they are
(b) Stop exposing the security_counts variable to the styles system
(c) Keep the variable, but force all the values to zero

I prefer (c), because it deals with the privacy issue without totally breaking any custom styles that use this information. We could add a note in core2.s2 explaining what is going on, and maybe remove the variable totally in a year's time or something.

What are other peoples' opinions?

If anybody wants to have a look for themselves, search for:

• "class TagDetail" in core2.s2
• "$t->{security_counts}" in S2.pm

Comments

[ninetydegrees]

visibility is used as a CSS class in Core2. I'm not sure what the point of having it there is but I can imagine someone wanting to highlight protected or private tags for some reason.

If security_counts may only be used in custom Core2 styles, I seriously doubt anyone actually uses it so I would vote for b). The question is what about Core1? Because I seem to remember it as something from LJ styles.

c) is a good compromise but c) is also leaving something which is useless and doesn't really work which *winces* isn't very good policy, I think.

[jjhunter]

For context, I would look at the post & comments section of Default security settings for tags @ dw_suggestions. Also consider that when someone is on the 'Manage Tags' page, those stats re: how often a particular tag is used at a particular security level can be very helpful.

[swaldman]

Thanks for the points.

The changes mooted here apply only to what information is available to the Styles system, and thus to pages that are displayed in the user's selected style. The info would still be available to unstyled Dreamwidth site pages such as Manage Tags, so that page wouldn't be affected.

The issue is that at present, much of the information that is available to the journal owner in Manage Tags could be available to *anybody* if they wrote their own style to display it.

I hope that's clear, but if it's not then please say!

[dreamatdrew]

You are missing an option here, which we shall now refer to as Option D: Enforce the access restrictions returned by security_counts. (In my mind, this returns a '?' if a user attempts to see information they are not privy to, kind of explicitly saying "Um, and how am I supposed to figure that out?", without providing false information.)

[swaldman]

Good point! And I feel a little stupid for missing it.

We can certainly do that for public/protected/private counts for very little cost. We can't do it for access filter groups, because we don't have the information needed, and can't get it without an expensive database query.

Unless anybody has any other strong feelings, what I'll do is only return the security_counts for access levels that the current user can see, with the exception of access filter groups. Levels that the user can't see will have their counts set to zero. I'll set security_counts->{groups} to zero regardless, because it would be (and already is) meaningless due to double-, triple- or multiple-counting posts that appear in multiple groups.

Unless anybody points out a flaw in this plan before tomorrow I'll roll this into the related pull request that is already in Fu's queue ;-)

EDIT: Set stuff to zero, or leave it undef? Would undef stuff break styles?

RE: Zero vs UNDEF

[dreamatdrew]

Yeah, that's why I thought to set unknown to literal '?'. It sends a clear signal that you are not being presented with information and is not giving wrong information.

Re: Zero vs UNDEF

[marahmarie]

Quick question: on the tags page (this thing:http://marahmarie.dreamwidth.org/tag/) is this going to change what we see now while logged-in? I'm currently styling all the non-public-security-level counts bold and black and italicizing the number of uses* (see note) of each in red so I (and all others granted access to those posts) can find them easily (I have almost 300 tags, which necessitates highlighting the few locked/private posts any way I can so it doesn't take days to figure out what or where they are - it's truly the only filing system I've ever had on my blog, and I'd go crazy without it).

If this change won't affect what we, the actual users see, then whew, OK...but if it will affect what we see, how so and what should we do to work around it?

Note: I'm actually using the :after content: "" property/value in my CSS to write in the words "access-only" and "private", then styling those in red/italic to make finding those posts easier...which is why this whole topic is kind of a big deal to me.

Re: Zero vs UNDEF

[swaldman]

Hi marahmarie!

The actual numbers on the tags page are due to change with bug 1723. At present they show the total number of posts with that tag; once the patch is in they will show (approximately) the number of posts with that tag that are visible to the current user. If I'm understanding right, that shouldn't affect you.

As to your highlighting of non-public tags, that depends how you are getting that information. If you're getting it from the "visibility-something" class of the li elements of the tag list, and using CSS to do something with those, then no - they won't change.
The only way that you would be affected is if you are actually using your own S2 style (as opposed to just CSS) to process things, and were using the security_counts data structure.

Hope that's clear, and that it reassures?

Re: Zero vs UNDEF

[marahmarie]

At present they show the total number of posts with that tag...

Yes, I know! I was perusing the tag list of someone on DW a while back who granted me only limited access, so she had, say, four posts under the tag "sex", but I could view only one post tagged thusly; three posts under the tag "going crazy" but I could only see two of those posts, and so on. It was sort of maddening. That was months ago and how I came to find out (long before the bug was filed) that something is wrong with our tag system.

("Wrong" in the sense that we shouldn't be seeing total counts for tags we don't have full access to. If I can only see one of four posts tagged "foo" on someone else's journal, then the tag count should read "1" while I'm logged in and looking at that journal - seeing there's four posts with that tag but only being able to read one of those posts tells me I'm not seeing three other posts with the same tag, which I can call as either a system error or a privacy leak - but knowing how DW's tag system works, I can safely assume it's always the latter.)

As for how I'm pulling and designing the tag security levels, it's entirely through CSS. There's nothing in my s2 to address it specifically - that's among the reasons why I thought I'd get a clarification, since I'd need to know what Plan B would be otherwise. Thanks for the reassurances! :)

Re: Zero vs UNDEF

[swaldman]

No problem :-)
If you're curious, I've done a post explaining exactly what will change over on dw-styles. It's at http://dw-styles.dreamwidth.org/22250.html.

Re: Zero vs UNDEF

[marahmarie]

Thanks for the heads-up and the link...it's people like you who make me love being on DW.

[momijizukamori]

Hmm. I guess the question is 'what happens when you call print on an undefined variable?' which I assume either 1) prints nothing (okay) or 2) causes the S2 compiler to choke and die (not okay). I don't think core2 calls it in a way that would print the undef value, and I doubt any of the seven or eight styles that override major parts of core2 do either, but a custom style might.

We do use some form of undefined in other places in core2, though, usually in if() statements checking if an object exists (where defined/undefined ends up being a boolean, basically).

If you want I'll be on IRC tonight (PST) and I've been poking at a lot of core2, and if kunzite is on, he's been doing S2 since it was live on LJ

[momijizukamori]

So posting a follow up to this, swaldman and I did a quick test, and an attempt to print an undef value just prints nothing, without S2 erroring. So I suggested we set values the user can't see to undef, so if anyone wants to write further functions that use the array, they can just use it straight up as a conditional (as undefined is a 'false' return) to select stuff to print for view, without having to check for equality with a value. This way it's kind of like the screened comment count implementation, where if you don't have access to see the screened comments, the comment count just flat-out doesn't exist for you in S2 - you get no value back.

[swaldman]

Sorted! Thank you for all the comments. I shall do a post to dw_styles to explain what will change - although since half of it didn't work to start with (and is now fixed), I'm fairly sure that nobody actually used this stuff anyway...