This year, in lieu of a golden ticket to San Francisco, I had the opportunity to organise a meetup in Adelaide to watch the Keynote live at 2:30am. Not expecting more than a handful of people to turn up at 2am on a weekday morning, I was surprised to have 12 other Apple enthusiasts in town rock up. So with some comfortable chairs set up, enough sugar and Red Bull to keep us awake for at least 24 hours straight we watched the live stream over the Apple TV.
Because these individual blogs have separate RSS feeds you may not have seen this post.
Interesting to think if this will coincide with some third-party Touch ID capability to further increase security of these kinds of withdrawals.
Bank smartphone apps in general would greatly benefit from a basic authorisation feature provided by Touch ID.
"Siri, how many days until WWDC?" — 33 days.
One of iBeacons greatest attributes is that it allows end-users to control their location privacy and still benefit from location awareness in applications. With the shift from GPS coordinates to the presence of a physical iBeacon it no longer requires persistent location awareness or allow an application to track precise location information at will.
With iBeacon, end-users need not worry that a particular application may be snooping their current location or if that data is visible to anyone else as it goes through 'the wire'. A huge relief in light of the revelations around the NSA programs.
Unfortunately, this concise differentiation isn't passed on to the end-user in iOS. When the application requests to monitor an iBeacon region what the end-user will see is the same request for an application to access their current, precise location.
Whilst it is somewhat accurate, an iBeacon is fixed to a particular location, it doesn't convey that when outside the receivable region of the beacon the application has no way of tracking your location if its only using Core Locations iBeacon regions. However, I believe this clear differentiation needs to be expressed properly to the end-user to inform them about the applications intent and capabilities with what its requesting. A basic example of the OS handling this would be a message like so.
This would require that inside of Core Location the request is expressly for — all or mixed options of — iBeacons, GPS locations or Geofencing which is then reflected correctly in the message. However, this may be a problem because of the current implementation of region monitoring is that it can be made at any time in execution. Multiple and mixed region or location monitoring requests may be made independently of one another and not combined in one alert message. This will not be a viable solution for an OS initiated message.
At this time and most likely into the future it will be the responsibility of the developer and their applications presentation to clearly convey their intentions and usage of iBeacon regions. When using iBeacons the request reads the same as "I want your GPS location whenever I want" which is — rightly so — becoming more frowned upon by end-users.
Its up to the developers to be responsible about their location information requirements and educate the end-user consistently as a whole so this truly magnificent technology can be widely adopted and — most importantly — trusted by end-users to reduce the need for GPS location awareness.
One of the four trademark applications classes the use of 'iBeacon' for "financial services". Wether that is just a general cover for integration with Passbook or something larger only time will tell.
LINKEDIN just gave its users another reason to ensure their resumes are up to date. The online professional network has introduced a mobile feature that shows information about people's careers in emails being read on iPhones.
The feature released Wednesday works with Gmail, Yahoo Mail, AOL Mail and Apple Inc.'s iCloud when any of them are plugged into the iPhone's built-in email app. LinkedIn plans to update the feature so it also works with Microsoft Outlook.com and Exchange email. It's available at https://intro.linkedin.com/
So how exactly does LinkedIn display a users LinkedIn profile when viewing an email from them in iOS's Mail app?
IT USES AN IMAP PROXY TO INJECT HTML INTO THE USERS EMAIL . Read that again.
Employees can route all of their email through a IMAP proxy, after providing LinkedIn with their email credentials, under LinkedIn's control. Not only is a massive personal privacy violation, granted it is done with the user kind of knowing what they are getting into (opt-in), but it also is a bigger enterprise issue.
Any internal and sensitive business information circulated to staff can be read by LinkedIn or anyone with access to their proxies. Moreover, an employees email credentials may be the same for enterprise applications (VPN, RDP) allowing potential intrusions.
LinkedIn may have 'good intentions' but that doesn't matter. Someone could access those proxies and read the information or worse get access to the stored credentials for those email services. From there the third-party can go to town.
To make a bad situation worse the supplied article appears to be a press release. Absolutely no research or concerns about the potential privacy and security risks.
The author? AAP Staff Writers.
LinkedIn's Engineering blog has a post talking about how they built LinkedIn Intro. Here's one thing that concerns me:
- Whole article: ~1,509 words
- Words talking about security & privacy: 55 words.