Featured: Meet Stephanie Izard, Top Chef
CHEF STEPHANIE IZARD (Forkly: @Stephandthegoat)
Apart from her fabulous Forkly photos, most Forkly users know Chef Izard as the winner of Bravo’s Top Chef - Season Four.
After her huge and historical Top Chef win (she was the first female chef ever to win the title of Top Chef), Chef Izard opened the Girl & the Goat in Chicago—voted by Saveur Magazine as “America’s Best New Restaurant” and nominated in 2011 for the James Beard Best New Restaurant Award. In 2011, Stephanie also released her new cookbook, Girl in the Kitchen, and was named one of Food & Wine Magazine’s “Best New Chefs.” She is now working on her second restaurant, “Little Goat.”
Taste Tip for your next visit to Girl & the Goat: Chef Izard just rotated the Wood Grilled Broccoli back onto the menu—a spring menu staple and customer favorite. Stephanie especially likes the “spiced crispies” part of the dish.
All in all, us Forkly fans have plenty to get excited about as we get first glimpses of Chef Izard’s tastes from one post to the next!
Happy Tasting from the Forkly crew!
Introducing Forkly 2.0.6: Camera+ Integration, Local Food Friends, and more…
Great news! Only a month after the release of 2.0 we have another round of major updates for you: Forkly 2.0.6 for iPhone. Take a look at some of the great features available to you with this update.
Get Forkly 2.0.6 now:
If you have Camera+ (version 3+) installed, you can now use it when taking a photo directly from the app. Food photography can be a challenge, Camera+ is a great tool for making your shots look as tasty as ever!
We find using the “Clarity” or “Food” filters, in addition to the “Miniaturize” effect, produces some great results when taking pictures of food.
Try it for yourself: get the Camera+ update.
Days of the two-step process—Forkly restaurant searches followed by booking OpenTable reservations—are long gone! We’ve added the ability to reserve a table directly from within the Forkly app. It couldn’t be easier: Discover, reserve, taste, and rate. The “Reserve now” button will appear on the venue screen if OpenTable is available at that place.
Forkly’s Privacy Policies in a Letter to Congress
Last week we received a joint letter from House representatives Henry Waxman (D-CA) and G.K. Butterfield (D-NC). The U.S. Congress selected a total of 34 iOS developers to respond to a questionnaire that aimed to better understand privacy, information collection, and the best practices for Apple mobile devices.
Privacy practices were recently brought to the forefront when somebody discovered that Path and other mobile apps upload their users’ entire address book contents without asking their permission. We previously discussed best practices around this here.
It’s important to note that Congress selected Forkly based on being associated with the App Store’s “iPhone Essentials” list, not based on questionable privacy practices. In full disclosure of our privacy practices—and because we’re proud of our track record—we’ve posted our responses to Congress below.
The letter begins with the following statement followed by the questions and our responses:
We are writing to you because we want to better understand the information collection and use policies and practices of apps for Apple’s mobile devices with a social element. We request that you respond to the following questions regarding the Forkly app:
- Question: Through the end of February 2012, how many times was your iOS app downloaded from Apple’s App Store?
Response: The number of times that the Forkly iOS app has been downloaded is proprietary company information. The disclosure of such information could cause Forkly a competitive disadvantage. Therefore, we respectfully decline to provide such specific information.
- Question: Has your iOS app at any time transmitted information from or about a user’s address book? If so, which fields? Also, please describe all measures taken to protect or secure that information during transmission and the periods of time during which those measures were in effect.
- Question: Have you at any time stored information from or about a user’s address book? If so, which field? Also, please describe all measures taken to protect or secure that information during storage and the periods of time during which those measures were in effect.
- Question: At any time, has your iOS app transmitted or have you stored any other information from or about a user’s device - including, but not limited to, the user’s phone number, email account information, calendar, photo gallery, WiFi connection log, the Unique Device Identifier (UDID), a Media Access Control (MAC) address, or any other identifier unique to a specific device?
Response: Forkly transmits and stores push notification device tokens for users in order to support Apple Push Notifications, in accordance with the technical documentation provided by Apple here.
In order to provide location-relevant information to the user, we transmit the device’s location when needed.
As part of the Forkly beta program, we indirectly collect a beta tester’s device UDID through TestFlight (http://testflightapp.com).
- Question: To the extent you store any address book information or any of the information in question 5, please describe all purposes for which you store or use that information, the length of time for which you keep it, and your policies regarding sharing of that information.
Response: Forkly does not store any address book information. Forkly stores push notification device tokens to support sending push notifications to users. We keep this information until the user deletes their account, and/or until Apple’s Feedback Service (documented here) notifies us that a device token has had failed delivery attempts (this generally happens when a user uninstalls the app from the device). We do not share this information with third parties.
We use a device’s location in order to show nearby venues, make nearby restaurant suggestions, show users in the same metro area, and to verify that a user is in the general area of where they are posting a taste. We do not store this information beyond server logs which are used for debugging, and which are expunged every few weeks. We do not share this information with third parties.
We indirectly store a beta tester’s device UDID through TestFlight (http://testflightapp.com) in order to provide them with an ad-hoc build of our app for testing. We keep this information in TestFlight until the user is no longer part of the Forkly beta program, or they remove the device directly through TestFlight.
- Question: To the extent you transmit or store any address book information or any of the information in question 5, please describe all notices delivered to users on the mobile device screen about your collection and use practices both prior to and after February 8, 2012.
Response: Forkly does not store any address book information. As described in response to Question 5 above, Forkly stores push notification device tokens to support sending push notifications to users. Users must explicitly opt in to receive push notifications when they first open the Forkly app through a pop-up dialogue. This is a built-in feature of iOS, and the Forkly app does not get access to a push notifications device token until after the user opts in.
Users must explicitly opt in to make their device’s location available to Forkly when they first open the Forkly and/or when they access location-relevant features, whichever comes first. This is a built-in feature of iOS, and the Forkly app does not get access to the device’s location until after the user opts in.
- Question: The iOS Developer Program License Agreement detailing the obligations and responsibilities of app developers reportedly states that a developer and its applications “may not collect user or device data without prior user consent, and then only to provide a service or function that is directly relevant to the use of the Application, or to serve advertising.”
(8a) Question: Please describe all data available from Apple mobile devices that you understand to be user data requiring prior consent from the user to be collected.
Response: Address book data, calendar data, media library data, Twitter account information. None of which are accessed by the Forkly iOS app.
(8b) Question: Please describe all data available from Apple mobile devices that you understand to be device data requiring prior consent from the user to be collected.
Response: UDID, device location, system log
(8c) Question: Please describe all services or functions for which user or device data is directly relevant to the use of your application.
Response: For Forkly, we rely on a push notification device token in order to send push notifications to the user. We also rely on the device’s location information in order to show nearby venues, make nearby restaurant suggestions, show users in the same metro area, and to verify that a user is in the general area of where they are posting a taste.
- Question: Please list all industry self-regulatory organizations to which you belong.
As evident by our responses above, our goal was to be fully transparent not just with Congress but with Forkly users, the iOS development community, and the general public. We are proud of our practices and wanted to reiterate them publicly: we will continue to respect the privacy of our users as Forkly grows. In posting publicly, we hope that other iOS developers (beyond the 34 selected by Congress) will follow suit and take a moment to answer the same questions—if not for the sake of adhering to privacy practices, then for the sake of their users and online community.
Introducing Forkly v2.0
Since we launched Forkly in September 2011 we’ve seen some pretty amazing things happen. Thanks to you we’ve experienced growth of a great community full of amazing food and drink discoveries. We’ve been featured by Apple as App of the Week UK, chosen in the Top 5 Apps of 2011 UK and added to Essential Apps for Foodies in the US App Store, and its only been five short months.
Today we’re excited to announce the next generation of features and a substantially upgraded design. Say hello to Forkly 2.0. - Available now on the App Store.
Forkly has been largely redesigned making it easier to Discover, Want and Rate dishes you love. More importantly this release exposes the personal and social power of Forkly’s ‘intelligent menus’. You can now browse menu items with a level of understanding and guidance never possible before. Below we’ve highlighted some of the new concepts behind the 2.0 release.
Intelligent Menu Items at Places
Forkly menus will show you the “Most Popular Items”, whats good at a place, the average rating on a dish and what your friends thought. Additionally, Forkly will remind you if you have any “Wants” (items you’ve bookmarked) and/or “Hads” (things you’ve tried there before and what your rating was).
Revamped Feed - faster with bigger photos
We’ve redesigned the feed with larger photos and inline comments. This makes it easier to “Want” items (just double tap) and see what others have to say.
Personalized Dish Recommendations by Category
The new Discover can now give you personalized dish recommendations base on category. We’ve also added the ability to browse dishes in other locations, perfect for finding a restaurant across town or a dish in a city you’re about to visit.
Tastemakers, Influence, Featured Users, and Updated Profiles
We’ve upgraded the profile design and added better tools for connecting with friends and others who love great food and drink. Additionally we’ve added improvements around influence points and Tastemakers at places.
Your enthusiasm in Forkly has motivated us to stay up late nights to bring you this new release, so far we “Love it”. We can’t wait for you to download it and discover something tasty.
Forkly 2.0 is available today for your iPhone or iPod touch from the App Store.
PathGate and Best Practices for Implementing “Find Friends”
Yesterday, somebody discovered that Path and other mobile apps upload the entire address book contents of a user’s phone to their servers. If you’re not familiar with the backstory, read the links above.
I know the guys at Path well, and I’m sure they had only the best intentions in mind. In my opinion, they handled this about as well as they possibly could have after the news broke.
Some people gave Dave Morin some grief for this statement:
2. This is currently the industry best practice and the App Store guidelines do not specifically discuss contact information. However, as mentioned, we believe users need further transparency on how this works, so we’ve been proactively addressing this.
In saying that, he is mostly correct. Apple’s App Store guidelines do not specifically discuss contact information, and most apps that implement “Find Friends” functionality using the internal address book do it this way.
The one point that I disagree with is the “best practice” statement. I think what he meant to say here is “common practice”. Why? It’s been handled in a better way in the past. How do I know this? Because we built it, over 3 years ago.
A Better Way
The point of uploading the user’s address book information to the Path servers is to match potential friends who are also using Path, and notify the user when one of their friends joins. I think that’s good functionality and users appreciate it.
Over 3 years ago, we were working on the now defunct Brightkite iPhone app, and were building similar functionality to help our users find their friends on the service. When we were discussing the implementation, the first iteration inevitably lead to the same strategy that Path is using: upload the user’s address book information to our servers so we can do the matching.
But it didn’t feel right. I could already see the headlines about the privacy issues once people discovered what we were doing, very much like the headlines we saw yesterday. So we tried harder, and gave the whole issue some more thought. It didn’t take very long before we realized that we didn’t actually need the actual phone numbers and email addresses of people to match them; we just needed their hashes.
For those unfamiliar with hashes, a hash is the result of a one-way function that takes some input (in our case, an email address or phone number) and spits out something that looks like this:
2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12
The important characteristics of a hash are:
- Identical inputs will yield the same hash
- It is virtually impossible to deduce the original input from a hash if a strong hashing algorithm is used.
So, instead of sending a user’s address book contents to our servers, we only sent the hashed entries (with some normalization, such as lowercasing strings, and cleaning up phone numbers prior to hashing).
Then, we could just compare the hashes on our servers and inform our iPhone app that entry X in a user’s address book matches Brightkite user Y, all without ever “seeing” any actual phone numbers, names or email addresses. This enabled us to implement the same “Find Friends” functionality that so many apps nowadays use without compromising the privacy of the address book.
Apple’s Share of the Blame
Lastly, I wanted to take this opportunity to point out that Apple is to blame for some of this situation as well:
- As Dave stated, Apple doesn’t have any clear guidelines around accessing and using the internal address book.
- iOS doesn’t prompt the user for permission when an app tries to access their address book information.
I’ve had Apple developer evangelists actually tell me that in order to make signup to our apps easier, we should look for the “Me” card in the address book and pre-fill the signup form. While that seems like a great idea at first, I can’t help but wonder how people would feel if they saw this being pre-populated (“How do they know my personal information?!?”).
With regards to prompting for permission, this one just seems plain silly. iOS prompts you if an app wants to use your location, or wants to send you push notifications, but not if it wants to access your address book. Even my old Nokia 6620 did that, in 2004 mind you.
I would feel better if Apple added such a prompt, and I think they will, eventually.
While we didn’t opt to offer address book friend finding in Forkly (yet), I hope that this blog post helps those who are looking to implement such a system in their own apps.
Let’s get honest about uptime - Forkly’s Take
David from 37signals wrote a blog post today about uptime, and is calling for more transparency about actual uptime of services.
In that spirit, we’d thought we’d share our stats for the last year, directly from our monitoring tool of choice, Pingdom.
Note that, like David, we’re not “juking the stats” by omitting “scheduled” downtime.
We’re happy with our 99.93% uptime (which is incidentally the same as for 37signals’ own Basecamp), but we’ll try to improve on that number for 2012.
Forkly Picks: 10 Favorite Beers Tasted in 2011
Before we bid the year goodbye, let’s take a look back at some of our favorite beers tasted in 2011. Here they are (in no particular order):
What are some your favorites this year?
Forkly Wins “Best Food App”
Thanks to all of you, we walked away with “Best Food App” at the Westword Web Awards. Hooray!
Read about it here.