Tor2web Access disclaimer

[fpietrosanti]

As additional improvement, to reduce the risks by Tor2web operators and better distribute tor2web nodes, we should implement an Access Disclaimer.

Access disclaimer is shown to every user that have not accepted the access disclaimer.
Upon acceptance of Access Disclaimer the user is given a temporary cookie.

Any requests without the appropriate acceptance of Access Disclaimer will result in a redirection to the Access Disclaimer page.

That way we can definitely prevent embedding and crawling possibly illegal content from internet forums, directly from Tor2web resources.

The Access Disclaimer must be loaded from an external template file.

The Access Disclaimer feature must be configurable, as there may be custom Tor2web usage scenario where it's not required.

The acceptance of the disclaimer may mitigate the "White page effect" as the user will immediately be prompted with some content (the disclaimer) and when he will click to accept disclaimer and see the TorHS website, a Javascript comfort loader may be provided.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3638078-tor2web-access-disclaimer?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[fpietrosanti]

The access disclaimer may need to be configured in a way that FORCE THE AWARENESS of the end-user with a "quiz" with multiple answers, like we've already done at globaleaks (see http://demo.globaleaks.org)

[moba]

How do you do it without leaving behind a cookie on the user's computer? I like the idea in general, but I would hate to leave cookies that give away all hidden service addresses you visited over Tor2web. And just setting a global domain cookie is too little warning IMHO. Maybe a global cookie that works for 15 minutes, but then it is not very usability-friendly. A global domain cookie that reflects the user state on the server side (ID to URLs)? Not sure that is much better...

[fpietrosanti]

@moba another possible solution would be to authenticated this "cookie" trough a unique time-based access URL such as the one described at #33 .

For example the user may access blahblahblah.tor2web.org and get displayed this forced access disclaimer.
Upon correct answer/acceptance he would be redirected to http://luehlu34htrltrhdlsgheluwhtfljwehdsfljhwldjsghflsjdghljrfhdgljdfhgljdhfgldfhgljhdljgh.tor2web.org where the "random url" represent a time-driven authentication cookies ?

[evilaliv3]

@juhanurmi / @fpietrosanti i've ready the commit that change our architecture removing the injected banner and addind a landing disclaimer. can you please review the texts of the following screenshots and see if there is something you suggest to change/add/antani?

[evilaliv3]

[fpietrosanti]

I would strongly suggest to still keep the injected disclaimer.

[fpietrosanti]

I would suggest to have the disclaimer being shown, also if the site has been blocked, by showing the "block page" only after the end-user click accept.

[juhanurmi]

Good work @evilaliv3! I agree with @fpietrosanti. Let's still keep the injected disclaimer.

Furthermore, we should put there something similar to "We do not keep any logs and we are not hosting this content.".

And a large access button in the end with text

"I understand that this site is not hosted by <tor2web_node> and I want to access it using our proxy service: Large button with onionsite_name"

[evilaliv3]

@juhanurmi with @fpietrosanti what about the following screenshots in order to test the feature during the following days?

@juhanurmi can please you also review the english texts?

[fpietrosanti]

I ended up the web page for the final definitive styling including abuse reporting and donations:

Link for review and modification is at https://docs.google.com/document/d/1cbXZbDKwgePsWToXfxmlko5CHPLmMOONBkbxbxQh1Zg/edit?usp=sharing .

[evilaliv3]

ok i've pushed the MVP i've implemented for the feature.

it's included in the 3.1.13
so that we are a little now more stronger with respect to takedown actions.

numes if you want you can proceed updating tor2web.fi so that we can than go on reviewing @fpietrosanti texts and try to design a more beautiful page (the one designed by @fpietrosanti is to much rich for a disclaimer and creates confusion).

by the way here is the current status:

[fpietrosanti]

The definitive style should have all content built-in, being professionally styled, accessible from both desktop and mobile devices.

The definitive style of this page shall then be used as a base for the Tor2web public website.

[nadimkobeissi]

I'm interested in contributing to this, could someone please point me to the relevant code for the HTML page?

[fpietrosanti]

@KAepora Love :*

The template file is in data/templates/disclaimer.tpl of Tor2web 3 source code, implemented as MVP:
feae549

The draft of the elements of the web page we'd love to be there (for various reasons) are here:
https://docs.google.com/document/d/1cbXZbDKwgePsWToXfxmlko5CHPLmMOONBkbxbxQh1Zg/edit?usp=sharing .

The Tor2web logo is available at http://logioshermes.org/home/projects-technologies/tor2web/

The Adobe Illustrator of Tor2web logo is at https://github.com/globaleaks/advocacy/tree/master/logos

[evilaliv3]

great! thank you @KAepora !!!

as suggestion do not try to hack on tor2web directly as the only things needed is to develop a:
an single page like app page embedding javascripts / css / images inside an index.html (that we will integrate as disclaimer.tpl)

i startted using the templating system, but for the discalimer it would be probably really better to have it all embedded.

[fpietrosanti]

@KAepora love? :*

[evilaliv3]

just a note on the current status of the implementation:

currently all is based on sub domain specific cookies so the forensic issue for the clients exists (and it's equal to the traces that are obiosulsy leaved on proxies). by the way the solution has been considered better than having a global cookie (*, wildcard) and short living cookies that eventually can break some opplications in various conditions like for example long file uploads on globaleaks and so on.