Eh? I've so far not seen an XML parser (or any library) that runs JavaScript. And while buffer overflows are always a possibility in C based software, using a well tested XML parser is probably a better safeguard than hacking your own parsing code, and comparable to using any other parsing library.

Not that there aren't any problems with XML default parser configurations (system entities, the billion laughs), but this is just bogus.

As you quoted, "Programmers tend to use XML poorly", but then, "Programmers tend to use serialization poorly" would work just as well. I've only recently really started internalizing just how much of a minefield serialization is in general and I'm 12 years into my career.

couple of things: - "wispr" is a configurable keyword. thats not how wispr works or is detected. - the probeurl (i.e. the url that a captive network checks for) changes with a wide variety of hotspots. when I last looked, ATT provisioning had 5. - there is no security issues here as far as xml or wispr is concerned. the cached credentials on ATT, for example, are global to all ATT users. not to mention, there's a whole whackload of certificates and whitelists in there to keep you from sending a wispr request to fake access point

Gentlemen, start your engines!

You can't disable that unless you get on some magic whitelist that Boingo got into but it's pretty much off-limits for the rest of the crowd.

b. The author of the article is speculating when worrying about buffer overflows and javascript execution. I doubt most wispr parsers even use traditional XML parsers. Besides, its much easier to spoof an AP or execute a man-in-the-middle attack than anything else.

c. The magic whitelist as you call it, is publicly documented and is called "Captive Networks". You can read about it in the iOS documentation. But I suppose its more fun to try to bash without any knowledge.

I'm talking about native iPhone apps that try to provide some WISPr-related functionality -- the kind of apps ATT would pay somebody to do if WISPr wouldn't be "build in", OR, if they actually wanted to provide more features than just the basic login.

And the "magic whitelist" is a whitelist on the iPhone itself, that disables the iOS "built in" WISPr support so that native apps work. One of these apps is Boingo.

But you are right about one thing: sometimes I also feel that it seems easier for people to bash on the internet without any knowledge.

That doesn't make it easier to explain to customers why they can't even test the app properly on their test devices.

This fact was also basically undocumented which made things... interesting.

I'm not defending apple on this, at all. but from the time I've spent working with these devices, there is just so much going on in so many levels, you can't possibly cover everything with public facing documentation. and you probably shouldn't anyway.

The customer is the one paying for said app and they can't test it since the built-in WISPr gets in the way.

I think everything should be in public documentation. I don't like knowing that if I can visit Cupertino I might find out about some API I just really-really need, but not if I search the documentation.

from apple's perspective: they dont have to document everything. they covered the majority of stuff that the majority of developers/users care about. this is pretty much affecting almost nobody.

from my perspective: god dammit I wish they documented the goddamn provisioning system. I know the only people that need to care are carriers, but that would make my job a lot easier.

It's the same way I get on my University's network without logging into the awful SafeConnect.

I have to do it once every few days. I could craft a wget/curl request to run every few hours I suppose so I wouldn't have to close out of Chrome and reopen it, but what can I say, I'm lazy.