Terms of Use Clarifications
" I was actually reading the Terms of Use for a change looking for anything other than the usual "don't be hostile" and "covering your butt" stuff and the section above caught my attention. This section seems to suggest that a plugin like the Chrome PoE Helper is against the ToU and therefore bannable. In fact, even a fan site that reproduces patch notes, gives quest walkthroughs, or otherwise has references to items, npcs, areas, or whatever in PoE seems to be against the ToU. But at the same time, Dylan has not only worked with the developer(s) of the Chrome PoE Helper ( http://www.pathofexile.com/forum/view-thread/29916/filter-account-type/staff ) but suggested that an API for such apps is possibly on the horizon. These seem to be in contradiction as clearly the use of the Chrome PoE Helper isn't deemed to be against the ToU (and therefore not bannable to maintain/use). I get the impression from reading this section that what you don't want is a 3rd-party website that reproduces vast sections of your website content or any confusion as to who owns content or which site an unwary user is currently interacting with. You also wouldn't want hostile DDoS-like behaviour from a script/app that, when in the hands of hundreds of thousands/millions of users would bring the site to its knees without you spending a fortune on beefy servers. This much makes perfect sense and is completely understandable. But I don't think you intend to restrict benign helper apps that do technically scrape and reproduce content (by using your own pages as though viewed in a standard browser), in a more usable (perhaps mobile friendly) format. I'm not sure if building a Skilldrasil into an app for offline build planning would be objectionable, though it certainly seems to be disallowed. This caught my attention because I've been rolling around the possibility of creating a free benign* WebKit-based helper for iOS as it's something a number of people would love. Though I absolutely won't create it without contacting you privately with details for consent if/when I iron out said details, I think clarification of your relevant policies would be good for everyone. At the very least it'd be an iOS version of the Chrome PoE Helper, but there's so much room for cool stuff if you aren't so restrictive as the ToU makes you seem. Supporting GGG extensively and getting banned for making a helper tool would suck. I don't mean to suggest that you would unreasonably do so, but the general clamping down in the ToU that leaves the possibility dangle is a bit uncomfortable. The "without the prior written approval" part really only applies to the sentence it's in and so doesn't cover benign scraping or any of the rest of it. Not to mention the unwary player who uses a helper that seems to be in heavy community use (and GGG-accepted) who happens to become part of a mass ban at some point because it's deemed not acceptable after all. Of course, getting prior written approval makes sense for anything and it is certainly courteous at the very least, but I still think this section could use some public clarification. Thanks much. --- *By benign, I mean that it would obtain data using your own web queries with not just manual-only cache updates but sensible local time-restrictions far in excess of your own connections/sec/user settings. |
![]() |
Sorry for the slow reply!
We're probably going to review the Terms of Use and update them as we enter Open Beta. I definitely agree it can be improved, especially with regard to what tools are/are not allowed. The rough rule of thumb we're aiming for is that tools can't interact with the game client, but can interact with the website or other exposed public APIs that we make. Please email me at chris@grindinggear.com if you'd like to discuss it in more depth. | |
No worries, Chris.. I know I posted it at a busy time.
Thanks for the clarification. I'll definitely contact you directly when I get something more concrete. But, for example, though I want to make the app more restrictive than a browser, a kill switch that you can control via a meta tag on the website might be a good idea prior to an app going public. Also, if there were a more direct way of obtaining the necessary data than per-tab clicks it would result in lower bandwidth and less client connections. |
![]() |