User:Ms7821/Security theatre: Difference between revisions
mNo edit summary |
|||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 15: | Line 15: | ||
Names given are common username and email name. | Names given are common username and email name. | ||
(names removed, please see the history) | |||
=====The following people requested it be left public===== | =====The following people requested it be left public===== | ||
(names removed, please see the history) | |||
=====The following people requested a new shareable URL===== | =====The following people requested a new shareable URL===== | ||
(names removed, please see the history) | |||
==Implementation of limiting to members== | ==Implementation of limiting to members== | ||
Latest revision as of 20:40, 20 July 2018
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)
(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.
