> >You plan to > >deploy on a locally run user site yet you claim to be conscious of > >breaking the production server. It does not follow. > > More typo. You stated somewhere you intend to deploy to a test site > run locally. Something to that effect. I hope I'm not quoting you out > of context.
Without going back to have a look, I don't know if it's out of context, but my suspicion is I wasn't entirely clear :) I'll be running a test, yes, but the changes (and subsequent testing) will happen in the production environment. I've some issues with my dev environment which I need to address, so whilst I could use it for basic tests, I'm not sure they'd necessarily be valid. Although I see it as a big enough change that it needs some thought first (most of which is done), it's not so big that I feel I have to consider it gated by the dev-env issues, especially as I've a different site to test it against. So the test will be against a live site but one with a much lower traffic footprint (and one that, in worst case downtime won't lead to my inbox being spammed). Basically, all I'm trying to avoid at the moment is the things that are either severe, or will take a while to correct (such as getting canned in Google's indexes), everything else will be tested and measured as I go. > You just need to be concerned with ensuring trust of your > site by not doing anything silly. Such as selling their data, > embedding exploitable code, not caring that your client really doesn't > want to use javascript, etc. All the things you would do with a HS > anyway. It's a pity we live in a world where that could be considered HS specific, but yes you're right - some of the bits I've also been thinking about relate to whether there's anything on the www-front that I'd consider either un-necessarily risky or less acceptable on a .onion. There shouldn't be any, but I don't subscribe to the idea that it's your problem if you've got JS enabled - I need to be at least considering whether there's anything you might not want via an .onion that's considered acceptable on the www. (Analytics is a reasonable example - if you're accessing .onions through a gateway and www. traffic egresses normally, the analytics package can tie your .onion session to your real IP) > Without the constraint of hiding like the worst of tor. Having set up more than a few HS with that aim (though it wouldn't be liberty/life threatening if I made a mistake - I'm fortunate to be in that position) I have to admit it'll be nice to not have to do too much on that aspect. > Congratulations on giving your clients a choice and for being a good > model of tor use. > Based on your counter example, I think the same is (or will be) very much due to you - longer term, I probably will dig deeper into that side of it, partly because we don't know what the future will hold, but also it gives me something new that isn't work to tinker around with :) -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
