Gil.9346:

Hi,

I need the home world id of the current character in Mumble link identity data. I cannot progress the development of my overlay tool otherwise. I’m unable to do open field tests and can only release to knowm members of my guild. Thank you in advance.

Regards,
Gil/Comes Mors

Lulan.8497:

Why don’t you provide some options dialog that uses the arenanet api to retrieve a world list and configures your overlay application by user selection?

Wothor.4781:

He’s going to use the positional data for showing the positions of folks participating. It’s a given that user choice ain’t feasible there ;D

The most primitive option is to have a manual registration system, but having to verify home worlds manually for every single user ain’t really where one would want to be going.
Via Mumble Link, you can partially get there methinks using a combination of team color id, world id and the API. However this check only works when the player is on a wvw map, since otherwise the team color id will be 0 (dunno if an oversight or limitation). However, after all Mumble Link is attackable from local. It’s a barrier just until someone writes those lines of codes to break it.
In the end, we need this verification to be an API call.

I’m facing a similar problem with my positional audio module of my Teamspeak plugin. Luckily I can at least refer to TSes security mechanisms implementing the manual approach until then. I’m quite positive I could do a feasible protection, including an AntiSpy mechanism for TS if I had a better way to tie players to a home world (still excluding multi accounts ofc).

smiley.1438:

The only current problem i see with the MumbleLink data is that it returns garbage values for WvW and overflow servers. I hope this will change one day. (WvW → home world, Overflow → overflow server’s id)

Gil.9346:

Yep, thats the problem. I need the home world id and somekind of session versification to authenticate the users world. Otherwise a spy could get himself all positions for a foreign world. As I show WvW positions this would be fatal.

Regards,
Gil/Comes Mors

smiley.1438:

I’d also recommend you the “shared key” concept of our location tracker:
https://forum-en.guildwars2.com/forum/community/api/Gw2-Location-Tracker/2380078

Wothor.4781:

In a standalone context that’s probably the best bandaid indeed.
That said, the relevance of the issue at hand remains, as with every user interaction necessary a vast portion of the potential client base gets lost.
People are lazy.

smiley.1438:

You have to keep in mind that you will need to send the position to a webserver (or whatever on the net) in order to share it with the other people you play with. So as long as you don’t use some kind of VPN tunnel, there’s always the possibility to send spoofed data – and an SHA1 key can’t be spoofed that easy unless you work for the NSA…

Wothor.4781:

Actually the (single closed source) component waiting to be deployed in CrossTalk uses SHA-1 already to generate what I guess is some sort of keyed-hash message authentication code (HMAC) out of a variety of variables, that’s good enough for me
However, since one of those obviously has a certain relation to the world id, I’d currently inherit certain enforcements to have that work.
Imagine a commander disconnecting, reentering on LA overflow. Invalid key generated, no enter.
I’m not gonna be the one receiving complaints about that, so anyone will have to stick with manually setting passwords (aka shared key) until then.

I’m way more dedicated to user comfort than on security here, I want the manual user interaction out of the equation on that part, as I find hassle-free usage (I know we wouldn’t name shared keys as a hassle, but looking at the default user I think it is, given that there are server voicecoms without passwords since it’s too much drama/work apparently) is the breaking point to a wide-spread usage of the tools created by the community. Obviously I’m mostly trying to convince the devs here that the status quo isn’t suffice

Gil.9346:

Well, for sending the data I rely on Google SSL certifacte and encrypted POST Json Data. That shouldn’t be easy to break.

For the Homeworld Issue I would recommend to give us some kind of fingerprint/session key. With this key we can request Player Information through an public API like the home world id, the guild of the player and so on. This would garantuee that even if the mumble data is spoofed on client side the server can get the information from a public trustworthy source.

Regards,
Gil/Comes Mors