Last month, Google issued a warning to Android app developers that they will no longer be able to access Android accessibility service functions in their apps, unless they can demonstrate that those functions are specifically used to help users with "disabilities." Since a lot of password managers use the Accessibility API, as well as poplar apps like Tasker automation and Greenify battery saver, there was a large amount of backlash from developers and users alike. According to SlashGear, Google is putting the Android accessibility crackdown on hold. From the report: Google has now sent another email that basically says "we'll think about it." It is evaluating "responsible and innovative use" of those services on a case to case basis. It is also requiring developers to explicitly inform users why they are asking for accessibility permissions rather than just informing them. This, of course, puts a heavier burden on Google, as it has to be more involved in the screening of apps rather than just rely on good ol' machine learning and automation. Developers and users probably won't mind, if it means still having access to those features that make Android a platform above all the rest.

An anonymous reader quotes a report from Ars Technica: To further increase its enterprise appeal, Chrome 63 -- which hit the browser's stable release channel yesterday -- includes a couple of new security enhancements aimed particularly at the corporate market. The first of these is site isolation, an even stricter version of the multiple process model that Chrome has used since its introduction. Chrome uses multiple processes for several security and stability reasons. On the stability front, the model means that even if a single tab crashes, other tabs (and the browser itself) are unaffected. On the security front, the use of multiple processes makes it much harder for malicious code from one site to steal secrets (such as passwords typed into forms) of another. [...]

Naturally, this greater use of multiple processes incurs a price; with this option enabled, Chrome's already high memory usage can go up by another 15 to 20 percent. As such, it's not enabled by default; instead, it's intended for use by enterprise users that are particularly concerned about organizational security. The other new capability is the ability for administrators to block extensions depending on the features those extensions need to use. For example, an admin can block any extension that tries to use file system access, that reads or writes the clipboard, or that accesses the webcam or microphone. Additionally, Google has started to deploy TLS 1.3, the latest version of Transport Layer Security, the protocol that enables secure communication between a browser and a Web server. In Chrome 63, this is only enabled between Chrome and Gmail; in 2018, it'll be turned on more widely.

schwit1 shares a Recode report: The story that appeared in Quartz this November seemed shocking enough on its own: Google had quietly tracked the location of its Android users, even those who had turned off such monitoring on their smartphones. But missing from the news site's report was another eyebrow-raising detail: Some of its evidence, while accurate, appears to have been furnished by one of Google's fiercest foes: Oracle. For the past year, the software and cloud computing giant has mounted a cloak-and-dagger, take-no-prisoners lobbying campaign against Google, perhaps hoping to cause the company intense political and financial pain at a time when the two tech giants are also warring in federal court over allegations of stolen computer code. Since 2010, Oracle has accused Google of copying Java and using key portions of it in the making of Android. Google, for its part, has fought those claims vigorously. More recently, though, their standoff has intensified. And as a sign of the worsening rift between them, this summer Oracle tried to sell reporters on a story about the privacy pitfalls of Android, two sources confirmed to Recode.

Amazon began accepting registration requests for .BOT domain name from the public this week as the e-commerce giant comes to realize the potential of the top level domain name it secured rights for two years ago. For now, Amazon is keeping the registration for .BOT domains limited. "Creators with published bots who use Amazon Lex, Microsoft Bot Framework and Dialogflow can validate a bot and register a .BOT domain name," the company said, noting that the limited registration phase would end on March 30, 2018. At the time of registration, Amazon requires users to sign into their Amazon account and validate their published bot.

WheezyJoe writes: Classic Shell is a free Windows application that for years has replaced Microsoft's Start Screen or Start Menu with a highly configurable, more familiar non-tile Start menu. Yesterday, the lead developer released what he said would be the last version of Classic Shell. Citing other interests and the frequency at which Microsoft releases updates to Windows 10, as well as lagging support for the Win32 programming model, the developer says that he won't work on the program anymore. The application's source code is available on SourceForge, so there is a chance others may come and fork the code to continue development. There are several alternatives available, some pay and some free (like Start10 and Start Is Back++), but Classic Shell has an exceptionally broad range of tweaks and customizability.

An anonymous reader writes: "On December 1st, 24 Pull Requests will be opening its virtual doors once again, asking you to give the gift of a pull request to an open source project in need," writes UK-based software developer Andrew Nesbitt -- noting that last year the site registered more than 16,000 pull requests. "And they're not all by programmers. Often the contribution with the most impact might be an improvement to technical documentation, some tests, or even better -- guidance for other contributors."

This year they're even touting "24 Pull Requests hack events," happening around the world from Lexington, Kentucky to Torino, Italy. (Last year 80 people showed up for an event in London.) "You don't have to hack alone this Christmas!" suggests the site, also inviting local communities and geek meetups (as well as open source-loving companies) to host their own events.
Contributing to open source projects can also beef up your CV (for when you're applying for your next job), the site points out, and "Even small contributions can be really valuable to a project."

"You've been benefiting from the use of open source projects all year. Now is the time to say thanks to the maintainers of those projects, and a little birdy tells me that they love receiving pull requests!"

An anonymous reader quotes Bleeping Computer: PHP got a whole lot more secure this week with the release of the 7.2 branch, a version that improves and modernizes the language's support for cryptography and password hashing algorithms.

Of all changes, the most significant is, by far, the support for Argon2, a password hashing algorithm developed in the early 2010s. Back in 2015, Argon2 beat 23 other algorithms to win the Password Hashing Competition, and is now in the midst of becoming a universally recognized Internet standard at the Internet Engineering Task Force (IETF), the reward for winning the contest. The algorithm is currently considered to be superior to Bcrypt, today's most widely used password hashing function, in terms of both security and cost-effectiveness, and is also slated to become a favorite among cryptocurrencies, as it can also handle proof-of-work operations.

The other major change in PHP 7.2 was the removal of the old Mcrypt cryptographic library from the PHP core and the addition of Libsodium, a more modern alternative.

Politico reports: Staffers for Senate Republicans' campaign arm seized information on more than 200,000 donors from the House GOP campaign committee over several months this year by breaking into its computer system, three sources with knowledge of the breach told Politico... Multiple NRSC staffers, who previously worked for the NRCC, used old database login information to gain access to House Republicans' donor lists this year. The donor list that was breached is among the NRCC's most valuable assets, containing not only basic contact information like email addresses and phone numbers but personal information that could be used to entice donors to fork over cash -- information on top issues and key states of interest to different people, the names of family members, and summaries of past donation history... Donor lists like these are of such value to party committees that they can use them as collateral to obtain loans worth millions of dollars when they need cash just before major elections...

"The individuals on these lists are guaranteed money," said a Republican fundraiser. "They will give. These are not your regular D.C. PAC list"... The list has helped the NRCC raise over $77 million this year to defend the House in 2018... Though the House and Senate campaign arms share the similar goal of electing Republican candidates and often coordinate strategy in certain states, they operate on distinct tracks and compete for money from small and large donors.
Long-time Slashdot reader SethJohnson says the data breach "is the result of poor deprovisioning policies within the House Republican Campaign Committee -- allowing staff logins to persist after a person has left the organization."

NRCC officials who learned of the breach "are really pissed," one source told the site.

An anonymous reader writes: Friday saw this year's first new posts on the Perl Advent Calendar, a geeky tradition first started back in 2000. It describes Santa including Unicode's "Father Christmas" emoji by enabling UTF-8 encoding and then using the appropriate hexadecimal code.

But in another corner of the North Pole, you can also unwrap the Perl 6 Advent Calendar, which this year celebrates the two-year anniversary of the official launch of Perl 6. Its first post follows a Grinch who used the but and does operators in Perl 6, while wrapping methods and subroutines to add extra sneaky features, "and even mutated the language itself to do our bidding."

Perl/Python guru Joel Berger has also started an advent calendar for the Mojolicious web application framework (written in Perl), and there's apparently also an advent calendar coming for the Perl Dancer web application framework.

Kieren McCarthy, writing for The Register: Network admins, code wranglers and other techies have hit an unusual problem this week: their test and development environments have vanished. Rather than connecting to private stuff on an internal .dev domain to pick up where they left off, a number of engineers and sysadmins are facing an error message in their web browser complaining it is "unable to provide a secure connection." How come? It's thanks to a recent commit to Chromium that has been included in the latest version of Google Chrome. As developers update their browsers, they may find themselves booted out their own systems. Under the commit, Chrome forces connections to all domains ending in .dev (as well as .foo) to use HTTPS via a HTTP Strict Transport Security (HSTS) header. This is part of Google's larger and welcome push for HTTPS to be used everywhere for greater security.

Amazon today announced that third-party developers will be able to make use of the Alexa assistant's voice recognition feature to personalize apps for its line of Echo speakers. The news builds on the company's announcement in October that Alexa can now identify individual users' voices to personalize responses. The Verge reports: Until today, that recognition feature only worked for Amazon-built services like shopping lists, flash briefing news updates, and Amazon Music, among other built-in skills. Starting some time in early 2018, however, developers will be able to tap into those voice-based profiles to make apps more personalized to various members of a household. This yet again puts Amazon ahead of rival Google in the smart home and digital assistant fields. In addition to announcing voice recognition for third-party apps, Amazon also revealed today at its re:Invent conference that it's bringing Alexa notifications on Echo speakers to a wider pool of developers starting today.

An anonymous reader quotes a report from Ars Technica: Destiny 2, like its predecessor, depends largely on an open-ended "end game" system. Once you beat the game's primary "quest" content, you can return to previously covered ground to find remixed and upgraded battles, meant to be played ad nauseam alone or with friends. To encourage such replay, Bungie dangles a carrot of XP gain, which works more slowly than during the campaign stages. Players are awarded a "bright engram" every time they "level up" past the level cap; the engrams are essentially loot boxes that contain a random assortment of cosmetics and weapon mods. Everything you do in the game, from killing a weak bad guy to completing a major raid-related milestone, is supposed to reward you a fixed XP amount. As series fans gear up for the game's first expansion, slated to launch December 5 on PC, PlayStation 4, and Xbox One, its eagle-eyed fans at r/DestinyTheGame began questioning whether those rewards were really as fixed as claimed. Some players began to suspect that they were actually getting less XP than advertised each time they repeated certain in-game missions and tasks, such as the game's "Public Events."

With stopwatch in hand, a user named EnergiserX tracked the modes he played, keeping an eye on any shifts in XP gain over time. He put enough data together to confirm those suspicions: the XP gained in certain modes would shrink with each repetition. Worse, the game gave no indication of these diminishing returns. The XP-gain numbers that popped up above the game's XP bar didn't reflect the game's hidden scaling system. Thus, there was no way for a player to accurately calculate how their XP gain had been affected or scaled without going through EnergiserX's exhaustive process. With findings in hand, the tester posted on Reddit with calls to the developers for a response, which the community received on Saturday. Bungie confirmed its use of an "XP scaler" and added that it was "not performing the way we'd like it to," which meant the developer would remove that XP-scaling system upon the game's next patch. However, Bungie didn't clarify how the developers actually would have liked for this XP-scaling system to work, nor what factored into it announcing any changes beyond the system simply being discovered. Bungie issued a patch on Sunday that removed the XP-scaling systems, but it introduced another unannounced change to the XP system. "Bungie decided to tune the speed of XP gain by doubling the required XP needed to 'level up,' from 80,000 points to 160,000," reports Ars Technica. "Patch notes didn't mention this change; Bungie, once again, had to be questioned by its fanbase before confirming the exact amount of this XP-related change."

The Google Pixel 2 and Pixel 2 XL both feature a custom Intel "Visual Core" co-processor, which is meant to improve speed and battery life when shooting photos with Google's HDR+ technology. The chip has been hanging out in the phone not really doing much of anything -- until now. TechCrunch reports of a new developer preview of Android 8.1 due out today that puts the chip to use. "The component is expected to further improve the handsets' cameras, which were already scoring good marks, production issues aside." From the report: According to the company, Pixel Visual Core has eight image processing unit (IPU) cores and 512 arithmetic logic units. Using machine learning, the company says it's able to speed things up by 5x, with one tenth of the energy. Access to the chip, combined with the Android Camera API means third-party photo apps will be able to take advantage of the system's speedy HDR+. Sounds swell, right? Of course, this is still just an early preview, only available to people who sign up for Google's Beta program. That means, among other things, dealing with potential bugs of an early build. Google wouldn't give us any more specific information with regards to when the feature will be unlocked for the public, but it's expected to arrive along with the 8.1 public beta in December.

Open source guru Eric S. Raymond followed up his post on alternatives to C by explaining why he won't touch C++ any more, calling the story "a launch point for a disquisition on the economics of computer-language design, why some truly unfortunate choices got made and baked into our infrastructure, and how we're probably going to fix them." My problem with [C++] is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It's all very well to say "well, don't do that" about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced. Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with)... C is flawed, but it does have one immensely valuable property that C++ didn't keep -- if you can mentally model the hardware it's running on, you can easily see all the way down. If C++ had actually eliminated C's flaws (that is, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).

The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.

Vox reports on Amazon's recent push for "corporate sustainability": It plans to have 15 rooftop solar systems, with a total capacity of around 41 MW, deployed atop fulfillment centers by the end of this year, with plans to have 50 such systems installed by 2020. Amazon was the lead corporate purchaser of green energy in 2016. That year, it also announced its largest wind energy project to date, the 253 MW Amazon Wind Farm Texas. Overall, the company says, it has "announced or commenced construction on wind and solar projects that will generate a total of 3.6 million megawatt hours (MWh) of renewable energy annually."
But here's the most interesting part. GeekWire reports: Amazon is moving ahead with a unique plan to use heat generated from data centers in the nearby Westin Building to warm some of its new buildings downtown. The system transfers the heat from the data centers via water piped underground to the Amazon buildings. The water is then returned to the Westin Building once it's cooled down to help cool the data centers. The setup will be unusual. "Certainly there are other people using waste heat from server farms but you don't hear a lot about tying it in with buildings across the street from each other," said Seattle City Councilmember Mike O'Brien.

dryriver writes: A number of pay-to-win microtransaction FPS games, including Dirty Bomb and the $60 Star Wars Battlefront II, have drawn the ire of legislators in countries like Belgium and the United States. Not only are advanced characters like Luke Skywalker and Darth Vader and various weapons and abilities in these games "locked" -- you pay for them in hard cash, or play for them for dozens and dozens of tedious hours -- the games also feature so called "Loot Boxes," which are boxes that contain a random item, weapon, character or ability. So like playing slot machines in Vegas, each time you can get something good, something mediocre or something totally crap. You cannot determine with any certainty what you will get for your real-world dollars or in-game achievements. Angry Reddit users recently downvoted a blundering statement by EA on the topic with a whopping 249,000 downvotes -- an all time downvote record on Reddit, shocking EA into retreating from its pay-to-win model and announcing unspecified "changes" now being made to Star Wars Battlefront II. Legislators in a number of countries have also sharply criticized "Loot Boxes" and "microtransactions" in games, with one legislator in Belgium vowing to have the sale of such games banned completely in the EU, because children are essentially being forced to "gamble with real money" in these games. Forbes has written a great piece about how EA is now essentially stuck with a $60 Star Wars game that cost a lot to make but probably cannot be monetized any further, because there is considerable risk of all games with loot boxes, microtransactions and "pay to win" monetization models being completely banned from sale in a number of different countries now. The morale of the story? Maybe people should not pay a game developer any more than the $40-60 they paid when they thought they "bought" the game in the first place.

Richard Chirgwin, writing for The Register: Given that code sharing is a big part of the GitHub mission, it should come at no surprise that the platform stores a lot of duplicated code: 70 per cent, a study has found. An international team of eight researchers didn't set out to measure GitHub duplication. Their original aim was to try and define the "granularity" of copying -- that is, how much files changed between different clones -- but along the way, they turned up a "staggering rate of file-level duplication" that made them change direction. Presented at this year's OOPSLA (part of the late-October Association of Computing Machinery) SPLASH conference in Vancouver, the University of California at Irvine-led research found that out of 428 million files on GitHub, only 85 million are unique. Before readers say "so what?", the reason for this study was to improve other researchers' work. Anybody studying software using GitHub probably seeks random samples, and the authors of this study argued duplication needs to be taken into account.

An anonymous reader shares a report from Business Insider: The FCC is planning to kill net neutrality -- and some tech companies are starting to speak out. Pro-net neutrality activists, who argue the principle creates a level playing-field online, are up in arms about the plan. And some tech companies are now speaking out in support of net neutrality as well, from Facebook to Netflix. Business Insider reached out to some of the biggest tech firms in America today to ask for their reaction to the FCC's plan. Their initial responses are below, and we will continue to update this post as more come in.

In a blog post, Google's Product Manager, Chris Kleban, announced that the company is cutting the price of using Nvidia's Tesla GPUs through its Compute Engine by up to 36 percent. The older K80 GPUs will now cost $0.45 per hour while the more powerful P100 machines will cost $1.46 per minute (all with per-second billing). TechCrunch reports: The company is also dropping the prices for preemptible local SSDs by almost 40 percent. "Preemptible local SSDs" refers to local SSDs attached to Google's preemptible VMs. You can't attach GPUs to preemptible instances, though, so this is a nice little bonus announcement -- but it isn't going to directly benefit GPU users. As for the new GPU pricing, it's clear that Google is aiming this feature at developers who want to run their own machine learning workloads on its cloud, though there also are a number of other applications -- including physical simulations and molecular modeling -- that greatly benefit from the hundreds of cores that are now available on these GPUs. The P100, which is officially still in beta on the Google Cloud Platform, features 3594 cores, for example. Developers can attach up to four P100 and eight K80 dies to each instance. Like regular VMs, GPU users will also receive sustained-use discounts, though most users probably don't keep their GPUs running for a full month.

An anonymous reader shares a report from Android Police: Google's in-development operating system, named "Fuchsia," first appeared over a year ago. It's quite different from Android and Chrome OS, as it runs on top of the real-time "Magenta" kernel instead of Linux. According to recent code commits, Google is working on Fuchsia OS support for the Swift programming language. If you're not familiar with it, Swift is a programming language developed by Apple, which can be used to create iOS/macOS/tvOS/watchOS applications (it can also compile to Linux). Apple calls it "Objective-C without the C," and on the company's own platforms, it can be mixed with existing C/Objective-C/C++ code (similar to how apps on Android can use both Kotlin and Java in the same codebase). We already know that Fuchsia will support apps written in Dart, a C-like language developed by Google, but it looks like Swift could also be supported. On Swift's GitHub repository, a pull request was created by a Google employee that adds Fuchsia OS support to the compiler. At the time of writing, there are discussions about splitting it into several smaller pull requests to make reviewing the code changes easier.