Zoom announces 90-day freeze feature update to address privacy and security issues

Zoom CEO Yuan Zheng (Eric S. Yuan) said: "In the next 90 days, we are committed to investing the necessary resources to better identify, deal with and proactively solve problems", while also saying: "We are also committed to Be transparent throughout the process. "

It is reported that all engineering resources of Zoom will now focus on privacy and security issues. The company is planning to conduct a "full review" with third parties to ensure that these new consumer cases are properly handled.

Recently, Zoom revealed that privacy and security issues have caused widespread concern. A foreign security officer revealed that the Windows version of the Zoom client is vulnerable to NUC path injection attacks and there are security vulnerabilities, which will cause users to face the risk of privacy leakage when using the application. A few days ago, the US Federal Bureau of Investigation (FBI) warned users to pay attention to the security of the application.

Zoom is a video communication application with only 10 million users in December last year . New users have skyrocketed in recent months due to the surge in the number of people working from home .

Image : Image : https://d24cgw3uvb9a9h.cloudfront.net/static/93880/image/thumb.png

Elizabeth Warren campaign team open-sources its software

Democratic Party presidential candidate Elizabeth Warren withdrew last month due to poor elections, and her campaign team just announced the open source of the software used in the campaign and is proud to use open source software to save money. The technical department of the Warren campaign team relies on open source technology and wants to reward the community, so it decides to open source its important projects for anyone to use. These projects include: Spoke , a peer-to-peer messaging platform , Pollaris , a polling location query tool , front-end and back-end for volunteer support sites , Redhook , a data tool , and more.

Image : https://miro.medium.com/max/2484/1*sJPIuE-VOrXdmzZRJYWm6w@2x.jpeg

Zoom announces removal of Facebook SDK from its iOS client

The new crown epidemic has made Zoom, which provides remote conference services, one of the most high-profile technology companies, and its services are essential for home isolation and remote workers. But Zoom ’s iOS client has sparked criticism and was found to send data to Facebook, even if users do n’t have a Facebook account. The official Zoom blog responded that the reason was that its client used the Facebook SDK. Zoom said that it attaches great importance to the privacy of its users. It uses the Facebook SDK to implement the Login with Facebook function, allowing users to more easily access its platform. It just learned that the Facebook SDK collects information such as device operating system type, version number, time zone, model, screen size, processor core, available storage space, and operator. This information is not necessary for Zoom to provide services, so it decided to remove the Facebook SDK and reconfigure the Facebook login function. After the update, users can still log in with their Facebook account through the browser.

Source : zoom blog
Image : https://d24cgw3uvb9a9h.cloudfront.net/static/93880/image/thumb.png

Apple blocks third-party cookies in Safari

With the release of Safari 13.1 and through updates to the Intelligent Tracking Prevention (ITP) privacy feature, Apple now blocks all third-party cookies in Safari by default.

The company’s move means that online advertisers and analytics firms cannot use browser cookie files anymore to track users as they visit different sites across the internet.

But Apple says the move isn’t actually a big deal, since they were already blocking most third-party cookies used for tracking anyway.

“It might seem like a bigger change than it is,” said John Wilander, an Apple software engineer. “But we’ve added so many restrictions to ITP since its initial release in 2017 that we are now at a place where most third-party cookies are already blocked in Safari.”

Second browser to block third-party cookies for all users

Apple’s Safari has now become the second browser — after the Tor Browser — to block all third-party cookies by default for all its users.

However, while Apple was quicker to block third-party cookies in Safari, Google is actually the one who pushed browser makers towards making this move in the first place, in a May 2019 blog post.

At the time, Google announced plans to block third-party cookies by default in Chrome and in the Chromium open-source project, on which multiple other browsers are built.

Google released Chrome v80 at the start of February with support for third-party cookie blocking (under the name of SameSite cookies), but the feature won’t fully roll out to all Chrome’s users until 2022.

Microsoft’s Edge, which runs a version of Google’s Chromium open-source browser has also begun gradually blocking third-party cookies as well, but the feature is not enabled by default for all its users either.

Apple’s decision today doesn’t mean that Safari now blocks all user tracking, but only tracking methods that rely on planting a cookie file in Safari and (re-)checking that cookie time and time again to identify the user as he moves from site to site.

Other user tracking solutions, such as user/browser fingerprinting, will most likely continue to work.

A small step forward for web privacy

Nonetheless, this is a major step in the right direction. With Google, Safari, Microsoft, and all the other Chromium-based browsers on board, now, the vast majority of current web browsers block third-party cookies or are on their way towards full blocks.

“This update takes several important steps to fight cross-site tracking and make it more safe to browse the web,” Wilander explained in a Twitter thread today.

“First of all, it paves the way. We will report on our experiences of full third-party cookie blocking to the privacy groups in W3C to help other browsers take the leap.

“Second, full third-party cookie blocking removes statefulness in cookie blocking.

“Third, full third-party cookie blocking fully disables login fingerprinting, a problem on the web described already 12 years ago. Without protection, trackers can figure out which websites you’re logged in to and use it as a fingerprint,” Wilander added.

“Fourth, full third-party cookie blocking solves cross-site request forgeries. This is one of the web’s original security vulnerabilities and discussed in communities like OWASP for well over a decade. Those vulnerabilities are now gone in Safari.”

Android lets advertisers get a list of all your apps

A research paper published this week has analyzed the current usage of a lesser-known feature of the Android operating system that could be a danger to user privacy.

The study found that many of today’s top Android apps make use of IAMs (Installed Application Methods), a set of Android OS API calls that allow app developers to get a list of other applications installed on the device.

Google initially created these API calls[1, 2] to allow developers to detect app incompatibilities or fine-tune interactions with other apps. However, the study published this week suggests that IAMs are also being used to track and fingerprint users, posing a palpable privacy risk.

The danger to user privacy comes from the fact that an advertiser could infer interests and personal traits (gender, spoken languages, religious beliefs, age groups) by analyzing a user’s list of installed applications.

In addition, there is also the issue that users can’t protect themselves against IAM-based fingerprinting. This is because IAM calls are “silent methods,” meaning that an app does not need to ask the user for permission before it executes.

Furthermore, many IAM calls are also executed without the app developer’s knowledge. If an app supports an analytics package or an advertising library, researchers found that many of these ran silent IAM API calls without the app developer being aware this was happening.

Analyzing thousands of apps

The research paper published this week looked at all these angles and quantified IAM usage stats in the Android ecosystem for the first time.

This monumental task was carried out by a team of four academics from universities in Switzerland, Italy, and the Netherlands. The research team said it analyzed thousands of Android apps and their respective code, looking for IAM API calls, regardless of their location — the app’s code or a third-party library.

Researchers said they analyzed 14,342 Android apps published in the top categories of the Google Play Store and another set of 7,886 Android applications that had their source code published online.

According to the research team, usage of IAMs is quite common in commercial apps, with 30.29% (4,214) of the Play Store apps making IAM calls within their code. For open-source apps, this number was only at 2.89% (228 apps).

But the research team didn’t just study which apps made IAM calls, but they also looked at what IAM call each app was making in an attempt to understand how and what app developers were trying to achieve through this feature.

The table below speaks volumes.

It shows that almost half of all recorded IAM calls found inside both Play Store and open-source apps were for the packageName IAM call, which retrieves a list of locally installed apps.

All the other IAM calls had a usage percentage of less than 15%, with most being under 1%. Most of these are IAM calls for technical app details, such as signatures, app versions, last update times, or SDK version numbers.

Such calls are often used to debug apps — the primary goal and reason why the IAM API was created in the first place.

However, the high number of queries for the packageName IAM suggests that many apps are getting a list of locally installed apps, and then doing nothing else — indicating a “collection” type of behavior on the part of those apps.

This discovery that IAM calls are most likely used for data collection rather than actual debugging was later confirmed when the research team also looked at the location of the code that executed the IAM call.

What researchers found was that most IAM calls were originating from third-party libraries added to apps, rather than the apps themselves.

“A total of 7,538 and 287 calls to IAMs were detected in commercial and open-source apps respectively (some apps perform more than one call),” the research team said.

“Usages of IAMs in included libraries appear to be more common in commercial apps, where 6,306 (83.66%) of detected calls are performed in code belonging to libraries, while the remaining 1,232 (16.34%) are performed in the apps’ own code,” researchers said. “Concerning open-source apps, 178 usages (62.02%) are performed from bundled libraries while remaining 109 (37.98%) belong to the apps’ own code.”

According to the research team, more than a third of the third-party libraries that they discovered running IAM calls were used for advertising purposes, confirming that IAM calls are now being used as a user data collection mechanism.

A follow-up questionnaire with 70 app developers also found that many developers weren’t even aware that the third-party libraries they used in their apps were performing IAM calls.

“We were not aware that it was used at all,” said one of the developers who answered researchers and completed the questionnaire.

“We aren’t using it. Third-party API? If you can tell me which one I’ll remove it,” said another.

Going forward, the research team urges Google to restrict the use of IAM API calls. According to the research team, the best-case scenario would be if Google would put IAM calls under a permission request. Permissions requests are popups that ask the user if an app is allowed to take an action — in this case, allow the app to retrieve a list of all of their other apps.

More details about this research are available in a research paper titled “Leave my Apps Alone! A Study on how Android Developers Access Installed Apps on User’s Device,” set to be presented this fall at the MOBILESoft 2020 conference in Seoul, South Korea.

Source : http://www.ivanomalavolta.com/files/papers/MOBILESoft_iam_2020.pdf

IOS 14 code leaked: Apple is working with BMW to develop iPhone's "CarKey" feature

Acc to news foreign media 9to5Mac found in the iOS 14 code that Apple is working with BMW. BMW is expected to be the first car manufacturer to support the iPhone CarKey feature .

When asked if it was involved in the relevant project, BMW made a non-denial statement: "At this point, we cannot confirm your request or give you more details. We would like to refer you to our press release . "

The press release involved was published in December last year, and it mentioned BMW's efforts to adopt a new digital key standard for smartphones and watches.

IT House understands that previously, Apple added the CarKey API to iOS 13.4 Beta 1 released in early February.

The system file shows that users will be able to unlock the car with the iPhone / Apple Watch by using the NFC chip inside the car. The iPhone / Apple Watch can be unlocked just by approaching the vehicle, without face ID verification. This feature is only available for NFC-compatible cars.

Hacker selling data of 538 million Weibo users

The personal details of more than 538 million users of Chinese social network Weibo are currently available for sale online, according to reports from Chinese media.

In ads posted on the dark web and other places, a hacker claims to have breached Weibo in mid-2019 and obtained a dump of the company’s user database.

The database allegedly contains the details for 538 million Weibo users. Personal details include the likes of real names, site usernames, gender, location, and — for 172 million users — phone numbers.

Passwords were not included, which explains why the hacker is selling the Weibo data for only ¥1,799 ($250).

However, Weibo’s response has been confusing.

In a statement sent to Chinese site 36kr and many others, the company claims the phone numbers were obtained at the end of 2018 when its engineers observed a series of user accounts uploading large batches of contacts in an attempt to match accounts with their respective phone numbers.

However, several Chinese security experts were quick to point out technical irregularities with the company’s response. First, the hacker’s ad contained indicators that the data came from an SQL database dump, which did not match the company’s explanation that the data was obtained by matching contacts against its API.

Second, the company’s statement also doesn’t explain how the hacker obtained other details like gender and location, information that is not public, nor returned by the API when matching contacts.

Speculation has been rampant on Chinese social media about where the data originated and how the attacker got their hands on it. The theory of a password spray or credential stuffing attack was quickly dismissed when security researchers realized the attacker wasn’t selling passwords.

The hacker, which in some ads went by the name of “@weibo,” also provided samples of the data, which Weibo users confirmed to be accurate.

Weibo said it notified authorities about the incident and that police is investigating.

Due to its near totalitarian control over the internet, Chinese police have been able to track most local hackers with relative ease. In the summer of 2018, another hacker put up for sale the details of millions of hotel guests that stayed at properties from the Huazhu Hotels Group. Chinese police arrested the hacker three weeks later, despite the data being sold on the dark web.