Hacking & Security
A co-leader on Google's product security team has waved a piece of red meat in front of already frothing privacy advocates by deleting part of a blog post saying he wished the Allo messenger app the company announced Wednesday would provide end-to-end encryption by default.
To critics, the deletion by Thai Duong amounted to tacit admission that his employer was willfully choosing to leave messages sent by the vast number of Allo users open to government surveillance. The critics have argued that because end-to-end encryption will be turned off by default and turned on only in an incognito mode, most users will never avail themselves of the protection.
In a blog post published shortly after Wednesday's announcement, Duong said the move would benefit people who want their messages to be processed by an artificial intelligence agent that would offer auto-replies based on the content of the messages. A built-in digital assistant, for instance, might automatically suggest nearby restaurants or available movies when parties are making plans, but only if the encryption feature is turned off. Then Duong went on to say something that he later deleted from the post:
We're excited to announce the launch of the new Safe Browsing API version 4. Version 4 replaces the existing Safe Browsing API version 3. With the launch of v4, we’re now starting the deprecation process for v2-3: please transition off of these older Safe Browsing protocol versions as soon as possible and onto protocol version 4.
Safe Browsing protects well over two billion internet-connected devices from threats like malware and phishing, and has done so for over a decade. We launched v1 of the Safe Browsing API in 2007 to give developers a simple mechanism to access Google’s lists of suspected unsafe sites.
The web has evolved since then and users are now increasingly using the web from their mobile devices. These devices have constraints less common to traditional desktop computing environments: mobile devices have very limited power and network bandwidth, and often poor quality of service. Additionally, cellular data costs our users money, so we have a responsibility to use it judiciously.
With protocol version 4, we’ve optimized for this new environment with a clear focus on maximizing protection per bit, which benefits all Safe Browsing users, mobile and desktop alike. Version 4 clients can now define constraints such as geographic location, platform type, and data caps to use bandwidth and device resources as efficiently as possible. This allows us to function well within the much stricter mobile constraints without sacrificing protection.
We’ve been using the new protocol since December via the Safe Browsing client on Android, which is part of Google Play Services. The first app to use the client is Chrome, starting with version 46: we’re already protecting hundreds of millions of Android Chrome users by default.
We’ve Done Most Of The Work For You Already
A single device should only have a single, up-to-date instance of Safe Browsing data, so we’re taking care of that for all Android developers. Please don’t implement your own Version 4 client on Android: we’re working on making a simple, device-local API available to prevent any resource waste on device. We’ll announce the availability of this new device-local API as soon as possible; in the meantime, there’s no need to develop a Version 4 client on your own. For those who operate in less resource-constrained environments, using the Safe Browsing Version 4 API directly allows you to:
- Check pages against the Safe Browsing lists based on platform and threat types.
- Warn users before they click links that may lead to infected pages.
- Prevent users from posting links to known infected pages
To make Safe Browsing integration as simple as possible, we’re also releasing a reference client implementation of the new API today, written in Go. It also provides a Safe Browsing HTTP proxy server, which supports JSON.
It’s easy to start protecting users with the new Version 4 of the Safe Browsing API. Sign up for a key and let us know what you think!
This is the last part of our Test Lab solutions in this article we are going to find two tokens from Recon and Dev-test system. Recon is not any system in the network we will find this token from DNS reconnaissance. Attacking the Recon: So we started with the zone transfer on both gateway IPs: […]
FBI využívá ke sledování díru, která je zřejmě i ve Firefoxu. Mozilla chce chybu znát, ale neuspěla ani u soudu
ISPs around the world are being attacked by self-replicating malware that can take complete control of widely used wireless networking equipment, according to reports from customers and a security researcher who is following the ongoing campaign.
San Jose, California-based Ubiquiti Networks confirmed on Friday that attackers are actively targeting a flaw in AirOS, the Linux-based firmware that runs the wireless routers, access points, and other gear sold by the company. The vulnerability, which allows attackers to gain access to the devices over HTTP and HTTPS connections without authenticating themselves, was patched last July, but the fix wasn't widely installed. Many customers claimed they never received notification of the threat.
Nico Waisman, a researcher at security firm Immunity, said he knows of two Argentina-based ISPs that went dark for two days after being hit by the worm. He said he's seen credible reports of ISPs in Spain and Brazil being infected by the same malware and that it's likely that ISPs in the US and elsewhere were also hit, since the exploit has no geographic restrictions. Once successful, the exploit he examined replaces the password files of an infected device and then scans the network it's on for other vulnerable gear. After a certain amount of time, the worm resets infected devices to their factory default configurations, with the exception of leaving behind a backdoor account, and then disappears. Ubiquiti officials have said there are at least two variations, so it's possible that other strains behave differently.