Архив метки: API

Here’s how Google is revamping Gmail and Android security

Eager to change the conversation from their years-long exposure of user data via Google+ to the bright, shining future the company is providing, Google has announced some changes to the way permissions are approved for Android apps. The new process will be slower, more deliberate and hopefully secure.
The changes are part of “Project Strobe,” a “root-and-branch review of third-party developer access to Google account and Android device data and our philosophy around apps’ data access.” Essentially they decided it was time to update the complex and likely not entirely cohesive set of rules and practices around those third-party developers and API access.
One of those roots (or perhaps branches) was the bug discovered inside Google+, which theoretically (the company can’t tell if it was abused or not) exposed non-public profile data to apps that should have received only a user’s public profile. This, combined with the fact that Google+ never really justified its own existence in the first place, led to the service essentially being shut down. “The consumer version of Google+ currently has low usage and engagement,” Google admitted. “90 percent of Google+ user sessions are less than five seconds.”
But the team doing the review has plenty of other suggestions to improve the process of informed consent to sharing data with third parties.
The first change is the most user-facing. When an application wants to access your Google account data — say your Gmail, Calendar and Drive contents for a third-party productivity app — you’ll have to approve each one of those separately. You’ll also have the opportunity to deny access to one or more of those requests, so if you never plan on using the Drive functionality, you can just nix it and the app will never get that permission.

These permissions can also be delayed and gated behind the actions that require them. For instance, if this theoretical app wanted to give you the opportunity to take a picture to add to an email, it wouldn’t have to ask up front when you download it. Instead, when you tap the option to attach a picture, it would ask permission to access the camera then and there. Google went into a little more detail on this in a post on its developer blog.
Notably there is only the option to “deny” or “allow,” but no “deny this time” or “allow this time,” which I find to be useful when you’re not totally on board with the permission in question. You can always revert the setting manually, but it’s nice to have the option to say “okay, just this once, strange app.”
The changes will start rolling out this month, so don’t be surprised if things look a little different next time you download a game or update an app.
The second and third changes have to do with limiting which data from your Gmail and messaging can be accessed by apps, and which apps can be granted access in the first place.
Specifically, Google is restricting access to these sensitive data troves to apps “directly enhancing email functionality” for Gmail and your default calling and messaging apps for call logs and SMS data.
There are some edge cases where this might be annoying to power users; some have more than one messaging app that falls back to SMS or integrates SMS replies, and this might require those apps to take a new approach. And apps that want access to these things may have trouble convincing Google’s review authorities that they qualify.
Developers also will need to review and agree to a new set of rules governing what Gmail data can be used, how they can use it and the measures they must have in place to protect it. For example, apps are not allowed to “transfer or sell the data for other purposes such as targeting ads, market research, email campaign tracking, and other unrelated purposes.” That probably puts a few business models out of the running.
Apps looking to handle Gmail data will also have to submit a report detailing “application penetration testing, external network penetration testing, account deletion verification, reviews of incident response plans, vulnerability disclosure programs, and information security policies.” No fly-by-night operations permitted, clearly.
There also will be additional scrutiny on what permissions developers ask for to make sure it matches up with what their app requires. If you ask for Contacts access but don’t actually use it for anything, you’ll be asked to remove that, as it only increases risk.
These various new requirements will go into effect next year, with application review (a multi-week process) starting on January 9; tardy developers will see their apps stop working at the end of March if they don’t comply.
The relatively short timeline here suggests that some apps may in fact shut down temporarily or permanently due to the rigors of the review process. Don’t be surprised if early next year you get an update saying service may be interrupted due to Google review policies or the like.
These changes are just the first handful issuing from the recommendations of Project Strobe; we can expect more to appear over the next few months, though perhaps not such striking ones. To say Gmail and Android apps are widely used is something of an understatement, so it’s understandable that they would be focused on first, but there are many other policies and services the company will no doubt find reason to improve.

Here’s how Google is revamping Gmail and Android security

6 million users had installed third-party Twitter clients

Twitter tried to downplay the impact deactivating its legacy APIs would have on its community and the third-party Twitter clients preferred by many power users by saying that “less than 1%” of Twitter developers were using these old APIs. Twitter is correct in its characterization of the size of this developer base, but it’s overlooking millions of third-party app users in the process. According to data from Sensor Tower, six million App Store and Google Play users installed the top five third-party Twitter clients between January 2014 and July 2018.
Over the past year, these top third-party apps were downloaded 500,000 times.
This data is largely free of reinstalls, the firm also said.
The top third-party Twitter apps users installed over the past three-and-a-half years have included: Twitterrific, Echofon, TweetCaster, Tweetbot and Ubersocial.
Of course, some portion of those users may have since switched to Twitter’s native app for iOS or Android, or they may run both a third-party app and Twitter’s own app in parallel.
Even if only some of these six million users remain, they represent a small, vocal and — in some cases, prominent — user base. It’s one that is very upset right now, too. And for a company that just posted a loss of one million users during its last earnings, it seems odd that Twitter would not figure out a way to accommodate this crowd, or even bring them on board its new API platform to make money from them.
Twitter, apparently, was weighing data and facts, not user sentiment and public perception, when it made this decision. But some things have more value than numbers on a spreadsheet. They are part of a company’s history and culture. Of course, Twitter has every right to blow all that up and move on, but that doesn’t make it the right decision.
To be fair, Twitter is not lying when it says this is a small group. The third-party user base is tiny compared with Twitter’s native app user base. During the same time that six million people were downloading third-party apps, the official Twitter app was installed a whopping 560 million times across iOS and Android. That puts the third-party apps’ share of installs at about 1.1 percent of the total.
That user base may have been shrinking over the years, too. During the past year, while the top third-party apps were installed half a million times, Twitter’s app was installed 117 million times. This made third-party apps’ share only about 0.4 percent of downloads, giving the official app a 99 percent market share.
But third-party app developers and the apps’ users are power users. Zealots, even. Evangelists.
Twitter itself credited them with pioneering “product features we all know and love,” like the mute option, pull-to-refresh and more. That means the apps’ continued existence brings more value to Twitter’s service than numbers alone can show.

Image credit: iMore
They are part of Twitter’s history. You can even credit one of the apps for Twitter’s logo! Initially, Twitter only had a typeset version of its name. Then Twitterrific came along and introduced a bird for its logo. Twitter soon followed.
Twitterrific was also the first to use the word “tweet,” which is now standard Twitter lingo. (The company used “twitter-ing.” Can you imagine?)

These third-party apps also play a role in retaining users who struggle with the new user experience Twitter has adopted — its algorithmic timeline. Instead, the apps offer a chronological view of tweets, as some continue to prefer.
Twitter’s decision to cripple these developers’ apps is shameful.
It shows a lack of respect for Twitter’s history, its power user base, its culture of innovation and its very own nature as a platform, not a destination.
P.S.:
twitterrific

6 million users had installed third-party Twitter clients

WhatsApp finally earns money by charging businesses for slow replies

Today WhatsApp launches its first revenue-generating enterprise product and the only way it currently makes money directly from its app. The WhatsApp Business API is launching to let businesses respond to messages from users for free for up to 24 hours, but will charge them a fixed rate by country per message sent after that.
Businesses will still only be able to message people who contacted them first, but the API will help them programatically send shipping confirmations, appointment reminders or event tickets. Clients also can use it to manually respond to customer service inquiries through their own tool or apps like Zendesk, MessageBird or Twilio. And small businesses that are one of the 3 million users of the WhatsApp For Business app can still use it to send late replies one-by-one for free.

After getting acquired by Facebook for $19 billion in 2014, it’s finally time for the 1.5 billion-user WhatsApp to pull its weight and contribute some revenue. If Facebook can pitch the WhatsApp Business API as a cheaper alternative to customer service call centers, the convenience of asynchronous chat could compel users to message companies instead of phoning.
Only charging for slow replies after 24 hours since a user’s last message is a genius way to create a growth feedback loop. If users get quick answers via WhatsApp, they’ll prefer it to other channels. Once businesses and their customers get addicted to it, WhatsApp could eventually charge for all replies or any that exceed a volume threshold, or cut down the free window. Meanwhile, businesses might be too optimistic about their response times and end up paying more often than they expect, especially when messages come in on weekends or holidays.

WhatsApp first announced it would eventually charge for enterprise service last September when it launched its free WhatsApp For Business app that now has 3 million users and remains free for all replies, even late ones.
Importantly, WhatsApp stresses that all messaging between users and businesses, even through the API, will be end-to-end encrypted. That contrasts with The Washington Post’s report that Facebook pushing to weaken encryption for WhatsApp For Business messages is partly what drove former CEO Jan Koum to quit WhatsApp and Facebook’s board in April. His co-founder, Brian Acton, had ditched Facebook back in September and donated $50 million to the foundation of encrypted messaging app Signal.

WhatsApp CEO Jan Koum quits Facebook due to privacy intrusions

Today WhatsApp is also formally launching its new display ads product worldwide. But don’t worry, they won’t be crammed into your chat inbox like with Facebook Messenger. Instead, businesses will be able to buy ads on Facebook’s News Feed that launch WhatsApp conversations with them… thereby allowing them to use the new Business API to reply. TechCrunch scooped that this was coming last September, when code in Facebook’s ad manager revealed the click-to-WhatsApp ads option and the company confirmed the ads were in testing. Facebook launched similar click-to-Messenger ads back in 2015.
Finally, WhatsApp also tells TechCrunch it’s planning to run ads in its 450 million daily user Snapchat Stories clone called Status. “WhatsApp does not currently run ads in Status though this represents a future goal for us, starting in 2019. We will move slowly and carefully and provide more details before we place any Ads in Status,” a spokesperson told us. Given WhatsApp Status is more than twice the size of Snapchat, it could earn a ton on ads between Stories, especially if it’s willing to make some unskippable.
Together, the ads and API will replace the $1 per year subscription fee WhatsApp used to charge in some countries but dropped in 2016. With Facebook’s own revenue decelerating, triggering a 20 percent, $120 billion market cap drop in its share price, it needs to show it has new ways to make money — now more than ever.

Facebook loses $120 billion in market cap after awful Q2 earnings

Why unskippable Stories ads could revive Facebook

WhatsApp finally earns money by charging businesses for slow replies

Apple is introducing a health record API for developers this fall

For all of the news that Apple managed to cram into today’s 135-minute(!) WWDC keynote this morning, the event was actually pretty light on health care updates. It was a bit of a surprise, given how much of a focus the company has put on the space at past events.
Apple did announce an interesting health tidbit today on its website today — something that likely just got squeezed out of keynote the event late in the game. Starting this fall, the company will open up health record data to third-party iOS apps through a new API. The feature will make it possible for users to share health data from more than 500 hospitals/clinics with third-party apps.

There are, clearly, some serious concerns around sharing this sort of sensitive data.
The company is addressing this in a couple of ways. For starters, it’s all opt-in, obviously. Your personal information won’t be shared with any apps unless you explicitly allow it to be. The health records are also encrypted and stored locally on the phone.
“When consumers choose to share their health record data with trusted apps,” according to Apple, “the data flows directly from HealthKit to the third-party app and is not sent to Apple’s servers.”
As far as specific applications for such data, Apple points to medication tracking as one of the key case uses. Medisafe will be among the first to use the information in this way, letting users import prescription lists, in order to push reminders, without having to manually enter all of that information in the app.
Disease management is another possibility, for something along the lines of a diabetes app, which customizes recommendations based on health information. There’s also some applications for broader medical research here, providing anonymized health data for laboratory purposes.

Apple is introducing a health record API for developers this fall

LocationSmart didn’t just sell mobile phone locations, it leaked them

What’s worse than companies selling the real-time locations of cell phones wholesale? Failing to take security precautions that prevent people from abusing the service. LocationSmart did both, as numerous sources indicated this week.
The company is adjacent to a hack of Securus, a company in the lucrative business of prison inmate communication; LocationSmart was the partner that allowed the former to provide mobile device locations in real time to law enforcement and others. There are perfectly good reasons and methods for establishing customer location, but this isn’t one of them.
Police and FBI and the like are supposed to go directly to carriers for this kind of information. But paperwork is such a hassle! If carriers let LocationSmart, a separate company, access that data, and LocationSmart sells it to someone else (Securus), and that someone else sells it to law enforcement, much less paperwork required! That’s what Securus told Senator Ron Wyden (D-OR) it was doing: acting as a middle man between the government and carriers, with help from LocationSmart.
LocationSmart’s service appears to locate phones by which towers they have recently connected to, giving a location within seconds to as close as within a few hundred feet. To prove the service worked, the company (until recently) provided a free trial of its service where a prospective customer could put in a phone number and, once that number replied yes to a consent text, the location would be returned.
It worked quite well, but is now offline. Because in its excitement to demonstrate the ability to locate a given phone, the company appeared to forget to secure the API by which it did so, Brian Krebs reports.
Krebs heard from CMU security researcher Robert Xiao, who had found that LocationSmart “failed to perform basic checks to prevent anonymous and unauthorized queries.” And not through some hardcore hackery — just by poking around.
“I stumbled upon this almost by accident, and it wasn’t terribly hard to do. This is something anyone could discover with minimal effort,” he told Krebs. Xiao posted the technical details here.
They verified the back door to the API worked by testing it with some known parties, and when they informed LocationSmart, the company’s CEO said they would investigate.
This is enough of an issue on its own. But it also calls into question what the wireless companies say about their own policies of location sharing. When Krebs contacted the four major U.S. carriers, they all said they all require customer consent or law enforcement requests.
Yet using LocationSmart’s tool, phones could be located without user consent on all four of those carriers. Both of these things can’t be true. Of course, one was just demonstrated and documented, while the other is an assurance from an industry infamous for deception and bad privacy policy.
There are three options that I can think of:
LocationSmart has a way of finding location via towers that does not require authorization from the carriers in question. This seems unlikely for technical and business reasons; the company also listed the carriers and other companies on its front page as partners, though their logos have since been removed.
LocationSmart has a sort of skeleton key to carrier info; their requests might be assumed to be legit because they have law enforcement clients or the like. This is more likely, but also contradicts the carriers’ requirement that they require consent or some kind of law enforcement justification.
Carriers don’t actually check on a case by case basis whether a request has consent; they may foist that duty off on the ones doing the requests, like LocationSmart (which does ask for consent in the official demo). But if carriers don’t ask for consent and third parties don’t either, and neither keeps the other accountable, the requirement for consent may as well not exist.
None of these is particularly heartening. But no one expected anything good to come out of a poorly secured API that let anyone request the approximate location of anyone’s phone. I’ve asked LocationSmart for comment on how the issue was possible (and also Krebs for a bit of extra data that might shed light on this).
It’s worth mentioning that LocationSmart is not the only business that does this, just the one implicated today in this security failure and in the shady practices of Securus.

LocationSmart didn’t just sell mobile phone locations, it leaked them