User:Ms7821/Security theatre

From London Hackspace Wiki

< User:Ms7821

Revision as of 20:40, 20 July 2018 by Ms7821 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Background

Currently webcams are easy to access on any device, simply by knowing the URL.

This is a cause of concern for some members, for some/all of the following reasons:

  • People just don't like webcams
  • It's difficult to justify the loss of privacy to visitors
  • Temptation to use the webcams to work out why something happened
  • Imbalance of power - those in the space don't necessarily know who can see them

Note that the last two are seen by some as advantages, due to their deterrent effect.

The following people requested for it to be members only

Names given are common username and email name.

(names removed, please see the history)

The following people requested it be left public

(names removed, please see the history)

The following people requested a new shareable URL

(names removed, please see the history)

Implementation of limiting to members

I hope rearranging the cameras will be enough, but if not, here's how the members-only limit might work without causing too much disruption:

  • Logged in user visits webcam page
  • Auth cookie is checked; user is given a long-lived cookie with auth details
  • User is redirected to current URL with key (random)
  • Current URL with key can be distributed

Periodically, current URL changes

  • When current URL key is wrong, long-lived cookie is checked and user reauthenticated
  • If user is still active, user is redirected to current URL with key
  • If not, user is invited to ask on IRC


This of course does nothing to protect against a member who shares their password, forwards the streams, or writes an API to make the URL available to the wider world. But it does mean we can graph how often the links are shared with outside members.

  • We don't currently know that the cameras are EVER viewed by nonmembers (other than transiently, by invitation, which this implementation is designed to still support). How about investigating this first, before bothering to set all that up ? Logging IPs would do as a first cut, then see whether it needs to be refined.