- wlug - list.wlug.org.nz

Half of the Websites Using WebAssembly Use it for Malicious Purposes
by Peter Reutemann 09 Jan '20

09 Jan '20

'Around half of the websites that use WebAssembly, a new web technology, use it for malicious purposes, according to academic research published last year. From a report: WebAssembly is a low-level bytecode language that was created after a joint collaboration between all major browser vendors. It introduces a new binary file format for transmitting code from a web server to a browser. Once it reaches the browser, WebAssembly code (Wasm) executes with near-native speed, similar to compiled C, C++, or Rust code. WebAssembly was created for both speed and performance. Due to its binary machine-friendly format, Wasm code is smaller than its equivalent JavaScript form, but also many times faster when executing. This has made WebAssembly the next incarnation of Adobe Flash, allowing websites to run complex CPU-intensive code without freezing a browser, a task for which JavaScript was never designed or optimized for.' -- source: https://it.slashdot.org/story/20/01/08/1421216 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Coming Soon: The Web “Thin Client”
by Lawrence D'Oliveiro 08 Jan '20

08 Jan '20

Here’s a new trend to watch out for: it’s being called “browser isolation” <https://www.theregister.co.uk/2020/01/07/cloudflare_buys_s2/>: S2 developed a ... headless version of Chromium – the open-source foundation of Chrome and about two dozen other browsers – that runs in the cloud and intercepts calls to the browser's Skia graphics layer. "Before it actually draws anything virtual, we intercept those Skia calls, we tokenize them, we compress them, we send them through to any HTML5 browser, where we redraw them locally, right on the machine," Remington explained. "We use WebAssembly. We push a little Skia library that runs local in your browser, any browser. ... Turns out, it's very secure, because that is not an attack vector. It's only draw commands." ... According to Harnett, S2's scheme results in a 60 per cent bandwidth savings. "People are surprised when we say that in many cases, it's faster than local" ...

1 0

PGP keys, software security, and much more threatened by new SHA1 exploit
by Peter Reutemann 08 Jan '20

08 Jan '20

'Three years ago, Ars declared the SHA1 cryptographic hash algorithm officially dead after researchers performed the world’s first known instance of a fatal exploit known as a "collision" on it. On Tuesday, the dead SHA1 horse got clobbered again as a different team of researchers unveiled a new attack that’s significantly more powerful. The new collision gives attackers more options and flexibility than were available with the previous technique. It makes it practical to create PGP encryption keys that, when digitally signed using SHA1 algorithm, impersonate a chosen target. More generally, it produces the same hash for two or more attacker-chosen inputs by appending data to each of them. The attack unveiled on Tuesday also costs as little as $45,000 to carry out. The attack disclosed in 2017, by contrast, didn’t allow forgeries on specific predetermined document prefixes and was evaluated to cost from $110,000 to $560,000 on Amazon’s Web Services platform, depending on how quickly adversaries wanted to carry it out. The new attack is significant. While SHA1 has been slowly phased out over the past five years, it remains far from being fully deprecated. It’s still the default hash function for certifying PGP keys in the legacy 1.4 version branch of GnuPG, the open-source successor to PGP application for encrypting email and files. Those SHA1-generated signatures were accepted by the modern GnuPG branch until recently, and were only rejected after the researchers behind the new collision privately reported their results. Git, the world's most widely used system for managing software development among multiple people, still relies on SHA1 to ensure data integrity. And many non-Web applications that rely on HTTPS encryption still accept SHA1 certificates. SHA1 is also still allowed for in-protocol signatures in the Transport Layer Security and Secure Shell protocols.' -- source: https://arstechnica.com/information-technology/2020/01/pgp-keys-software-se… Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Firefox 72 Arrives With Fingerprinting Blocked By Default, Picture-in-Picture on macOS and Linux
by Peter Reutemann 08 Jan '20

08 Jan '20

'Mozilla today launched Firefox 72 for Windows, Mac, Linux, and Android. Firefox 72 includes fingerprinting scripts blocked by default, less annoying notifications, and Picture-in-Picture video on macOS and Linux. There isn't too much else here, as Mozilla has now transitioned Firefox releases to a four-week cadence (from six to eight weeks).' -- source: https://news.slashdot.org/story/20/01/07/143225 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Chrome OS Has Stalled Out
by Peter Reutemann 07 Jan '20

07 Jan '20

'Speaking of Chromebooks, David Ruddock, opines at AndroidPolice: Chrome OS' problems really became apparent to me when Android app compatibility was introduced, around five years ago. Getting Android apps to run on Chrome OS was simultaneously one of the Chrome team's greatest achievements and one of its worst mistakes. In 2019, two things are more obvious than ever about the Android app situation on Chrome. The first is that the "build it and they will come" mantra never panned out. Developers never created an appreciable number of Android app experiences designed for Chrome (just as they never did for Android tablets). The second is that, quite frankly, Android apps are very bad on Chrome OS. Performance is highly variable, and interface bugs are basically unending because most of those apps were never designed for a point-and-click operating system. Sure, they crash less often than they did in the early days, but anyone saying that Android apps on Chrome OS are a good experience is delusional. Those apps are also a crutch that Chrome leans on to this day. Chrome OS doesn't have a robust photo editor? Don't worry, you can download an app! Chrome doesn't have native integration with cloud file services like Box, Dropbox, or OneDrive? Just download the app! Chrome doesn't have Microsoft Office? App! But this "solution" has basically become an insult to Chrome's users, forcing them to live inside a half-baked Android environment using apps that were almost exclusively designed for 6" touchscreens, and which exist in a containerized state that effectively firewalls them from much of the Chrome operating system. As a result, file handling is a nightmare, with only a very limited number of folders accessible to those applications, and the task of finding them from inside those apps a labyrinthine exercise no one should have to endure in 2019. This isn't a tenable state of affairs -- it's computing barbarism as far as I'm concerned. And yet, I've seen zero evidence that the Chrome team intends to fix it. It's just how it is. But Android apps, so far as I can tell, are basically the plan for Chrome. Certainly, Linux environment support is great for enthusiasts and developers, but there are very few commonly-used commercial applications available on Linux, with no sign that will change in the near future. It's another dead end. And if you want an even more depressing picture of Chrome's content ecosystem, just look at the pitiable situation with web apps.' -- source: https://developers.slashdot.org/story/20/01/06/1626227 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

“Open Source” Journalism
by Lawrence D'Oliveiro 06 Jan '20

06 Jan '20

This week’s “Listening Post” on Al Jazeera (viewable here <https://www.aljazeera.com/programmes/listeningpost/2019/09/xinjiang-story-c…>) talks, in the latter part, about this new phenomenon of “open source” journalism. My understanding is, the meaning of “source” here is not that of “source code” familiar to software developers, but “source of information” as understood by journalists. That means getting information from public sources available to all. Even a tightly-controlled society like China makes a surprising amount of information freely available online--more than it really wants to make available, sometimes. And this information can be pieced together like a puzzle by perceptive investigators, to point to conclusions which can be directly at odds with public pronouncements from Government officials.

1 1

Linus Torvalds Calls Blogger's Linux Scheduler Tests 'Pure Garbage'
by Peter Reutemann 06 Jan '20

06 Jan '20

'On Wednesday Phoronix cited a blog post by C++ game developer Malte Skarupke claiming his spinlocks experiments had discovered the Linux kernel had a scheduler issue affecting developers bringing games to Linux for Google Stadia. Linus Torvalds has now responded: The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring. First off, spinlocks can only be used if you actually know you're not being scheduled while using them. But the blog post author seems to be implementing his own spinlocks in user space with no regard for whether the lock user might be scheduled or not. And the code used for the claimed "lock not held" timing is complete garbage. It basically reads the time before releasing the lock, and then it reads it after acquiring the lock again, and claims that the time difference is the time when no lock was held. Which is just inane and pointless and completely wrong... [T]he code in question is pure garbage. You can't do spinlocks like that. Or rather, you very much can do them like that, and when you do that you are measuring random latencies and getting nonsensical values, because what you are measuring is "I have a lot of busywork, where all the processes are CPU-bound, and I'm measuring random points of how long the scheduler kept the process in place". And then you write a blog-post blamings others, not understanding that it's your incorrect code that is garbage, and is giving random garbage values... You might even see issues like "when I run this as a foreground UI process, I get different numbers than when I run it in the background as a batch process". Cool interesting numbers, aren't they? No, they aren't cool and interesting at all, you've just created a particularly bad random number generator... [Y]ou should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself -- we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times). There's a reason why you can find decades of academic papers on locking. Really. It's hard. "It really means a lot to me that Linus responded," the blogger wrote later, "even if the response is negative." They replied to Torvalds' 1,500-word post on the same mailing list -- and this time received a 1900-word response arguing "you did locking fundamentally wrong..." The fact is, doing your own locking is hard. You need to really understand the issues, and you need to not over-simplify your model of the world to the point where it isn't actually describing reality any more... Dealing with reality is hard. It sometimes means that you need to make your mental model for how locking needs to work a lot more complicated...' -- source: https://linux.slashdot.org/story/20/01/06/012251 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Open Source Initiative Co-Founder Bruce Perens Resigns, Citing Move Toward License 'That Isn't Freedom Respecting'
by Peter Reutemann 06 Jan '20

06 Jan '20

'Bruce Perens (Slashdot reader #3872) co-founded the Open Source Initiative with Eric Raymond in 1998. But on Thursday Perens posted "it seems to me that the organization is rather enthusiastically headed toward accepting a license that isn't freedom respecting. Fine, do it without me, please. "I asked Patrick to cancel my membership, and I would have unsubscribed from OSI lists, including this one, if your server was working..." The issue is a new software license drafted by lawyer Van Lindberg called the Cryptographic Autonomy License (or CAL). Another open-source-community leader familiar with the debate -- who spoke with The Register on condition of anonymity -- claimed Lindberg lobbied OSI directors privately to green-light the license, contrary to an approval process that's supposed to be carried out in public. "I don't think that's an appropriate characterization," said Lindberg, of law firm Dykema, in a phone interview with The Register. "I think there are number of people who from the beginning made up their minds about the Cryptographic Autonomy License. You'll see a lot of people jumping onto any pretext they can find in order to oppose it. With regard to this idea of lobbying, there have been procedural-type communications that I think are entirely reasonable," he added. "But all the substantive debate has been on the license review and license discussion forums...." Perens said he resigned because the OSI appears to have already decided to accept the license. He said he's headed in a different direction, which he called "coherent open source." "We've gone the wrong way with licensing," he said, citing the proliferation of software licenses. He believes just three are necessary, AGPLv3, the LGPLv3, and Apache v2. Meanwhile, the Cryptographic Autonomy License is envisioned for use with the distributed development platform Holo, notes the Register: According to Holo co-founder Arthur Brock, distributed peer-to-peer software needs a license that addresses cryptographic key rights, which is why the Cryptographic Autonomy License has been proposed. "We are trying to say: the only valid way to use our code is if that developer's end-users are the sole authors and controllers of their own private crypto keys," he wrote in a post last year. Lindberg said the Cryptographic Autonomy License is applicable to current web applications but it more meaningful in the context of distributed workloads and distributed computation, which he contends will become more important as people seek alternatives to the centralization of today's cloud-based systems. "A lot of people are very concerned about this concept of owning your data, owning your computer, having the ability to really control your computing experience and have it not be controlled by your cloud provider," said Lindberg. Perens said, "It's a good goal but it means you now need to have a lawyer to understand the license and to respond to your users." Slashdot asked Bruce Perens for details on "Coherent Open Source." Here's what he wrote back...' -- source: https://news.slashdot.org/story/20/01/05/208249 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Dell's Upcoming XPS 13 Linux Laptop Includes a Fingerprint Reader
by Peter Reutemann 06 Jan '20

06 Jan '20

'If you've been following the steady march of progress from Dell's Linux-first Project Sputnik team, you're no doubt aware that the "Developer Edition" variant of the XPS 13 is one of the finest Linux-ready ultrabooks you can buy. Just ahead of CES 2020, Dell is pushing out a few more improvements including a feature that's been hotly requested: fingerprint-reader support. It's one of several enhancements Dell is promising to Linux users for its 10th-generation XPS 13, including a new maximum of 32GB RAM and a redesigned "InfinityEdge" display that adds even more screen real estate, resulting in an adjusted 16:10 aspect ratio to match... Details on fingerprint-reader support are still a bit vague, but Dell says it will be released shortly after the system's February 2020 launch as an OTA (over-the-air) update, and then as part of the preloaded Ubuntu Developer Edition image it ships with the system. Dell's lead on Project Sputnik developer systems, Barton George, also blogged about Dell's new 86-inch 4K interactive touch monitor, as well as their upcoming Latitude 9510 notebook and 2-in-1 laptops, promising "a new ultra-premium class of products" offering 5G mobile broadband capabilities, AI-based productivity capabilities, and 30-plus hours of battery life. The blog post ends by noting that "While project Sputnik is the most visible Linux-based offerings from Dell, it is only a small fraction of the over 150 systems that make up Dell's Linux portfolio."' -- source: https://linux.slashdot.org/story/20/01/05/0137242 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

2 1

Linux Kernel Developers and Commits Dropped in 2019
by Peter Reutemann 06 Jan '20

06 Jan '20

'Phoronix reports that on New Year's Day, the Linux kernel's Git source tree showed 27,852,148 lines of code, divided among 66,492 files (including docs, Kconfig files, user-space utilities in-tree, etc). Over its lifetime there's been 887,925 commits, and around 21,074 different authors: During 2019, the Linux kernel saw 74,754 commits, which is actually the lowest point since 2013. The 74k commits is compares to 80k commits seen in both 2017 and 2018, 77k commits in 2016, and 75k commits in both 2014 and 2015. Besides the commit count being lower, the author count for the year is also lower. 2019 saw around 4,189 different authors to the Linux kernel, which is lower than the 4,362 in 2018 and 4,402 in 2017. While the commit count is lower for the year, on a line count it's about average with 3,386,347 lines of new code added and 1,696,620 lines removed... Intel and Red Hat have remained the top companies contributing to the upstream Linux kernel.' -- source: https://linux.slashdot.org/story/20/01/04/2335200 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0