I tried searching around, but couldn't come up with much on the topic of this.
Is there an API or code within various Security API's that would allow some sort of passcode locking mechanism to enable whenever a device is connected (by Bluetooth, etc) and disable whenever said device is paired with the phone? An interesting concept I had thought up earlier today but can't seem to determine a method available for this.
The concept is pretty much this: if the phone is close enough to be connected over Bluetooth to the device (would be something like a smartwatch or other wearable computing) then the phone is on you and passcode entry can be disabled. However, when the device is not found by the iPhone, there is a physical distance between the two devices and the phone should lock up and not allow entry. This could even be some form of superficial lock mechanism on some apps (which exists already) that could activate based on this proximity awareness. This method is meant to failsafe by being a "lock first, then check" mentality that is paired to a specific address of the wearable computing. This could, in theory, be hacked, yes, but for general usage allows a user to have a no-maintenance method that can save some passcode entries from time to time should one find it annoying, but still want it's security potential.
Again, this idea is based on the assumption that said device connecting to your iPhone that the phone itself is searching for is physically latched to you somehow.
Thanks and I appreciate any sort of input or direction.
Related
I am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
I am looking to write application for iPhone which will be able to control radio and CD player in car. Radio and player have Bluetooth connection available.
I started this question in order to obtain all informations I need for this one one place. I have few questions, but if you find anything I didn't ask important for me to start developing this application, please, let me know.
I have read about AVRCP profile and Bluetooth device in car supports AVRCP 1.3, which is good enough for me, having in mind controls which can be performed in that protocol version.
I read a lot about people saying "Apple device can only interact with each other", "Apple device can't be connected via Bluetooth to non-Apple device", "MFi program is obligatory if you want to do that", "MFi is not needed", etc. My first question is:
1)Is it even possible to pair iPhone (4, 4S) with radio and CD player in car via Bluetooth and control radio stations and music with any iPhone version? If yes, what are the limitations for making this kind of successful Bluetooth connection?
There is also very few informations about roles in which iPhone can work. For AVRCP there are two kind of roles: controller and target role. By reading this paper: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf I didn't find answer to my second question:
2) Can iPhone act as a controller and issue all available commands stated in AVRCP 1.3 to target device (radio and CD player)?
I would also like to know about available frameworks for this particular problem. I know there are several of them, but if anyone recognizes the right one for my problem, I'd like to know:
3) Which framework for interacting with target device should I use?
From developer point of view, I am also interested in available APIs for interacting with connected Bluetooth device. Since I am making my own application and assigning actions to buttons, inside of methods assigned to buttons I need to perform message sending to target device. So my next question is:
4) Does anyone know how if there's a way to send commands to target device (start/stop/pause/forward/backward, etc) as part of some API provided in XCode, or each message which I attend to send via Bluetooth to target device I need to make according to protocol documentation (make entire message (header, body, command part, etc) by myself)?
AVRCP was my thought for accomplishing this application. If I am wrong, please let me know.
Bluetooth has different profiles and when message is sent from one device, as far as I understand, profile itself handles message and interprets it and delivers to target device so target device can understand it. I do not understand how a message sent from iPhone to target Bluetooth device is handled from the moment I send it from my Objective-C (or C) code. That's the main doubt I have and it is related with question 4 - do I need to make raw messages in correct format in order to send AVRCP commands to device or I can use some API which will recognize those messages as AVRCP (or any other kind) and deliver it to target device?
This last question (if I suppose there is any kind of positive answer to all previous) concerns me the most from developer point of view. So, if anyone had maybe experience with this specific problem, I would appreciate any kind of answer or advice.
I am really looking forward to your answers. I hope that constructive and useful discussion will start on this topic and that lots of useful informations will be written.
Best regards.
You can do it using CoreBluetooth if your device (CD Player) is Bluetooth 4.0 LE compliant
Most likely you shall not be able to do it even if your car CD player has BLE 4.0.
With Core Bluetooth devices act as "Central" (client) or "Peripheral" (server), the peripheral "has data" and expose services with characteristics (variables). The central (client) reads data from the peripheral or subscribe for notifications.
Your only chance is to connect to the CD player as peripheral (server) and your iPhone being the central (client). In this case the CD player must expose services that allow you to control it. To be honest I do not know how this can be done, since the central (the iPhone) will read data and receive notifications from the peripheral, not vice versa.
Reversing roles, implementing iPhone as peripheral makes sense, but there is no predefined Bluetooth LE service for remote control, so your car CD player does not know what service to expect from you. It might work using HID service (Human Interface Device), used in general for keyboards and mouse, but according to this post the HID is forbidden by Apple on iOS.
We are in the process of developing an method of caching so that our app can continue to operate in an area with very little/no signal.
Obviously users will try to continue to use functions that require data and we need to handle the inevitable failure of these requests appropriately.
Essentially we are sat in the office, switching airplane mode on and off to simulate entering/exiting signal then adjusting our app to fix any issues this may arise.
What I'd like to know is, is using airplane mode going to give us a reasonable simulation of entering/exiting an area with no data or are there other implications?
I've seen questions raising the issue that the 3G/EDGE connection may not always wake up after airplane mode is switched on - while I appreciate this method is no way as good as actually being out in the field testing, if we can get a reasonable simulation and account for the majority of the problems that arise then I think this is an acceptable tradeoff.
I apologise if this has been asked before, I did do a search on here & on google but couldn't find any appropriate results.
You should try the Network Link Conditioner
There is a WWDC 2012 session called Networking Best Practices that mentions it (but he does not explain how to use it there).
To get it, you have to go to XCode/Open Developer Tool/More Developer Tools.. and download the latest Hardware IO Tools for XCode.
Once you install it from the IO Tools pkg, "Network Link Conditioner" will appear in System Preferences
You can then do something like 100% packet loss to simulate one of those routers that pretends you are connected but actually doesn't work.
On iOS, the network link conditioner is under Settings / Developer (you must have enabled Developer mode in XCode first to see it)
The main problem is that in the Airplane Mode the networking operations fail fast, while spotty mobile signal will lead to timeouts and a-few-bytes-an-hour speeds. This is usually a significant difference from the UI viewpoint. (It might be worth a try to use some bandwidth throttle to starve the testing machine and see how it behaves when the network starts to break?)
A few years back, when testing remote devices which used the cell network to communicate with the 'home base', we did things like move them into a shielded room (make shift), place large shields on three of four sides to force them to connect to a certain tower (and therefore, network), etc. Brute force physical methods. Since this actually cuts off the signal, it may be a more realistic approach.
You may also want to try this through your wlan-router. First, disable data roaming on your iPhone. Then, let the iPhone be connected to the internet through your wlan network. Then, disconnect the gateway on your wlan router while your iPhone is still connected to the wlan network.
This depends on what failure modes you are trying to test.
I use Airplane mode as a first pass check to make sure an app submission isn't quickly rejected.
Other network failure handling checks might include:
3G only (no wifi).
WIFI only (in Airplane mode).
Pulling the power cord on the WIFI access point.
Pulling the network cable from the back of the WIFI access point after connecting to it (Reachability may falsely say yes).
Walking in and out of a basement
elevator (or other Faraday cage) in the middle of a transfer.
Driving between 2 cell towers during a data transfer.
Walking between 2 enabled WIFI access points between connection and data transfer.
Starting the app after more than 30 minutes of device inactivity (radios may be idle).
Running the app while another app (Safari, Mail) is downloading in the background.
etc.
I want to send some Text plus a image from one iphone application to other iphone app but restriction is I should not use a web server in between communication,Is there any way to fulfill it ?
Details: There are two independent devices and could be far enough say out of network. My requirement one app adds some text with a image and sends it to another iphone which can be at any long distance , and the app installed in another iphone will read that info and image into itself.
Actually there is a solution that meets your needs — and that fits to bbums answer:
Create a HTTP-Server on the iPhone, using cocoahttpserver. than you will ask some webservice like whatismyip.com for your public ip. with this your iPhone can be connected worldwide.
But very likely ur wifi-network is not forwarding your port to the iPhone. Ash.
And even if: Now it gets difficult. How to publish your ip from one phone to the other? hmmm... — I got it: I will exchange the information in a centralized space! In the web!
... wait — that would be a Webserver.
You see: Without any kind of server in the Web the users would need to exchange ip manually and have full admin power and knowledge about the local network.
So IMHO bbums answer is the only way to go.
PS: I am working with http server running on iPhones. In local network that works great, especially with bonjour. And you can use them over distance network — but only with reconfiguration of your router — something you shouldn't force your user to do
There is far from enough information to provide a specific answer.
two apps on two different devices?
are the two devices on the same network?
are the two devices both on WiFi?
do you need the user to receive a notification or something if the app isn't running?
If on same device, you can define a custom URL handler in the destination app and then openURL: in the source app to pass the data over. Encode your image and text into the URL, but be careful of size limitations.
If on different devices, there are many possible solutions, but answering the above questions will be critical to actually knowing what solution is appropriate.
Given your comment -- two apps, different devices, arbitrary networks -- then you are going to have to have some kind of server in between. Note that the recently added Game Center does have the ability to rendezvous two users, but it has a very particular user experience that may not be appropriate to your needs.
I would suggest that you investigate using push notifications to notify the receiving user of the availability of content. As for moving the content between, no direct connection is possible and you will have to have some kind of store-and-forward server in between. And, yes, a web server is going to be the easiest possible solution simply because HTTP is ubiquitous these days.
If there's no network of any kind available, but both parties have amateur radio licenses, then hooking the two devices up to HF packet radios might work.
THIS is super EASY.
I would code up some software that can turn data into modem signal, like the good old dial up modem. The device would actually make those annoying buzzing sounds.
You get the phone number for your friends nearest landline and call him.
He places his iPhone near the phones receiver in listen mode and you connect to his phone using your audible modem.
Bingo, via the power of sounds you have sent data which is decoded on his device and all for the very cheap price of a phone call, there are pretty cheap these days especially if you use Skype.
Easy Way (relatively speaking)
A way two apps on different networks can communicate without setting up a web server of some sort is as follows.
Use an existing third party storage system like DropBox.
Each app would need the login and password for your DropBox. Then both apps can read and write files that the other app can see.
An existing app that does this is a shopping list app called ShopShop.
The app on my phone and my wife's phone both link to the same DropBox account and the app keeps the shopping list synced up when one of us adds something to the list.
When Apple's Remote app tries to connect to a Mac (running iTunes) on a local network (using WiFi), the user needs to enter a passcode provided by the iPhone as a security measure. This approach has been adopted by a number of other apps (e.g., Rowmote, Pastebot, ...). Is there an API that provides this way of working?
Assuming Bonjour is in play, how does an iPhone checks if the passcode entered on a Mac is correct without resolving the NSNetService the Mac is publishing? Or does the iPhone resolve the NSNetService a Mac is publishing and waits for the passcode to be confirmed before processing any other packets that might be sent via the NSNetService (packets other than the passcode).
I have a solution for my problem, but I would like to know if there's an API I have overlooked that provides a ready-made solution.
Advice and pointers are welcome.
Thanks in advance,
Bart
I don't believe there is an Apple provided API for this. I simply use the Bonjour APIs to open a connection between two devices, then have one randomly create a 4 digit passcode and ask the other device for it. The other device presents a UI to ask the user for the passcode, then transmits it back and waits for an answer. If they match, the devices store each other's identifiers to skip over this process the next time they connect.
Edit: Thanks to tc for pointing out that this implementation isn't totally secure. I'm now having one device create a unique, random password, and send it over to the other device, then store the SHA1 hash of the password for future reference. Then the other device stores the password and sends it back over whenever it connects for authentication. The user does the number code thing once in order to let the devices know that they should trust each other in the future, but now in order for a reverse engineer to connect to a device they would have to know both the identifier of and password for a valid, connected device. (Or they'd have to have access to both devices and do the number code thing; there isn't really a way to stop anyone from doing that, obviously).