changes to the mumble identity

[codemasher]

The Mumble identity string contains data which became redundant when the /v2/characters API was introduced. Also, it doesn't comply with the authorized endpoints anymore since the data is available without authorization.
I changed the name field to character_id which contains the hopefully soon-to-be-available character UID (#32). The profession field is obsolete, supply added as per #55 (comment), also added health which is questionable as Lawton already mentioned on the forums. In addition, the name field in the Link data, which currently contains the account name, should be changed to the account UID.

(oh, you can safely add the "breaking" tag ;)

[lye]

Also, it doesn't comply with the authorized endpoints anymore since the data is available without authorization.

Ehhhh, if you're running someone else's code on your machine there's implicit authorization there.

I really hesitate to remove data from the mumble link stuff because doing so will likely break existing applications -- moreover, native applications that are significantly more difficult to update than web applications. I would much prefer to move away from the mumble link data and never look at it ever again; the way we're currently using it is a fairly massive hack.

[codemasher]

Ehhhh, if you're running someone else's code on your machine there's implicit authorization there.

Thats right, but since there are a couple apps out there which use this data, authorization wouldn't hurt (my WvW app might be a good example how this data can be "exploied").
That being said, the Mumble Link is (and will probably stay) the only source for realtime data - even if you'd provide a realtime API instead it wouldn't be as accurate. I guess any other solution might also be a hack anyway. :D

[lye]

What wouldn't be accurate about a local websocket connection to the running game client?

I'm not opposed to local APIs, I just don't like the shared memory model that the mumble link uses -- it's way too difficult to effectively interop with.

[codemasher]

Hmm, ok, thats an argument i didn't think of.
Go! Go! Websockets! ;)

[tivac]

Seconding the lack of love for continuing to work within the bonkers confines of the mumble "API".

[aRestless]

The proposed change would break Markers and require users to authenticate an application that's now working "right out of the box".

I'm all in for more real-time data and for a better protocol than MumbleLink, but please don't remove fields if it's not absolutely necessary.

[darthmaim]

The proposed change would [...] require users to authenticate an application that's now working "right out of the box".

Instead of requiring an extra API key, the mumble link data (or whatever replacement) should ideally contain an autogenerated API key with access to all scopes.

[aRestless]

Instead of requiring an extra API key, the mumble link data (or whatever replacement) should ideally contain an autogenerated API key with access to all scopes.

Nope, it definitely shouldn't. It's one of the major principles of APIv2 that you manually authorize access. If any process running on your computer had access to that data, that thought is compromised. Just imagine malware that reads that API key, sends it "home" and then, when external guild chat is implemented, spams its goldselling messages there.

I know, if you've got malware on your computer you've got a whole bunch of problems anyway, but we shouldn't make it so easy for the bad guys, should we?

What I could totally imagine is a message exchange between external application and the GW2 client, that results in a user prompt that says "Application X wants access to account, characters and guild, allow?". Accepting that generates an API token that also appears on the account page and can therefor be revoked.

[lye]

I can totally see, from a UX perspective, why it makes a lot of sense to be able to create and grant API keys to local applications from within the game client. Not gonna lie though, that pushes the implementation's scope out quite a bit.

[lye]

That said, I'll look into adding supply into the mumble link data. I think we've got enough spare bytes, and it's a fairly infrequently updated field (updates <once/second).

[FrederikNJS]

@aRestless If you have software running on your computer which has the ability to steal your API key, then goldselling is the least of your worries. If they can get at your API key, then it can just as well keylog your password, and swipe your browser cookies, making it possible for the attacker to log into your account on the Guild Wars 2 website where they can make their own API key. But why not steal your account gold instead then? Why not steal your PayPal account info or your actual credit card info? API keys are simply not worth the effort to steal.

To make things easier for ANet it might make good sense to use the API keys for everything, but it won't really improve the security against anyone who wants to attack you.

[lye]

@FrederikNS I think there's an important distinction to be made between bypassing access controls (which is within the realm of capabilities for local applications) and being implicitly and automatically granted access.

Yes, a local application can technically acquire and distribute information without your explicit consent, but that should not be an officially supported flow.

Anyway, all of this depends on quite a bit of infrastructure being developed. It's all pretty far in the future. There's not much benefit to debating the minor semantics, IMO.

[FrederikNJS]

@lye I completely agree! I much prefer applications asking politely (and explicitly) about permission, and I think the "Do you want to allow application X to view your inventory?" or manually generating API keys are definitely the way to go.

My point is that this mechanic does not improve security. Instead it improves transparency and the user's privacy.