you can get this functionality by downloading and installing a simple app from the Google Play Store: Access Dots. It’s free, it’s easy, and it helps you up your Android’s security game. I would almost call it a must-install for anyone, because it’s as unobtrusive as it is helpful.
Download and launch the app, and you’ll see one simple setting you have to enable. That’s all you have to do to fire up Access Dots’ basic functionality.
Screenshot: David Murphy
Well, that and tapping on the new “Access Dots” listing in your Accessibility settings, and then enabling the service there, too.
Screenshot: David Murphy
Head back to your Android’s Home screen and…you won’t see anything. Zilch. That’s the point. Pull up your Camera app, however, and you’ll see a big green icon appear in the upper-right corner of your device. Tap on your Google Assistant’s microphone icon, and you’ll see an orange dot; the same as what iOS 14 users see.
Screenshot: David Murphy
If you don’t like these colors, you can change them to whatever you want in Access Dots’ settings. You can even change the location of said dot, as well as its size. Tap on the little “History” icon in Access Dots’ main UI—you can’t miss it—and you’ll even be able to browse a log of which apps requested camera of microphone access and for how long they used it:
Though I’m not a huge fan of how many ads litter the Access Dots app, I respect someone’s need to make a little cash. You only see them when you launch the app. Otherwise, all you’ll see on your phone are those dots. That’s not a terrible trade-off, I’d say, given how much this simple security app can do.
Waydev, a San Francisco-based company, runs a platform that can be used to track software engineers’ work output by analyzing Git-based codebases. To do this, Waydev runs a special app listed on the GitHub and GitLab app stores.
When users install the app, Waydev receives an OAuth token that it can use to access its customers’ GitHub or GitLab projects. Waydev stores this token in its database and uses it on a daily basis to generate analytical reports for its customers.
Waydev CEO and co-founder Alex Circei told ZDNet today in a phone call that hackers used a blind SQL injection vulnerability to gain access to its database, from where they stole GitHub and GitLab OAuth tokens.
The hackers then used some of these tokens to pivot to other companies’ codebases and gain access to their source code projects.
An annoying vulnerability in the widely used GRUB2 bootloader can be potentially exploited by malware or a rogue insider already on a machine to thoroughly compromise the operating system or hypervisor while evading detection by users and security tools.
[…]
Designated CVE-2020-10713, the vulnerability allows a miscreant to achieve code execution within the open-source bootloader, and effectively control the device at a level above the firmware and below any system software. Bug hunters at Eclypsium, who found the flaw and dubbed it BootHole, said patching the programming blunder will be a priority and a headache for admins.
To be clear, malware or a rogue user must already have administrator privileges on the device to exploit the flaw, which for the vast majority of victims is a game-over situation anyway. You’ve likely lost all your data and network integrity at that point. What this bootloader bug opens up is the ability for a determined miscreant to burrow deeper, run code at a low level below other defenses, and compromise the foundation of a system to the point where they cannot be easily detected by administrators nor antivirus.
The sources of the stone used to construct Stonehenge around 2500 BCE have been debated for over four centuries. The smaller “bluestones” near the center of the monument have been traced to Wales, but the origins of the sarsen (silcrete) megaliths that form the primary architecture of Stonehenge remain unknown. Here, we use geochemical data to show that 50 of the 52 sarsens at the monument share a consistent chemistry and, by inference, originated from a common source area. We then compare the geochemical signature of a core extracted from Stone 58 at Stonehenge with equivalent data for sarsens from across southern Britain. From this, we identify West Woods, Wiltshire, 25 km north of Stonehenge, as the most probable source area for the majority of sarsens at the monument.
A handful of Chrome users have sued Google, accusing the browser maker of collecting personal information despite their decision not to sync data stored in Chrome with a Google Account.
The lawsuit [PDF], filed on Monday in a US federal district court in San Jose, California, claimed Google promises not to collect personal information from Chrome users who choose not to sync their browser data with a Google Account but does so anyway.
“Google intentionally and unlawfully causes Chrome to record and send users’ personal information to Google regardless of whether a user elects to Sync or even has a Google account,” the complaint stated.
Filed on behalf of “unsynced” plaintiffs Patrick Calhoun, Elaine Crespo, Hadiyah Jackson and Claudia Kindler – all said to have stopped using Chrome and to wish to return to it, rather than use a different browser, once Google stops tracking unsynced users – the lawsuit cited the Chrome Privacy Notice.
Since 2016, that notice has promised, “You don’t need to provide any personal information to use Chrome.” And since 2019, it has said, “the personal information that Chrome stores won’t be sent to Google unless you choose to store that data in your Google Account by turning on sync,” with earlier versions offering variants on that wording.
Nonetheless, whether or not account synchronization has been enabled, it’s claimed, Google uses Chrome to collect IP addresses linked to user agent data, identifying cookies, unique browser identifiers called X-Client Data Headers, and browsing history. And it does so supposedly in violation of federal wiretap laws and state statutes.
Google then links that information with individuals and their devices, it’s claimed, through practices like cookie syncing, where cookies set in a third-party context get associated with cookies set in a first-party context.
“Cookie synching allows cooperating websites to learn each other’s cookie identification numbers for the same user,” the complaint says. “Once the cookie synching operation is complete, the two websites exchange information that they have collected and hold about a user, further making these cookies ‘Personal Information.'”
The litigants pointed to Google’s plan to phase out third-party cookies, and noted Google doesn’t need cookies due to the ability of its X-Client-Data Header to uniquely identify people.
Whether the goal is to find a treatment for COVID-19 or another disease, scientists often have to conduct preliminary tests on animals to determine whether the drug is safe or effective in people. It’s not always a one-for-one comparison, but The New York Times reports there may be a new way around that step going forward: 3-D printing.
For example, Anthony Atala, the director of the Wake Forest Institute for Regenerative Medicine, and his team are using 3-D printers to create tiny replicas of human organs, including miniature lungs and colons, which are particularly affected by the coronavirus. They send them overnight for testing at a biosafety lab at George Mason University.
The idea predated the coronavirus — Atala said he never thought “we’d be considering this for a pandemic” — but it could come in handy and help expedite the experimental drug process, especially since Atala said his Winston-Salem, North Carolina-based lab can churn out thousands of printed organs per hour. “The 3-D models can circumvent animal testing and make the pathway stronger from the lab to the clinic,” said Akhilesh Gaharwar, who directs a lab in the biomedical engineering at Texas A&M University. Read more at The New York Times.Tim O’Donnell
Twitter contractors with high-level administrative access to accounts regularly abused their privileges to spy on celebrities including Beyoncé, including approximating their movements via internet protocol addresses, according to a report by Bloomberg.
Over 1,500 workers and contractors at Twitter who handle internal support requests and manage user accounts have high-level privileges that enable them to override user security settings and reset their accounts via Twitter’s backend, as well as view certain details of accounts like IP addresses, phone numbers, and email addresses.
[…]
Two of the former Twitter employees told Bloomberg that projects such as enhancing security of “the system that houses Twitter’s backup files or enhancing oversight of the system used to monitor contractor activity were, at times, shelved for engineering products designed to enhance revenue.” In the meantime, some of those with access (some of whom were contractors with Cognizant at up to six separate work sites) abused it to view details including IP addresses of users. Executives didn’t prioritize policing the internal support team, two of the former employees told Bloomberg, and at times Twitter security allegedly had trouble tracking misconduct due to sheer volume.
A system was in place to create access logs, but it could be fooled by simply creating bullshit support tickets that made the spying appear legitimate; two of the former employees told Bloomberg that from 2017 to 2018 members of the internal support team “made a kind of game out of” the workaround. The security risks inherent to granting access to so many people were reportedly brought up to the company’s board repeatedly from 2015-2019, but little changed.
This had consequences beyond the most recent hack. Last year, the Department of Justice announced charges against two former employees (a U.S. national and a Saudi citizen) that it accused of espionage on behalf of an individual close to Saudi Crown Prince Mohammed bin Salman. The DOJ alleged that the intent of the operation was to gain access to private information on political dissidents.
