Previous Page
PCLinuxOS Magazine
Article List
Next Page

Short Topix: Dropbox Reinstates Support For ZFS, XFS, Btrfs, eCryptFS

by Paul Arnote (parnote)

Google Effort To Prevent Chrome Incognito Mode Detection Flops

On July 18, 2019, Google announced in a blog post that it was closing a loophole that allowed sites to know if a user was connecting to a site using "incognito" mode on Google Chrome. Some sites would not allow users to connect to their sites using incognito mode. Granted, some users used incognito mode, where browsing history and cookies are not saved, to circumvent article limits and paywalls. In 2017, The Boston Globe started blocking users of incognito mode from accessing its content. The New York Times, the Los Angeles Times, the Dallas Morning News and others have also employed the method that prevents users of incognito mode from accessing the content on their sites.

The "method" is detecting if Chrome's FileSystem API is disabled or not. In incognito mode, the FileSystem API is disabled, resulting in the return of an error code whenever trying to write cookies or browsing history to the user's device. Google stated in its blog entry that this particular method would be eliminated with the release of Google Chrome 76 on July 30.

And close it they did. However, sites blocking incognito users have resorted to other methods to block the use of incognito mode. It seems the "fix" has opened up two more ways to detect if a user is using incognito mode, according to the BleepingComputer website. The fix opened up the FileSystem API in both regular and incognito mode, with the incognito mode using a memory-based transient file system that is cleared at the end of the session.

In the first method, if the user is using incognito mode, a memory quota of a maximum of 120 MB is reserved, according to Vikas Mishra on his blog. If the space for FileSystem API is 120 MB or less, the user is using incognito mode. The non-incognito mode uses 10 percent (or 2GiB maximum) of available disk space. Websites can query their quota without any special permissions. Armed with this information, Mishra executed a quick and easy script that showed if a user was using incognito mode or not.

The second method was discovered by researcher Jesse Li, and uses access timings. In normal browsing mode, it takes about 2281 ms to write data to the disk based file system. If a user is using incognito mode, it takes an average of 792 ms to write data to the memory based file system. In other words, data is written three to four times faster to the memory based file system, used when the user is using incognito mode, as in regular browsing mode when data is written to the disk based file system.

Fortunately, Google has stated in their blog (first link), "any approach based on private browsing detection undermines the principles of Incognito Mode. We remain open to exploring solutions that are consistent with user trust and private browsing principles."

Users can only hope that Google is serious about preserving user privacy in incognito mode. We at least hope they are more serious about this than preserving their "do no evil" credo, which has gone by the wayside a long time ago.

End Of Floppy Disk In Linux?

On July 18, Linus Torvalds marked the floppy drive "orphaned." This means that there are no developers able or willing to maintain the code in the Linux kernel. Able is probably more like it. When was the last time you saw a computer with a floppy drive, outside of a museum, or at the bottom of a miscellaneous junk pile of computer parts? I don't think floppy drive controllers are even available on today's motherboards.

Orphaned modules will probably get deprecated and removed eventually if no one else comes forward to continue maintaining and developing it. Here's Torvalds entire statement posted on GitHub:

This also marks the floppy driver as orphaned - it turns out that Jiri no longer has working hardware.

Actual working physical floppy hardware is getting hard to find, and while Willy was able to test this, I think the driver can be considered pretty much dead from an actual hardware standpoint. The hardware that is still sold seems to be mainly USB-based, which doesn't use this legacy driver at all.

The old floppy disk controller is still emulated in various VM environments, so the driver isn't going away, but let's see if anybody is interested to step up to maintain it.

The lack of hardware also likely means that the ioctl range verification fixes are probably mostly relevant to anybody using floppies in a virtual environment. Which is probably also going away in favor of USB storage emulation, but who knows.

Will Decon reviewed the patches but I'm not rebasing them just for that, so I'll add a

    Reviewed-by: Will Deacon

here instead.

* floppy:
MAINTAINERS: mark floppy.c orphaned
  floppy: fix out-of-bounds read in copy_buffer
  floppy: fix invalid pointer dereference in drive_name
  floppy: fix out-of-bounds read in next_valid_format
  floppy: fix div-by-zero in setup_format_params

Most of us probably haven't seen, much less used, a floppy drive in at least 15 years. Actually ... I did ... once ... about 10 years ago (I have a USB 3.5 inch floppy drive, still in working order, but I'd have to do some serious searching to find where I stashed it). With floppy drives having been supplanted by larger and more efficient USB thumb drives, it was only a matter of time before the death bell tolled for floppy drives.

The floppy drive, however, will always be with us in spirit. The floppy drive gave its life so we may forever have the universal icon for "Save."

Dropbox Reinstates Support For ZFS, XFS, Btrfs, eCryptFS

Last November, Dropbox dropped support for any Linux file systems that weren't ext4. At the time, Dropbox announced "a supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync." But, the odd thing is that most of the file systems they "disallowed" actually do support extended attributes. That includes ext2, ext3, Btrfs, XFS, JFS, and others. Then, and even now, it sounded like a lazy programmer or lazy team lead didn't want to have to mess with supporting any file systems other than ext4.

In the backlash that ensued, Maestral was born. It's an open source Dropbox replacement on Linux and Mac systems that supports all file systems with extended attributes that Dropbox stopped supporting. It is a PyQt5 program that matches the Dropbox client's most commonly used capabilities, allows running from either the command line or a GUI, and comes in at a much lighter weight than the native Dropbox client.

Maestral wasn't the only solution born out of the sudden loss of support. Another project by a user named "dark" sprouted up on GitHub that fixed the file system detection in the Dropbox Linux client, restoring the ability to sync files with the Dropbox server while using "unsupported" Linux file systems. Other solutions were for users of "unsupported" file systems to run their own private version of NextCloud or ownCloud.

Fortunately, and probably quite a bit too late for many Dropbox users who have moved on, Dropbox has reversed course. Included in the changelog files for Dropbox 77.3.127 beta is that Dropbox has added back in support for ZFS and XFS on 64-bit systems, and Btrfs and eCryptFS.

Although the company that runs Dropbox probably won't miss many of the Linux refugees since last November financially, the move to remove support for popular file systems was a bit of a black eye in the public relations sense.

Knoppix 8.6 Abandons systemd

If you want to start a fiery debate among Linux users, just bring up one word: systemd. A handful of Linux distros have eschewed systemd, including our PCLinuxOS. Knoppix, with its 8.6 release, joins an exceptionally short list -- only two Linux distros -- to have adopted, and then abandoned, systemd, according to a TechRepublic article. The other one is Void Linux.

Hated by many, many Linux administrators and users, Linus Poettering's creation to replace the init system used by Linux is most likely here to stay for the vast majority of Linux users. The problems with systemd are vast and worrisome. First, it replaces human-readable log files with binary log files that can only be read with an appropriate software-based reader. Second, systemd has been besieged with "feature creep." Instead of doing one thing really well (as most *nix programs do), systemd has dipped its toe into just about every part of the Linux operating system. It's no longer just an init system. It tries to control every aspect of a user's computer and userspace. Third, and most likely because of systemd's overreach, it has been besieged with security vulnerabilities, with the latest (that I'm aware of) coming in January, 2019.

Here is what Knoppix creator Klaus Knopper had to say regarding the abandonment of systemd (translation via Google Translate, from the German Linux Magazine):

The startup script knoppix-autoconfig, which detects the hardware and controls the parallel startup of important system components, remains the backbone of Knoppix 'boot system.

The still controversial startup system Systemd, which has been a scandal for some vulnerabilities just recently, has been deinstalled since Knockix 8.5 (and) is finally uninstalled. I bypass hard dependencies on the boat system with my own packages.

To still get a systemd-like session management and thus retain the ability to shut down and restart the system as a normal user, I run the session manager "elogind" instead. This bypasses Systemd's interference with many system components and reduces the complexity of the overall system. If you want to start your own services at startup, you do not need to create any systemd units, but simply enter them in the text file >>/etc/rc.local<< which contains explanatory examples.

Knoppix is based on Debian, and had been using systemd since 2014. Work started on systemd in 2010, with Red Hat adopting it in 2011. Since then, it has grown like an unwanted zit on prom night.

Just in case there was any doubt, I am not a fan of systemd. Had it remained just a replacement for the Linux init system, I might be able to see some value. But it then proceeded to consume Linux like nothing ever has. It goes against the tradition of *nix programs: do one thing, and do it well. I dislike systemd almost as much as I dislike the egotis... (well, let's try to keep it moderately cordial here) Linus Poettering. It was Poettering, after all, who also brought us PulseAudio hell.

Any reasonable person should be asking about now: is this just the start of a mass exodus from systemd? Linux users everywhere can only hope so.

The Hackers Get Hacked

In what many may term either karma or the ultimate payback, Russia's security agency, the Federal Security Service (FSB), was hacked, according to a Business Insider article. The result was, according to BBC Russia (in Russian), possibly "the largest data leak in the history of the work of Russian special services on the Internet."

The robber barons, going by the name 0v1ru$, made off with over 7.5 TERABYTES of data from Sitek, a major information technology contractor of the FSB. They also left a "calling card" of a Yoba Face, a meme that trolls those who have been hacked. For reference, a terabyte of data holds 200,000 five minute songs, or 500 hours of movies. The data stolen merely uncovered projects with goals that were already known or suspected.

The smaller 0v1ru$ group turned the pilfered data over to the more well known hacking group Digital Revolution. The latter has targeted the FSB in the past. In turn, Digital Revolution passed notable (and unedited and unaltered) information to media outlets, and posted on Twitter about their discoveries. According to BBC Russia, none of the stolen data contained Russian government secrets.

As you might expect, the FSB has not commented on the embarrassing matter.

Previous Page              Top              Next Page