Sensitive flagger data is exposed via chat WebSockets (and possibly /events), allowing "private" flags to be publicly visible

Question

So, after I figured out that I could see who starred a message (highly related), I figured I might be able to find out the flagger of a message too. So I tried. Here's some data from my logs:

hichris is about to flag

{"event_type"=>1, "time_stamp"=>1398388054, "content"=>"Flag now?", "id"=>28079239, "user_id"=>10308
1, "user_name"=>"hichris123", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>15148938}
{"event_type"=>1, "time_stamp"=>1398388055, "content"=>"k", "id"=>28079240, "user_id"=>103081, "user
_name"=>"hichris123", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>15148939}

Here's where hichris flags.

{"event_type"=>9, "time_stamp"=>1398387950, "content"=>"@Doorknob This is <i>so</i> offensive.", "id
"=>28079242, "user_id"=>103081, "user_name"=>"hichris123", "room_id"=>11540, "room_name"=>"Charcoal
HQ", "message_id"=>15148916, "parent_id"=>15148878, "message_edits"=>1, "message_flags"=>1, "show_pa
rent"=>true}

Now he reports the fact that he flagged...

{"event_type"=>1, "time_stamp"=>1398388067, "content"=>"There.", "id"=>28079244, "user_id"=>103081,
"user_name"=>"hichris123", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>15148941}

Now I handle that flag as invalid:

{"event_type"=>9, "time_stamp"=>1398387950, "content"=>"@Doorknob This is <i>so</i> offensive.", "id
"=>28079245, "user_id"=>59776, "user_name"=>"Doorknob", "room_id"=>11540, "room_name"=>"Charcoal HQ"
, "message_id"=>15148916, "parent_id"=>15148878, "message_edits"=>1, "message_flags"=>1, "show_paren
t"=>true}

And I thank hichris

{"event_type"=>1, "time_stamp"=>1398388074, "content"=>"Thanks!", "id"=>28079247, "user_id"=>59776,
"user_name"=>"Doorknob", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>15148943}
{"event_type"=>1, "time_stamp"=>1398388077, "content"=>"(marked as invalid :P)", "id"=>28079248, "us
er_id"=>59776, "user_name"=>"Doorknob", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>
15148944}

Now I am examining my logs, which is the stuff you're looking at now

{"event_type"=>1, "time_stamp"=>1398388080, "content"=>"Examining logs", "id"=>28079250, "user_id"=>
59776, "user_name"=>"Doorknob", "room_id"=>11540, "room_name"=>"Charcoal HQ", "message_id"=>15148946
}

And then:

PearsonArtPhoto arrives and flags as invalid (setting message_flags to 0, since he's a mod).
It's *highly* troubling that I can figure this out.

{"event_type"=>9, "time_stamp"=>1398387950, "content"=>"@Doorknob This is <i>so</i> offensive.", "id
"=>28079251, "user_id"=>3087, "user_name"=>"PearsonArtPhoto", "room_id"=>11540, "room_name"=>"Charco
al HQ", "message_id"=>15148916, "parent_id"=>15148878, "message_edits"=>1, "show_parent"=>true}

The implications of this is that anyone with 10k rep can see supposedly "private" flagging information. Anyone can see who flagged a message, who flagged as valid, and who flagged as invalid. This is a major problem.

I'm fairly sure that the WebSockets work the same way that /events does. I still haven't figured out the right timestamp to send, but if I'm right, this means that anyone can see all flags ever made.

(This is a separate post from the "seeing stars" post because 1. it's about a different mechanic, 2. it's much more urgently in need of fixing, as it exposes potentially privacy-violating data, and 3. it may be fixed in a different way (hopefully sooner).)

Here is the conversation about this in chat.

Can this be fixed, preferrably as quickly as possible?

Answer 1

Apologies for the delay in answering: sometimes things slip through cracks; triage is not perfect.

The behaviour is unfortunate, and I will endeavour to investigate and remedy this.

Note: an initial glance suggests that "flag for moderator attention" flags are not impacted by this. Only spam/offensive. Likewise, it is not correct that all flags "ever" are recoverable: the window of data available via the scrolling event loop is pretty small (beyond that the client application simply requests a full page reload).

I will, however, investigate how this can be addressed.

Update: this change is deploying now; for these events, the user-id (used to change the UI experience) is now only included for your own events. For other events this is omitted.