DescriptionThis is consideration 9 in the parent issue.
Need to look at all third party resources and decide whether they're acceptable on a .onion.
For example, 'Tweet' buttons traditionally load in an iframe, need to consider whether there's any opportunity for leakage there (I've no issue with the onion address being associated with the www. address, but definitely don't want a visitor's real IP being disclosed).
Need to keep in mind that some visitors may not be routing all their port 80/443 traffic via Tor, and instead run a gateway on the local network so that they can transparently access .onion sites (I do).
Activity
2015-05-21 15:59:06
2015-05-21 16:09:40
Login Radius
Used to allow login/registration via Social Media account in the shop section. As it hooks into authentication, it triggers on every page.
The user has to actually opt to sign into the site, so I can't automatically tie a visit to the .onion to an account. If the user opts to log in using that method then that's a deliberate action on their part.
Google Analytics
Enabled by default (Note: not an issue if Javascript is disabled in-browser). I already offer functionality to disable Analytics (though the user does have to visit the site first).
If not all traffic is torified Google can tie a real IP to a visit to my .onion. Not good.
Maybe adjust the existing routines so that it's disabled by default if browsing through the .onion (not like the analytics data will be of much use anyway). Have been debating turning analytics off anyway, so might also be worth revisiting that.
Social Media sharing buttons
Articles carry buttons to share content (via Twitter, Facebook, Google+ and LinkedIN).
The buttons are just images when the page loads, they need to be clicked to activate them (at which point the 3rd party scripts will fire). The site also includes functionality so a user can have them enabled by default, but it's optional.
Not a risk in the sense that it's a deliberate action by the user - they know they'll be associating their user account with a visit to my site.
Google Ads
Probably the most difficult one to approach correctly.
Have trialled getting rid of the ads in the past, and it's just not economically viable at the moment - I can justify spending time writing documentation for the site if there's likely to be return from the ads, but not for free.
This one needs more thought, whilst the bulk of access will probably be via the www rather than the .onion I need to consider whether turning the ads off is viable (or whether there's some sort of alternative work-around I can put in place).
2015-05-22 14:57:26
Not sure why I did that, probably missed it when I was making it optional.
Have changed that function, Analytics is now only available if the browser supports LocalStorage (so that I can store the preference) and is disabled by default.
2015-05-22 15:04:47
An additional element to consider (when I do that) is that the effect of having Adsense ads on a hidden service may well be multiple clicks from a small group of users (from Google's perspective) which might be mis-interpreted as click-fraud.
Definitely needs some thought, but for now will move on with the other outstanding items.
2015-05-22 16:17:40
Need to think up a good way around it, but in the interim, my primary concern is that I don't want anyone being unexpectedly redirected to the www front. I think as a precaution I'll block access to the shop from the onion and display a message instead.
Will raise a separate issue to track the fix - MISC-7
2015-05-22 16:46:01
2015-05-22 16:46:08
2015-05-22 16:46:08
2015-05-22 16:46:15