The Knock app lets you knock on your iPhone to unlock your Mac.
I come from the iOS side and was naturally surprised to see it was able to modify the lock screen. How does it do that? Can any Mac OS X just do anything it wants to the lock screen?
(source: heavy.com)
Also, while installing, the password prompt seemed... unusual. It wasn't like the default password prompt, but more like the one on the lock screen:
(source: mshcdn.com)
Any idea about what's going on?
OSX has a security system that allows third party developers to develop authorisation plugins, in order to provide alternative or additional security, such as finger print scanners, iris readers or anything else you want to provide.
There's a database of rules which states for each type of security access, what security mechanisms are used. You can see this in action when you see the padlock icon in Security Preferences. Clicking on a locked icon brings up a security dialog asking for credentials.
The lock screen and login uses the same mechanism, so with this in mind, it's not too difficult to write a plugin which listens out for a network message (in this case, via bluetooth) from the iPhone, which is sent when the internal gyroscope picks up the knock.
Modifying the security rules database allows the developer to switch the standard login dialog for their security plugin and that's all there is to it.
As for being more secure, I'm not too sure about that; they are, after all, replacing the standard OSX security, which requires a password that is verified through Apple's cryptography.
If someone in your home picked up your iPhone, they can easily knock on it and unlock your Mac, but with a password, only you should know that!
Related
I've been having issues getting these ipads working to our liking in our environment. First of all, we are using an app that syncs calendar with exchange and each ipad has an email address setup that 've configured as a room. It works great but I have a single issue that is bugging us and I cannot figure it out.
We want the screens on 24x7 without any pin or password. Basically disable the pin code or password completely for these devices so we can set the screen sleep to it's 'never' setting.
Where and how do I do this in Exchange? I know Exchange is where this needs to be done but I'm not 100% sure what to do or where to change it. Any help would be appreciated.
I think you are really asking an iPad question, more than an Exchange ActiveSync question.
In iPad Settings > General > Guided Access, you can enable a "kiosk mode". Apple just calls it Guided Access, but what you're effectively doing is locking the tablet to a single application. With the feature turned on, triple click the Home button to lock the application. You can configure a PIN to release Guided Access, or rely on the obscurity of the triple click to unlock the device.
As for ActiveSync, you should create a new ActiveSync policy and assign it to the room mailboxes. Normally a room mailbox account is disabled, but I would imagine your solution gets around that issue.
Creating a new policy can be accomplished in the Office 365 Exchange Admin Center, under Mobile > Mobile Device Mailbox Policies. Click the Plus [+] to create a new policy, give it a name, and configure options. I would advise against not requiring a password. You can leave the "Require sign-in after the device has been inactive for X minutes" option, and I think that will allow you to set the auto-lock to Never.
Finally, I suggest you audit usage of this ActiveSync policy, since it is less restrictive than normal.
You can also create and modify ActiveSync policies using Powershell, using New/Get/Set-MobileDeviceMailboxPolicy. Get and Set-MobileDeviceMailboxPolicy is going to be useful for enumerating some of the more obscure settings and requirements, you might find something useful.
I manage a number of Windows PCs which are used to control equipment. Each computer has a specific program installed which is what people launch to use that equipment. We want to require people to log in before they can access this program.
Currently, I have a wxpython app which just launches that executable when people log in with the correct credentials. However, you can just run the program directly and bypass logging on. I'd like to make a mock logon screen, ie, fullscreen and modal, which only goes away when you log in. Also it should not be able to be bypassed by alt-tab, windows key, etc. How might I accomplish this with wxpython?
There is no full proof way to do this on Windows. You can show a wx.Frame modally using its MakeModal() method. And you can catch EVT_CLOSE and basically veto it it they try to close the frame. However, if they have access to the Task Manager or even Run, they can probably get around the screen. Most users won't be that smart though. You can delete the shortcuts to the apps you want to launch with wx and that will force most normal users to use your login screen. It's only the smart ones who like to troll through the file system who will go around it.
Before Windows 8, the method of adding a mailto: protocol handler was straightforward (as outlined here Register Windows program with the mailto protocol programmatically)
As of Windows 8, the old method no longer works. It would seem that Win8 enforces the following key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice.
It also appears the ProgID of the selected app is hashed and can't be forged, at least not that I can tell.
Does anyone have a working method for this, or can point me at a utility class/code that'll outline how to accomplish this programmatically?
For code, any language will do.
Edit
I've been asked from other discussions to specify a use-case, so I think it'd be helpful in the context of this question. Please consider this screenshot https://github.com/shellscape/Gmail-Notifier-Plus/raw/master/Promotional/prefs-account.png and the checkbox allowing the user to specify mailto handling. In this use-case, no one is forcing the user, the user is in control and makes the decision. While windows 8 store apps (metro/modern) have an available app manifest entry that automates the missing process described above, nothing seems to readily exist for desktop apps.
You can set your application to be activated by a custom protocol (like mailto:). When the user installs your app, if there is no other app supporting that protocol, they are not prompted and you are automatically assigned to that protocol.
If, however, the user already has an app that handles that protocol, then they will be prompted with a list of apps who support that protocol with the option to select the default. You cannot force the user to make a specific selection.
Also, if the user clicks on a protocol (like myprotocol:) and they have no app installed that handles that protocol then they will be sent to the store (app) which automatically searches for all apps that support that protocol. The user then installs whatever they want. You cannot force the user to make a specific selection (if any at all).
I wrote an article on protocol activation. It might be interesting to you: http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
So, I made Desktop Firefox my default mailto handler today in Windows 8 by adding the string value "mailto" to the HKCU\Software\Clients\StartMenuInternet\FIREFOX.EXE\Capabilities\URLAssociations and setting the value of "mailto" equal to the ProgID or "FirefoxURL". I then deleted the keys at HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice to allow me to choose the default client again and this time Firefox was available for me to choose.
The essence of this question seems to be that one cannot take over the default client for any protocol anymore (post Windows 8). The user must choose. However, if you wanted to break the OS convention you could hook the call to create the choose default dialog, which would take research, effort, and be only a temporary kludge and would require "breaking" the OS, or you could send a double click to the dialog to choose for the user, assuming your program has elevated rights so that it can send clicks to Admin windows. That would probably be the easiest way, the user would never know what happened, just a quick flash. Really though, after registering itself as a protocol handler, I don't think any program should go beyond deleting the default protocol handler registry entry, thereby forcing the user to re-choose.
This is how to set mailto protocol manually and simply in Windows 8, 8.1, 2012, 2012R2
Add a new registry branch HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice
Then click any mailto: link in your web browser, say IE
and finally there in a program list for you to choose which was not available before.
Also MAILTO appears in Control Panel\All Control Panel Items\Default Programs now. There is no other option to add/remove a protocol from there.
You can't have your app directly take over file associations anymore in Windows 8. There are guidelines for how to handle this for both Windows Store and desktop applications here: http://msdn.microsoft.com/en-us/library/windows/apps/hh700321.aspx
I'm trying to upload an application to the Windows Phone Marketplace but it keeps failing due to the location privacy policy. In the application there is only one part that checks your location, and the user has to manually call it. Basically we show a map, and a button to locate the user, when this button is pressed for the first time, we show a small privacy policy, and we ask the user to allow the use of his location. And even with this, the application's certification failed.
I'm wondering if anyone has a good example of how the privacy policy should be, and if it should be displayed when the app is first launched, rather than when the locations services are activated by the user (like we are currently doing it). And any other tips or advice you may have.
This is the only part of the certification the app failed, so once I get some good answers, it'll be ready to go.
Thanks!
Make sure to read the Windows Phone 7 Application Certification Requirements.
Section 2.10 specifically applies to your problem.
Microsoft really wants you to have a permanent link to your privacy policy somewhere in the app. Your privacy policy should explicitly explain that you collect this data, how you use it, how you store it, who you share it with, and what the user can do about it. You also need a setting somewhere for the user to turn use of GeoLocation data off.
In my app I have an About screen with a link to the PrivPol, TOS and Tech Support. I also have a settings page with an ON / OFF switch for GeoLocation data. I made sure our privacy policy explicitly addresses location data. And we got through approval with no issues.
YMMV.
Do you have the specific certification requirement (the reference number) ? Here are a couple of links about it in the Windows Phone 7 developers forum:
http://forums.create.msdn.com/forums/p/72366/441401.aspx#441401
http://forums.create.msdn.com/forums/p/63656/390088.aspx#390088
There is a password manager application for the MAC, and I was curious as to how one would go about developing such a fine piece of software.
I don't know much about the mac, just getting into xcode and iphone development actually.
The idea is, when you are at a website, and login it pops-up and asks if you want to save the login/password to the application.
You can also click on a previously saved login, and it will open up firefox and login for you.
How would you know when a browser is open, and when a form gets submitted?
What kind of application would this be i.e. project type in xcode?
I'd start by reading up on KeyChain, since that already does most of the work 1password is doing (i.e. securely storing passwords). As for bring up a prompt in web browsers etc, that's just a plugin for each browser it works with, so you'd have to dive into the plugin documentation for each web browser you wanted to support.
In short, it's not mind bogglingly difficult, but it's not a small task by any means. If you don't care about the browser integration you could probably write a thin wrapper around KeyChain quite easily, though I've never done it, so don't take my word as gospel.