Dynamic tile arguments #260
Conversation
opatut
force-pushed
the
dynamic_tile_arguments
branch
from
99fec82
to
49ef7f2
Compare
api/obs/api/routes/tiles.py
Outdated
| username = req.ctx.get_single_arg("user", default=None) | ||
| if username is not None: | ||
| if req.ctx.user is None or req.ctx.user.username != username: | ||
| raise Forbidden() |
There was a problem hiding this comment.
Tested this before even looking at the code :) Was not disappointed to get a "forbidden".
There was a problem hiding this comment.
Tested this on my machine, including trying to fetch the private tiles for another user (and being presented with a forbidden error, 🚫 👍 as it should be).
There's one privacy issue though: Allowing a time range as narrow as one day allows to see (anonymous) track data. Scenario: see someone riding with an OBS, later narrow the interval to just the day they were riding, switch to "road usage view" and see their (mostly continuous) track. Unless of course there are tons of riders in the area on that day - but that's unlikely on most portal instances. Example of such a track track that (from the beginning and end not shown in the picture) I was able to identify as mine.
We could combat this by making the selector less precise - Maybe only allowing to select a month, but no day.
The same with more inbetween steps will be possible with the "before-after" mode by subtracting before and after from the total - also arriving at the usage numbers in the interval between before and after.
I love the functionality though and think it is pretty powerful as a tool for investigation of the impacts of construction works and other temporal changes on the overtaking distance. Especially initial investigation will in reality often be done by not-so-tech-savy volunteers, and this really helps them out.
|
Yeah I am unsure about that fact. However, the same is already possible by showing events on the map, which come with the timestamp, so you can reconstruct movement patterns from them, provided there is little data overlap with other tracks (at the moment quite common). Sure, this makes it easier to visualize that, but the data is already there. In your attack scenario, you still need the mapping of the known timestamp to the user you've seen in real life to be able to extract information, so the leak (mapping a track to a human person) is technically happening outside the platform. Doesn't make it less valid, but harder to combat... I'd say we round the date to weeks for now (as construction work will often align to weeks), what do you say? |
opatut
force-pushed
the
dynamic_tile_arguments
branch
from
49ef7f2
to
868c4e1
Compare
… their statistics with filters
opatut
force-pushed
the
dynamic_tile_arguments
branch
from
868c4e1
to
4c2ba07
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
Adds filters to the map to dynamically limit the data being parsed.
Fixes #240, #241.