DropBox drops Linux support for all but ...

[TWPonKubuntu]

Practically speaking, what are people doing? Is there a work around? Or do I need to migrate everything to google drive now.

IMO, Google(r) is part of the problem, not part of the solution. We, the products, are still treated just as poorly as Dropbox has treated their "users".

Online storage/cloud, whatever is the buzzword of the day, are still insecure, mostly by design.

Even if a company has honorable intentions with respect to its customers, they remain a target for hacking because of the value of the data itself. Those hackers, whether private criminals or government sponsored, still want to harvest your data. Some of that "harvest" is used (sold) for marketing, but other uses include tracking opponents, both the political and philosophical types of opponents.

Hi there Three Letter Agency! Just having a friendly discussion here, purely philosophical in nature.

I wish I could recommend a safe online storage option, but honestly, I don't think it exists.

[GreyGeek]

Here's a BTRFS user trying to do something about it: https://askubuntu.com/questions/1066...ext4-isnt-ext4

I saw that 22 minutes after it was posted.

As he set it up using a fstab entry it will result in a /home/hisname/Dropbox subdirectory which is an EXT4 file, contrary to what a dissenter posted, because ${HOME} is defined in the environmental variables as /home/accountname. Open a Konsole and issue
:~$ env | grep HOME
PROFILEHOME=
HOME=/home/jerry


I plugged in one of my 64GB EXT4 formatted USB sticks and it mounted as /media/jerry/somenumbers and all my data was listed using vdir and was accessible.

I then mounted my <ROOT_FS> to /mnt and took a snapshot of @ that I titled @test
When I browsed @test with mc I noticed that none of the files under /media/jerry/somenumbers that I could see from the CLI use of vdir were visible in the @test snapshot. I browsed @ and did not see any files in that subvolume either. That makes sense because EXT4 is not Btrfs, CoW won't work on it and it won't be seen inside a subvolume created with the snapshot command.

Being mounted by fstab may mean that the fellow can drop file in and remove files from his ~/Dropbox subdirectory but I do not know if Dropbox's access software can work its way through Btrfs to get to /home/accountname/Dropbox. It may see /home and/or /home/accountname as a Btrfs filesystem, rightly so, and refuse to go any farther. Creating an EXT4 disk partition and mounting it as /home/accountname/Dropbox would not be any different, from the fs point of view, from plugging a USB stick in that was formatted with EXT4 and mounting it at the same location.

[jglen490]

The simple answer is avoid doing crappy things. I frankly don't care who's "watching" me - if they've got the time I've got the beer, as the old Miller commercial sort of said. They're going to be very bored. My wife wonders if someone is watching all the intersection cameras all the time. The answer is "No". Things get recorded, but if nothing happens, no one is looking. Granted someone could watch a particular intersection, at any given time, or be cycling through several feeds, but I know my city and the best thing that happens is the sanitation workers are well employed.

I know this is about Dropbox, but I don't use them anymore anyway. The most words written on any server that are mine are at work, and probably here. And the only picture you have of me is that homely old Keen Kutter hand plane in my profile.

[oshunluvr]

I hadn't used my dropbox account in quite awhile so I closed it. They ask "why are you leaving?" so I told them, not that it'll make any difference. They're too busy watching traffic cams!

[oshunluvr]

I forgot to ad that I self-host now using Nextcloud so I didn't need them anymore anyway.

[GreyGeek]

Dropbox was used by the church I attend to upload sermon recordings that I later edited with Audacity and then posted to the church website along with metadata. When I retired from doing that I no longer needed Dropbox on my system, so I took my name off the list and deleted the dropbox directory.

When I signed on to the ISP that supplies my 300 Mbi fiber optic connection I also paid for a static address, with a plan to use it as my "cloud". Alas, I rarely go anywhere so I have never set it up for remote connection. Too old, too tired, too lazy.

[bendy]

I use https://spideroak.com/ instead of dropbox. It works on all platforms and encrypts your data before it leaves your device, using a key which stays on your device. This means that, unlike dropbox, even they can't read your data.

I pay a modest price for this service, because I want to the customer not the product.

[kc1di]

I've changed to Mega for now at mega.nz the give you 50gb free and it will work with all file systems.
syncthing is another possibility. My needs are minimal now and only need to keep a few backups in the cloud. Like GG I'm retired and don't have need to store tons of stuff up there.

[GreyGeek]

I've changed to Mega for now at mega.nz the give you 50gb free and it will work with all file systems.
syncthing is another possibility. My needs are minimal now and only need to keep a few backups in the cloud. Like GG I'm retired and don't have need to store tons of stuff up there.

I LIKE Syncthing!
The data stays on my laptop but I can give an ID to a person to upload or download from a shared folder until I unshare the folder, and each person can be assigned to a unique folder, until you unassign that folder. It's open source and free, but I'd willingly donate to that project.

[TWPonKubuntu]

I like the idea of data storage on MY system, ala Syncthing. I don't use sharing but that would make sense if I needed remote access to my data on the home system.

This does not solve the backup problem, it just makes the data accessible from elsewhere. Still need backup devices, plural.

[GreyGeek]

...
This does not solve the backup problem, it just makes the data accessible from elsewhere. Still need backup devices, plural.

True, and that is where Btrfs SHINES:
btrfs send /mnt/snapshots/@YYYYMMDD | btrfs receive /backup/some_external_drive_or_url_or_usb

[GreyGeek]

I've changed to Mega for now at mega.nz the give you 50gb free and it will work with all file systems.
syncthing is another possibility. My needs are minimal now and only need to keep a few backups in the cloud. Like GG I'm retired and don't have need to store tons of stuff up there.

I gave MEGA a look and signed up. I also found in the Bionic repository the megatools app, which creates Dolphin Service Menus that allows you to add or remove or sync files with MEGA. Very nice.

[SpecialEd]

Rogue MEGA Chrome Extension Stole Passwords and Crypto Keys

A rogue version of file-hosting platform MEGA's Chrome extension has triggered a major security alert from the company. The variant was able to steal user credentials for sites including Amazon, Live.com, Github.com and Google's webstore, in addition to private keys to cryptocurrency wallets. MEGA is investigating how its Chrome webstore account was compromised.

[jpenguin]

I have a lot of files on dropbox & Google drive via insynchq. I pay for mediafire. Have 50GB of box.net webdav storage & have onedrive with my student email.
If I need a dropbox replacement, I'll look into pcloud

https://blog.pcloud.com/pcloud-drive-for-linux/

Sent from my E6810 using Tapatalk

[GreyGeek]

Rogue MEGA Chrome Extension Stole Passwords and Crypto Keys

A rogue version of file-hosting platform MEGA's Chrome extension has triggered a major security alert from the company. The variant was able to steal user credentials for sites including Amazon, Live.com, Github.com and Google's webstore, in addition to private keys to cryptocurrency wallets. MEGA is investigating how its Chrome webstore account was compromised.

I investigated that. The FF browser extension is not affected. If one was concerned they could run it in firejail.

moz-extension://a90b9c76-acf4-4c11-9730-76c34d348fef/mega/secure.html#blog_47


"On 4 September 2018 at 14:30 UTC, an unknown attacker uploaded a trojaned version of MEGA's Chrome extension, version 3.39.4, to the Google Chrome webstore. Upon installation or autoupdate, it would ask for elevated permissions (Read and change all your data on the websites you visit) that MEGA's real extension does not require and would (if permissions were granted) exfiltrate credentials for sites including amazon.com, live.com, github.com, google.com (for webstore login), myetherwallet.com, mymonero.com, idex.market and HTTP POST requests to other sites, to a server located in Ukraine. Note that mega.nz credentials were not being exfiltrated.

...


We would like to apologise for this significant incident. MEGA uses strict release procedures with multi-party code review, robust build workflow and cryptographic signatures where possible. Unfortunately, Google decided to disallow publisher signatures on Chrome extensions and is now relying solely on signing them automatically after upload to the Chrome webstore, which removes an important barrier to external compromise. MEGAsync and our Firefox extension are signed and hosted by us and could therefore not have fallen victim to this attack vector. While our mobile apps are hosted by Apple/Google/Microsoft, they are cryptographically signed by us and therefore immune as well."