In early July, we helped beacon enable MacAdmins, a large educational Mac administrator conference hosted at Penn State. We saw a great opportunity to use beacons to make check-in fast and easy as well as a way to use beacons in the conference sessions to promote session feedback. We created a beacon-enabled Passbook pass for each participant that showed a lock screen message when in proximity to beacons placed in the conference facility. The passes also had a barcode that was customized to the individual participants’ check-in information contained in cVent.
Prior to the event, we walked around the location and installed our Bleu Station beacons in the registration area and in each of the session rooms. Using iOS software we developed, beacon power levels were tuned so the signal covered only the areas they were in.
Before attendees arrived, we sent out an email to each registered conference attendee that contained a link to their individualized Passbook pass. With a quick tap on the link with their iPhone, the beacon-enabled conference pass was installed into Passbook. When the participants arrived at the Penn State conference center and headed to registration, they had access to the Passbook pass for the conference on their lock screen. The registration volunteers scanned the barcode with an iOS device that checked them in to their registration system, cVent. The attendees were then able to pick up their badge and other conference materials. We tuned the beacons so that the registration lock screen message only showed when in proximity to the registration area. The majority of participants had Bluetooth turned on and had installed the pass, so their registration process was smooth. They thought it was a fast and easy way to check in. For few that managed their Bluetooth settings manually or had not installed the pass, they were able to check in either manually or with a bit of help.
The conference schedule was also tied to the registration pass. MacAdmins used sched.org to manage all of their conference schedules. Sched has a great system that allows others to transfer schedule information easily from their system to ours. We populated the back of the registration pass with the current day’s sessions dynamically, and participants had current session information updated on the back of their pass.
The back of the Passbook pass also had the links to session feedback, and we wanted to remind attendees on their lock screen to fill out session feedback, but didn’t want to have a message always showing on their lock screen. To accomplish this, near the end of each session, we updated the pass to contain a beacon-enabled message reminding the participants to fill out feedback forms. At the start of the next session, we cleared the notification. The result was that only participants in each session room would see the notification, and only at the end of the session.
Proximity and beacons provide a great way to engage people in conferences, and by beacon-enabling the Penn State MacAdmins conference, we showed that beacons can provide value to a conference in interesting and unexpected ways. The best feedback we received from attendees was that it was a natural and intuitive way to keep up to date with the goings on at the conference.
I also presented a session on iBeacons in Education that you can view here.
Not much gets retailers more excited than making it easy for customers to pay. The more barriers store owners can remove from the payment process, the fewer reasons customers have to re-think their purchase—and the better they enjoy the shopping experience.
So it’s no surprise that a number of large companies are interested in owning the mobile payments space. But right now, it looks as though Apple has an advantage with its Passbook app (included with every iPhone) and iBeacon technology.
By setting up one or two iBeacons at the check-out area, retailers can enable mobile payments for smartphone users, provided they have a bar code scanner. As the customer walks up the register, the device recognizes the beacon’s identity and presents a message regarding payment to the customer’s lock screen. Payment takes place via an electronic pass stored in Passbook that’s connected to the customer’s credit card, debit card or store credit card. The cashier then scans the barcode on the phone’s screen to accept payment.
Transactions like these are known as frictionless because the customer never takes out his/her wallet. In a recent article talking about Apple’s strength in the mobile payment market (it has 800 million iTunes accounts, most of them with credit cards attached), iBeacon.com Insider said, “iBeacon will be the lubricant for any friction-less payments system.”
There are several reasons that iBeacons are the right technology to enable mobile payments:
1. Nearly 40% of US smartphones run on iOS. In contrast, Google’s Android platform is fragmented among hardware companies (with 26% of the market, Samsung is Apple’s biggest competitor in smartphone hardware).
2. iBeacons are a one-stop shop for retailers. With a set of beacons deployed around the store, they can enable mobile payments, help shoppers find what they’re looking for, broadcast product specials, promote new products and send personalized coupons.
3. Apple has introduced Touch ID fingerprint sensors on the latest iPhones, addressing security concerns around payments.
4. iBeacons are personal—set up properly, they broadcast a message to the right shopper at the right time. (“Good afternoon, Mary, and welcome to Sports R Us. The bike helmet you recently looked at online is one aisle over, in the middle of aisle 2. Because you’re a valued customer, we’re pleased to take 10% off your entire purchase today.”)
5. iBeacons allow retailers to connect mobile payments with loyalty programs, taking rewards out of the paper-punch era and into programs greatly valued by customers. All rewards and discounts are stored on their phones, making them simple to track and use.
How quickly retailers and customers will adopt and adapt to mobile payments remains to be seen, but we think it’ll be fairly quick, and we’ll definitely be watching this space with interest.
You might know that creating a snapshot image of Boot Camp can be done easily or are already familiar with the benefits of migrating Boot Camp. For those who may be new to Winclone, we have compiled a list of the top ten Winclone tips that will help you save time and prevent common issues when restoring/creating images.
1. Running CHKDSK
Before creating a Winclone image, run the chkdsk utility to fix any disk errors that could cause problems later. As a maintenance practice, you should always run chkdsk in Windows prior to making a Winclone image and shrinking or expanding the Boot Camp file system. Chkdsk is an internal Windows maintenance utility that checks for disk errors and repairs bad blocks.
View the complete walkthrough: http://twocanoes.com/winclone/support/run-chkdsk-to-check-for-errors-before-imaging-with-winclone-4
2. Scheduling Maintenance
Maintaining Windows updates on Boot Camp can be a challenge in an enterprise environment. To schedule reboots into Boot Camp for Windows maintenance windows, the Boot Runner scheduling feature will ensure Windows is ready to receive updates at the right time.
View the video:
3. Shrinking the Windows file system
Before creating a Winclone image, always shrink the Windows file system. This will ensure that the image can be restored to smaller partitions than the original if necessary. Images restored to a larger destination partition will have the file system expanded automatically.
View the complete walkthrough: http://twocanoes.com/winclone/support/shrink-the-windows-file-system
4. One-Click Installation
With Winclone, administrators can provide a self-service for users to download their chosen Boot Camp system and run the one-click package installation to create the partition and restore the selected image.
View the complete video: http://twocanoes.com/winclone/support/create-a-boot-camp-installer-with-winclone-pro
5. Bootcamp Assistant
When setting up Boot Camp on new Macs with 3TB or Fusion drives, make sure to use Boot Camp Assistant to create the Boot Camp partition. Disk Utility does not support core storage, which is used for managing logical partitions on these drive types. When using the Winclone package feature, configure the package to install to the existing partition.
View the complete walkthrough: http://twocanoes.com/winclone/support/installing-windows-on-a-boot-camp-partition-on-a-3-tb-fusion-drive
6. Removing Cache Files
On Macs that are loaded with RAM, Windows cache files can take up quite a bit of space. If storage space or restore time is limited, enable Winclone to remove cache files when creating the image by visiting the preferences pane within Winclone.
7. Restore to Disk Image
To access a Winclone image without needing to restore to a Boot Camp partition, restore to a disk image. If you need to boot into this disk image, use a virtual machine pointed to the disk image.
View the complete walkthrough: http://twocanoes.com/winclone/support/restore-a-winclone-image-to-a-disk-image-to-verify-image
8. Create Snapshots
During the build process for the Windows master, take occasional Winclone image snapshots, especially before major software installations or changes to the file system. The provides multiple “undo” points if something goes wrong.
9. Using Sysprep
When creating a master that will be restored to multiple hardware models, uninstall the Boot Camp application in Windows before running Sysprep. Legacy Boot Camp installations contain hardware information for the source Mac, which will create problems when updating device drivers on different destination hardware.
View the complete walkthrough: http://twocanoes.com/winclone/support/migrating-a-boot-camp-partition-with-winclone-4
10. Troubleshooting Package Installs
If a package installation doesn’t install successfully, check in /var/log/install.log and /tmp/winclone_package.log on the destination Mac for any error events.
View our complete walkthrough: http://twocanoes.com/winclone/support/deploy-boot-camp-as-a-package-using-winclone-pro-4
Sending log files to support
The system Console log can contain helpful troubleshooting information. Enable verbose logging in Winclone preferences, then run the process and extract the relevant Console log information.
To collect log files, select Help -> Send Logs under the Winclone application menu. In the resulting dialog box, click the “Get Logs” button. A Finder window will open to a temporary folder containing the logs in a compressed file named “logs.zip”.
This file can be attached to an email and sent to email@example.com and used to aid in troubleshooting.
As I am sure you have already seen and read, the WWDC 2014 keynote was full of amazing and wonderful things for developers. Although, there wasn’t any mention of iBeacon in the keynote and little mention of proximity, that doesn’t mean that iBeacon was forgotten. It means that it is part of a larger mobility proximity puzzle Apple is solving. A few things are becoming clear:
1. Apple isn’t trying to create a public beacon network. There were prognostications that iOS would allow for discovery of all beacons regardless of which organization deployed them. I doubt this limitation is arbitrary, but rather is something that allows an organization to define their own beacons for their own solutions. As always, the user experience is the foremost consideration, and closely binding the beacons to a customer’s solution helps assure a great user experience. Getting a huge number of arbitrary beacons into the world doesn’t accomplish this if there isn’t a specific solution for a locations’ customers.
2. Running iOS as a beacon in the background isn’t happening. Another “hope” by some was that iOS could advertise as an iBeacon in the background. While this is technically possible, only a single app could advertise as an iBeacon at one time, and this would cause confusion with users as they install different apps that would try to enable this feature and fail. A potential solution to this would be to define a system service that could run as iBeacon in the background, but that would remove the binding of the beacons to a customer’s solution for a great user experience.
3. Beacons are all about proximity, engagement and discovery, not about navigation. Apple has some cool new indoor navigation technology that does not use iBeacon. However, iBeacon is a way to trigger content and engagement when nearby specific areas are at entrances. The new indoor navigation is all about the app being in the front and the actively discovering Wi-Fi signals. This indoor navigation feature is great news for proximity and iBeacon since it allows triggering engagement on iBeacon with nearby interesting areas, but doesn’t try to use iBeacon signals strength for navigation. This means that indoor proximity and navigation options just got a lot richer. App developers and solution providers just got a lot more options for amazing indoor proximity solutions.
4. Beacons advertise as often as they do for user experience. Regardless of the impact to the battery life, beacons advertise multiple times a second to ensure a great user experience. Solutions should provide battery powered versus hard wired beacons based on the deployment realities. Expecting a reduction in user experience for better battery life is not something we should expect from Apple and that is a good thing. It’s also not surprising.
We are entering an era where your iPhone is very much aware of where it is in the world to enhance user experience, and iBeacons play a critical role in that. From the lock screen app recommendations to “Apps near me” to indoor navigation to proximity engagement with iBeacon, iOS 8 is making the iPhone the most proximity aware OS. And that is huge.
Image courtesy of Apple.com
I’m fascinated by the way retailers are deploying iBeacons in their stores. The opportunities to connect with customers are endless.
For starters, iBeacons can broadcast in a specific area of the store (unlike geofencing, which simply forms a large perimeter). An iBeacon near the front door can broadcast an electronic greeting to everyone with your store’s app on their smartphone. For low-price retailers, this is a great opportunity to offer an item coupon or one-day discount. Owners of high-end boutiques might simply welcome customers by name and thank them for returning.
The greeting serves another purpose, too—reminding customers they have the store’s app. This is important if they are part of the store’s rewards program, have a coupon they can use that day, or have a credit on their store account.
The beacon can also be set up to alert a staff person or manager that a frequent customer (or one who’s spent a certain amount in the past year) has walked through the door so they can greet them personally.
Some large stores set up their iBeacons to automatically open the app as an electronic map to help customers find departments or items they’re looking for. Discounts and personal greetings are great, but helping a customer quickly find what they want and speed through check-out is often the best way to delight them. I see this having a huge impact on stores like Ikea and The Home Depot, where it can be tough to find what you’re looking for.
Now, imagine tying wayfinding into online shopping. Bob Smith walks in to a sporting good retailers’ front-door and the retailer’s app is alerted to the front door beacon. The app then alerts the backend system that Bob is now in the store. The system accesses Bill’s online shopping cart, sees a baseball glove was recently added to it, and generates a message asking Bill if he’d like directions to the baseball equipment aisle.
A similar process could take place without the shopping cart. For example, making a suggestion or offering a discount based on past buying history. (“Hi Bill! Did you know those khaki pants you bought a few months ago are on sale today?”) Or maybe the store’s website or app lets customers create a shopping list and displays a map showing the location of each item when they walk in the door.
Of course, as retailers, you have to remember that fine line between helpful and irritating. The more targeted the message, the better—and avoid sending so many that your customers turn off your store’s notifications.
Speaking of targeted, I’m excited about stores that are using knowledge of the customer’s location within the store to provide product information. Imagine you’re standing in an electronics store looking at high-end headphones and you launch the store’s app and the app knows you are in the headphone isle and can offer product information, a celebrity endorsement, recent reviews, or an offer to see which person in your social media circle bought the product you’re looking at within the last six months.
An electronic store replace interactive displays on the wall showing their products in use with a customer demo right on their own phone. When a customer enters a new store area, his/her phone will show product information and videos of products in action.
Here are a few things retailers should keep in mind as they take advantage of beacon-enabled marketing:
- Beacons should be invisible. Some retailers are experimenting with visible beacons. There are two problems with this approach. First, it negates the elegant nature of the invisible beacon. Second, visible beacons are a prime target for theft and can be hard to fit into store décor.
- Beacons should plug into the store’s power source. Some beacons run on batteries, which is convenient right up to the moment the battery runs out.
- Beacons should be carefully tuned. The one in the men’s department should not broadcast so loudly that it spills into the checkout area. Be aware that some brands of beacons are easier to set up and adjust than others.
And don’t forget the checkout area. Retailers can streamline payments by broadcasting a “Check out now” message to lock screens. When the customer slides open the message, it opens to the store account or a special barcode to be scanned by the cashier. It’s fast and convenient—just what you want your customers to remember about their shopping experience.
Now that we understand how beacons work and best practices for keeping them secure, here are some tips for getting the most out of your beacons.
You should consider support costs beyond initial beacon deployment. While battery powered devices may be attractive for easy initial deployment, battery replacement can drive up support costs. A large number of devices means that IT must monitor and replace batteries on an ongoing basis. Battery life is largely dependent on broadcast range and how often broadcasts happen. The better option is a powered beacon, as it does not have batteries which eliminates battery replacement costs. If battery power is required for a beacon deployment, do not depend on best-case estimates from vendors when evaluating battery life. Instead, be sure to test the battery life with the production units and select a beacon with an appropriate battery capacity. Make sure that you test when the beacon is a mode that is within the iBeacon spec. Many vendors will specify battery life with the beacon transmitting at a much lower rate, which can cause issues with iOS.
Since user experience with iBeacon is highly dependent on when the beacon is discovered when entering an area, adjust the power level of the beacon to match the environment and periodically test the user experience in the field.
Apple provides simple and powerful hooks that developers can integrate into their apps to iBeacon-enable them. Beacons should be usable without a specific vendor’s SDK for iBeacon-enabling a customer’s app.
So what’s next for beacons?
In just a short time, we have seen a huge amount of interest in iBeacon. It’s a fast-paced, exciting space with so much potential. iBeacons provide a great way to enhance user interaction based on micro-location. As both Bluetooth LE and iBeacon gain a market foothold, iBeacon solutions will become more common. I expect iBeacon to evolve over time, and see more native support on other platforms such as Android and Windows Phone. Most platforms support Bluetooth LE, but having the hooks for iBeacon in the core operating system is crucial for widespread adoption. Personally, I would like to see the ability to cryptographically sign the advertisement packets so the receiver could verify the identity of the sender. This would increase the advertising information length, so may not be technically feasible with the current standard. Providing a mechanism to verify the authenticity of the advertisement would open up new areas of use.
What do you expect to see from beacons in the future?
Follow Twocanoes on Twitter @twocanoessoft
In the first part of the series, I talked about how beacons worked and the availability of the identifiers that are broadcast out from the iBeacon. Now that we covered the operations of how beacons work, let’s talk privacy.
While an iBeacon broadcasts identifiers publicly, an iPhone does not need to connect to an iBeacon-enabled beacon to get this information. To understand the importance of this, consider an example of how Bluetooth services traditionally work. For a temperature sensor, Bluetooth will advertise that a temperature service is available. An iPhone can listen passively for a service advertisement or can send out a request for this service. Either way, when the service is discovered, the iPhone then connects to the sensor and requests the temperature information. If a third party nearby is scanning for Bluetooth traffic, they will see the traffic and can uniquely identify the iPhone based on a built-in Bluetooth value, known as a MAC address. This is not related to the identifier used for iBeacons, but as part of standard Bluetooth. The iPhone Bluetooth MAC address can be discovered whenever the iPhone is transmitting over Bluetooth. In the example interchange above, the iPhone Bluetooth MAC address would be exposed when requesting a scan or connecting to the temperature sensor. The mobile device could potentially be tracked using the Bluetooth MAC address.
The Bluetooth MAC address of the iPhone is not exposed when getting iBeacon identifier information. iBeacon broadcasts its identifier to the world, but only the beacon’s MAC address is exposed. An iPhone does not need to connect to the beacon to get the required information, so its Bluetooth MAC address is not exposed. Apple’s iBeacon standard allows a beacon to advertise without compromising privacy of the listening devices. This prevents tracking of iPhones based on capturing and tracking Bluetooth MAC address.
Most beacons provide a way to program the identifiers that are used by iBeacon. Since changing the identifiers could provide a way to disrupt the beacon broadcasts (and potentially advertise as a different organization’s beacon), it is important to prevent unauthorized users from gaining access.
To prevent unauthorized access, the beacon must be able to support the following areas:
Authorized Access Prevention
The use of credentials to change settings is critical. Simply making it difficult to discover how to connect the beacon to change settings is not sufficient. Setting a complex password with sufficient length can prevent people from trying to guess the password. Having a mechanism to detect unauthorized authentication attempts and initiate progressively longer timeout periods between authentication attempts helps prevent brute force password attacks.
Beacons should not all have the same or similar passwords. Organizations should have the ability to set unique passwords for each beacon and should not deploy using the default vendor password.
All authentication should be done over an encrypted channel and passwords should not have the ability to be extracted from the physical beacon. Since Bluetooth pairing to a beacon is usually done using Secure Simple Pairing that does not require an out-of-band password, initial pairing should be done in an area that is free from unauthorized scanning of the Bluetooth network.
Provide a mechanism for updates
Since security vulnerabilities can be discovered at any given time, it is important to get timely security notifications and firmware updates to keep the beacons secure. Beacons must support the ability to update the software on the beacons themselves.
Reduce Attack Surface Area
Since iBeacon is a broadcast only protocol, administration must be done while the iBeacon is not acting as an beacon or over a different communications channel, for instance another Bluetooth radio. Beacons must not allow service connections when deployed and broadcasting as an iBeacon. This reduces the attack surface area since an attacker could not connect to the beacon, making it difficult for automated attacks.
Beacons should be placed in physically secured environments to prevent theft, tampering, and placing in administrative mode. Beacons can be placed with other infrastructure equipment that is secured in cabinets, behind counters, or physically attached and secured. While attaching to display walls may ease initial deployment, it is an easy target for theft and vandalism in many environments.
Next in the series will be some tips and tricks to help get the most out of your beacons.
Two words you keep hearing are iBeacon and security. What is a beacon? How do you keep them secure? It’s important when deploying iBeacon technology to understand how beacons are used and appropriate ways to assess beacon security. Let’s start off simple.
How do beacons even work?
Beacons that support iBeacon-technology do not broadcast content (such as coupons or contact information), they broadcast identifiers that can be received by iOS. An app running in iOS can then use that identifier to do things. Let’s break down what this identifier is and what it does. Three different pieces make up the identifiers: a universal identifier (UUID), a major number, and a minor number. The UUID is a very large number that organizations can generate on their own and have confidence that it will not conflict with another organizations’ UUIDs. iOS makes it very easy to limit discovery of beacons to your organization’s defined UUID, while ignoring UUID’s defined by other organizations. While this could be viewed as a limitation of the technology, generating identifiers in a non-centralized way allows organizations to “brand” their beacons which, in a future awash in beacons, will be crucial for apps to be more than beacon-aware, but beacon-intelligent. This UUID scheme illuminates the path for how large-scale iBeacon deployments will be conducted: not apps that discover all beacons, but apps tuned to discover an organization’s beacons and ignore the rest.
It should be noted that UUID assignments are not part of a beacon security strategy, despite the ability to uniquely assign the company beacons. Unique IDs do not mean the broadcast information is at all private or secure. Using a Bluetooth sniffer or a Bluetooth discovery app can discover the identifiers. It is also relatively trivial to broadcast another organization’s identifier. That doesn’t make iBeacons are insecure, but indicates misplaced security concerns. Take a Wi-Fi network’s name, or SSID, for example. It is not possible to stop others from using the same network name, but you can use the network name as way to infer location. Combined with other information, this can help accuracy and speed positioning. iBeacons can be viewed in a similar way. The identifiers should not be used as keys to unlock protected resources, but as one among several reference points to determine location and proximity.
A great illustration can be found in iBeacons used with Passbook on iPhone. An iBeacon is not used to validate or redeem Passbook passes, but to determine when the pass will appear on the lock screen. The actual redemption takes place when the pass is scanned by a barcode scanner. We implemented a similar strategy during the Macworld 2014 iBeacon Scavenger Hunt. Initial ideas for the game involved showing a clue on the iPhone screen when participants arrived in a certain area. That clue would point participants to another iBeacon-enabled area which in turn will show the next clue. The problem with this strategy was that the protection of the valuable resource (in this case, the clue) was based on proximity to the iBeacon. It would be trivial for someone to set up their own iBeacon and use it to discover all the clues and game the system. To prevent this, we added in some physical security. When the participant entered a beacon-enabled area, it triggered the iPhone to show a hint to locate the clue on physical signage and scan a QR code associated with that clue. Someone who might set up an iBeacon to steal the clue would not be able to complete the scavenger hunt without physical proximity to the QR code on the sign.
iBeacons should be viewed as one of several reference points for microlocation. Apps can validate beacon broadcast reception against other information to determine validity including a local Wi-Fi network, geolocation, or other information available to the app. While someone could set up a spoof beacon, it would be much more difficult if an app verifies beacon data with discovery of GPS locations. iBeacons provide an effective way to quickly discover microlocation, but this capability should be used to enhance user interaction rather than protect resources.
In the next post we’ll dive deeper into some of the questions around beacon security. Should beacons be physically secured? What if a beacon ID is spoofed? What are the risks to customers receiving the beacon broadcasts?
Obviously, when we attend conferences, the goal is to gather information and make connections. But so many things are working against us—like huge crowds and vast aisles of booths—that sometimes we end up wandering past the items we came to the show to see.
iBeacons like Bleu Station turn that on its head, making large conferences a huge win for everyone involved: event organizers, vendors, and attendees.
It starts with your online registration. After you pay the conference fee, you’re prompted to download a beacon-enable app and state your interests. When you arrive at the show, the phone recognizes the beacon and facilitates check-in. Then, as you walk the show floor, messages appear on your lock screen whenever you’re near a booth or event of interest.
iBeacons also solve those awkward information exchanges at vendor booths. Rather than asking for a business card to scan or renting a badge scanner, vendors just ask you to touch your phone to their beacon.
The device lets the app on your phone know what vendor is associated with the beacon and can then send your contact information as a vCard to the vendor, and the exchange can include a link download (to the vendor’s website or an app) to your phone. Vendors can configure the system to create a post-show report with contact information for every attendee they interacted with; show organizers can get data to quantify the number of overall vendor-attendee interactions.
iBeacons are the best way to make sure you see everything that falls within your areas of interest and find the booths you want to visit. No need for a map of the show floor—just use the show app to search for a booth location and get directions from where you’re standing.
For event organizers, iBeacons are a way to combat attendees’ tendency to become overwhelmed and disengage. It starts with that streamlined check-in, which ensures fast, pleasant entry into the show. It continues with improved wayfinding and messages about areas of interest. Gamification takes things a step further, with iBeacon-enabled scavenger hunts and other events designed to make sure attendees go home feeling good about the quality of information they gathered.
The iBeacons at March Macworld/iWorld in March and the most recent SXSW conference were enthusiastically received, but I think we’ve only scratched the surface. In the next few months, I expect conference centers to jump on board to beacon-enable their facilities as attendees start to expect proximity capabilities to pump up their show experience.
AWS Web console
Even though the data is sent over an encrypted channel via SSL, it still seemed to me a bad idea to send the cleartext password to the service unless the user is creating an account or changing their password. I am not the first one to notice this. My major concern is two fold:
1. Most people have 4 or 5 passwords that they use for most services, and if the first one fails, they try the others. This gives the services you are authenticating to a trail of all the common passwords you use. You may trust the larger sites, but what about for services that you are not that familiar with? Just giving them your “standard” password may be risky, but giving them all of your previous and common passwords seems like a bad idea. It is also possible that those services log each of your password attempts and may even capture the data to a database.
2. In some corporate environments, users are forced to use HTTPS proxies. This means that data is only sent in an encrypted channel between the proxy and the service, and IT would be able to see your cleartext password if you used one of these services.
It looks like the solution would be to use something like SJCL , jCryption or NoSSL. It seems that for compatibility-sake, this is common practice.
This does highlight using OAuth with smaller web services. If you already trust Facebook or Gmail with your password(s), and you use OAuth to log into these smaller sites, your password is never shared with those services. Your OAuth provider would still require authentication on their web form and would have access to any password you type in the login form, but at least you would not be sharing that information with unknown services. Recently, I have stopped using OAuth from Twitter or Facebook due to a service that required the ability to post to those services on my behalf as well as posted ads to that service without asking me first.
The bottom line: this password situation is not so great. Users need to figure out who to trust,even though that keeps getting more and more difficult. Also know, the should be basic fact that your trusted service might not really be about authentication but about social and sharing.
NOTE: Updated with copy edits for grammar on 14 April 2014.