Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User device as a tracker #158

Open
strdr4605 opened this issue Oct 27, 2021 · 2 comments
Open

User device as a tracker #158

strdr4605 opened this issue Oct 27, 2021 · 2 comments

Comments

@strdr4605
Copy link
Contributor

Is your feature request related to a problem? Please describe.
As of current situation 38f5834, what do you think about using user device as a tracker for the car?
Describe the solution you'd like
I don't have a clear vision, just ideas for now:
The app may start tracking the user location when the user opens the app to search for a route.
When we user is at the station we may ask him what route is he planning to take.
The app will send the location to the backend while the user is still on the route path.
When the user will leave the car and the route, a thank you message should appear. "Thank you, you helped X user. Now we don't track your location".

From the first view, this solution is not very doable.
Privacy concerns, implementation issues, small userbase!

Just wanted to put it down for traceability and discussions!

@ralienpp
Copy link
Collaborator

The main benefit of this approach is that RTEC cannot sabotage this system directly or easily, since it is not under their control.

The problem with privacy can be alleviated by the following means:

  • the code is open source
  • the part responsible for this analysis can be more commented than usual, to make it more understandable to non-experts
  • we can make a 3min video clip where this is explained in a very clear manner
  • the program's description mentions this, so anyone can see for themselves

However, there are some downsides:

  • vehicles without people who run this program won't be seen
  • people must not forget to "check in" when they get on-board,
  • and ideally they should also type in the board number - this is error-prone
  • supplying fake input data, poisoning, can be a serious problem; some will do it accidentally, some will do it for fun. It can be addressed by not relying on data coming from a single user, but rather using some sort of quorum logic - but this will only work if we reach a critical mass of adopters.

Critical mass is a problem, because we are not at all sure that this is realistic. In fact, considering the little coverage Roataway had so far, it means that betting our money on "we will easily achieve critical mass" is naive.

Moreover, we must seriously consider the possibility of sabotage, because it has already been done to us, and is therefore not merely a theoretical threat, but a very real one. So far, RTEC could easily interfere through inaction and a few small, one-off destructive actions (pull a wire, cover an antenna, etc.).
To sabotage this new approach, they'd actually have to put their mind to it, write some software (or find someone who will do it for a fee), etc. This requires more intelligence and skills, so we can consider, for now, that we're on the safe side.

However, my overall attitude towards this approach is skeptical. The energy that goes into this should go elsewhere. For example, with some SEO and social media influence, we could attempt to sway public opinion and bring RTEC in the spotlight, to make them take responsibility for their wrongdoings.

To sum things up - I wouldn't write this thing myself, but I'd happily observe and guide others, brainstorm about it, etc.

@iamandrewluca
Copy link
Member

iamandrewluca commented Oct 28, 2021

Side note. Analytics for almost 10 days. First 5 days I think trackers where still alive.

https://app.splitbee.io/public/roataway.md?period=30d

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants