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

iterated_lobby_channel also sends global_data #55

Open
JannisBush opened this issue Jan 5, 2019 · 2 comments
Open

iterated_lobby_channel also sends global_data #55

JannisBush opened this issue Jan 5, 2019 · 2 comments

Comments

@JannisBush
Copy link

The iterated_lobby_channels send the complete information of the experiment to the next participant. This includes the global_data of the posTest-View, which is personal, e.g. gender, comments, etc. and should not be send to everybody participating in the experiment.
Line 50-54:

        BABE.Endpoint.broadcast!(
          "iterated_lobby:#{experiment_id}:#{variant}:#{chain}:#{realization}",
          "finished",
          %{results: experiment_results.results}
)

Maybe we can filter the results table and exclude the global_information somehow?

@x-ji
Copy link
Member

x-ji commented Jan 5, 2019

Security-wise the current architecture is not very capable. For real online-games, the server should handle most of the functionalities and the clients should be really limited in power. However, since we need to support diverse types of frontend experiments with a backend structure as generic as possible, we have to leave a lot of power in the hands of the client, e.g. generating the next round of experiment, recording results for each round of experiment, etc.

That said, this situation might be a privacy concern since people might come to us and say we leaked their personal information somehow, to others willing to hack the browser console and inspect the data. A solution would be to require users specify dynamic_retrieval_keys, and filter the results based on those keys, just as we do for the traditional JSON results retrieval via HTTP requests.

@JannisBush
Copy link
Author

Using dynamic_retrieval_keys sounds like a reasonable solution

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

2 participants