Hacker News new | past | comments | ask | show | jobs | submit login

This brings back ugly flashbacks... Apple's WISPr implementation also breaks any apps that try to provide WISPr functionality since it gets in the middle of the handshake.

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.




a. WISPr is publicly documented. You can read about how it works in the document. As for user creds, I would suspect that maybe the ATT client is using a form of EAP-SIM over WISPr but thats just my guess. It could also be something much simpler that doesn't even bother to verify "credentials" in the normal sense. Whatever is going on - its built in "under the hood".

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.


You are so off-base it's not even funny. I can't believe 3 people upvoted you.

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.


it's not a magic white list. it's actually an explicit list on the iphone. you can apply to have your app exempted.


Sure, you can apply.

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 don't really understand what your second sentence means. what customers? what app? why can't you test it on the device?

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.


I'm taking about apps that provide WISPr functionality.

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.


ah, I get it.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: