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

ooniprobe in a browser? #471

Closed
d33tah opened this issue Mar 31, 2016 · 4 comments
Closed

ooniprobe in a browser? #471

d33tah opened this issue Mar 31, 2016 · 4 comments
Labels
enhancement improving existing code or new feature question for open questions

Comments

@d33tah
Copy link
Contributor

d33tah commented Mar 31, 2016

Is there an implementation of oonprobe that would work in a browser, enabling censorship tests without installing any extra software? If not, would it make sense to create something like that?

@hellais hellais added question for open questions enhancement improving existing code or new feature labels Apr 1, 2016
@hellais
Copy link
Member

hellais commented Apr 1, 2016

Hi @d33tah this is a very good suggestion. Somebody did start making a version of ooniprobe for chrome, but I think it's not very much complete at this stage: https://github.com/m-lab/chrooniprobe.

It seems like the chrome dart API would support what we need (https://www.dartdocs.org/documentation/chrome/0.8.0/chrome.sockets/ChromeSocketsTcp-class.html, https://www.dartdocs.org/documentation/chrome/0.8.0/chrome.sockets/ChromeSocketsUdp-class.html), however given the fact that we are already implementing a library for running ooniprobe tests in C++ called MeasurementKit, it probably makes more sense to orient energies towards implementing it as a NativeClient for Chrome and using the Mozilla build system.
I don't have any experience working with either of those, but it would be great to start out by making a feasibility study of those to figure out how do-able it is.

@d33tah
Copy link
Contributor Author

d33tah commented Apr 1, 2016

@hellais: so in other words: not unless we resort to native code? Would a stripped-down AJAX-only version make any sense?

@hellais
Copy link
Member

hellais commented Apr 1, 2016

@d33tah the problem with AJAX is that due to CORS you can't fetch arbitrary resources. There is an approach that allows you to learn something by loading favicon images and registering error handlers for them called Encore (http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p653.pdf), but it's very limited in what sites it can work for (they need to have a favicon) and the amount of data you can get from doing so.

@bassosimone
Copy link
Contributor

Closing in favour of ooni/run#19, which references this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement improving existing code or new feature question for open questions
Projects
None yet
Development

No branches or pull requests

3 participants