The usual argument for using "cloud" over managing your own files/data is that it's very hard to safely manage your own data without making mistakes (data loss, etc). However, this is an example of how companies like Google also make mistakes. Furthermore, when Google/FB makes a mistake (like leaking your private data) they do it at a global scale.
I offboarded myself from all of Google's services a while ago, but I also think "cloud" is dead, at least in the cases where the cloud service holds the encryption keys on my behalf. I don't trust, and never will trust, any company to hold on to my data without either selling it to a third party or accidentally leaking it.
> I don't trust, and never will trust, any company to hold on to my data without either selling it to a third party or accidentally leaking it.
This is a very black and white way of looking at trust. Trust is earned, it can be broken, it can be rebuilt. All human relationships are built upon trust, and it is fallible just like anything else. To have trust is to create vulnerability. However, just as you mention, that vulnerability comes with an upside.
What you are saying is: because there is vulnerability in trust, you should trust no one.
I get an absolutely endless parade of other people's data to my gmail account. Doctors send me MRI scans. Bankers send me foreclosure notices. Airlines send me tickets. Undertakers send me condolences. The preponderance of evidence suggests that relying on individual vigilance on a large scale does not work as well as relying on the vigilance of large organizations.
I use Restic Backup to backup to a supported object storage and now setting up another provider (or VPS which will be slightly tricky) via Borg Backup (for the same data). The most important of that (~1GB) gets backed up to Tarsnap too. And once copy gets backed up to my local hard disk.
Once a while if I have to share any photos with some friends I send them an iCloud link and then remove the photos once they have either downloaded or seen.
I know there's a risk of losing the data if I forget/misplace the key(s) and my hard disk dies (at the same time) but then I could forget my Google credentials too, or worse still (with a higher probability) I could get locked out of my Google A/c and I don't know any Googler, neither do I have too many Twitter followers.
It's been worth it and once setup it's been running smoothly for over a year (across 2 laptop changes/data migration).
For consumer products, the cloud makes perfect sense. Scaling, performance and orchestration make it a perfect fit. And who cares about the few things that fall into wrong hands here and there...
Our business, on the other hand, works closely with government agencies, insurance companies and similar institutions, and the cloud is an absolute no-go. All sensitive data on-premise on the intranet. No need for change.
I believe many people are not aware yet, that things in the cloud cannot be controlled, or they consciously accepted that. Many companies won't take this risk.
I would like to say that Nextcloud, while it is not trvial to set up, is very very good at helping you set up the server securely. They additionally have a way to testing your server to make sure you did set it up, and helps you to correct issues.
I would love to see Nextcloud create a "time machine" type box, where it runs both as your router and as a "home cloud" service. That way it would be much easier to configure it as a public facing service.
So far it seems that Google is notifying the people who received videos that weren't theirs, not yet the people what had their video leaked.
> Google has been sending emails to affected Takeout users. In the email, which was first spotted by 9to5Google, Google writes, "Some videos in Google Photos were incorrectly exported to unrelated user's archives. One or more videos in your Google Photos account was affected by this issue. If you downloaded your data, it may be incomplete, and it may contain videos that are not yours."
> While this message is directed to Google Takeout users who tried to download their own data and accidentally got someone else's, we've yet to see a message directed to the "unrelated users" whose videos ended up in the archive. We've asked Google if it plans to notify users who have had their private videos exposed, and we'll update this article if the company responds.
The way I read it, it seems that only Takeout users were affected, on either end. Either way, this still needs to be made explicit for the sake of transparency.
How does this happen? I realize it's a small percentage, but this is one of the first tests you build. Even 1 photo (not to mention this is regarding videos) should never make it to another non-authenticated user. This is a massive mistake.
I don't work at Google (any more) but I have seen bugs in large-scale production that served one user's data to another user, and both times it had the same cause: a developer stored user-specific data into a process-global singleton because the consequence of some java decorator was non-obvious. When the next user request came along they were served the previous user's information.
I think, when discussing software, the phrase "should never" just doesn't belong. I have only a short software career, but of all the bugs and unintentional behavior I have read about failures small and big companies make, I am no longer surprised.
For that matter, software itself is full of surprising and undefined behavior, so it really shouldn't be a surprise that large corporations sometimes have "simple" mistakes that appear really big. That is just software in motion.
I once witnessed something similar. Deep down in the repository code there was a field marked `static`, which should've been an instance property. The value would be overwritten by the last user to access the repository; so this resulted in a race condition where one user might see the other's data.
One way I've seen this happen is images have UUIDs (or just incrementing), they're base-64 encoded somewhere after security checks, and someone accidentally called `toLower()` on the id.
I once witnessed a very similar bug. The story was a comedy of errors:
1: I interviewed a HORRIBLE candidate and told my boss in no uncertain terms not to hire the bozo. Then, I look at my colleagues and explain how poorly the interview went.
2: I go away for two weeks to have surgery
3: I come back and learn that we're hiring the bozo
4: My boss asks me to do some pair programming with the bozo, and he doesn't understand some very basic concepts
5: I hear the bozo is debugging webservice code in production
6: We had a data leak from one of the bozo's bugs
From what I remember, it was a very dumb bug based on clear misunderstanding of fundamentals.
This makes sense for backups, but for something like photos, there's a lot of value-add you're missing out on. Something like sharing a photo with a friend becomes an ordeal.
This is a nice platitude, but frequently most b2c client apps that use cloud storage (eg Google Photos) give no option to encrypt data clientside for storage.
Considering this is 4 months later... This can't have been very widespread. If I saw someone else's video in my takeout archive, I'd have totally contacted the tech media...
Honestly, I would not have noticed if a bunch of someone else's videos were on my takeout archive - I've downloaded that takeout archive multiple times as a backup, and I've browsed some stuff there (a fraction of the total) once to see if the things I care about are there, and that's it.
For all I know, your videos might be in a zip file on my external HDD I use for backups, and I'll never know unless I need to restore data after some disaster and that's the latest takeout that I have.
Logging is really locked down due to GDPR stuff... Which ironically means the privacy laws means they've deleted the specifics of the privacy violations that occurred.
Does anyone have suggestions for a self hosted photo service with - importantly - a solid iOS companion app to do photo sync and possibly browse photos?
I would prefer using a simple S3 backend. It seems that finding a reliable photo sync'ing app for iOS (outside of Google Photos or Dropbox) is difficult.
I've been manually using Image Capture and uploading to S3 but that's quite inefficient. Thanks!
I find Nextcloud pretty great. There's a sync client available on f-droid. It also has capabilities for calendar and contact list synchronisation, so you can move that off your google account.
It came preinstalled with my instance of mail-in-a-box (https://mailinabox.email/), which is an easy way of hosting your own email. With my self-hosted instance of mailinabox and LineageOS my phone is completely google-free. :)
Edit: And it has a decent iOS sync client as far as I know.
Interesting that the bug was in Takeout, which might have a fair amount of privacy concerned users that were trying to leave Google. Guessing some caching or "generate a unique url" type bug.
I've seen services (Google Photos, Dropbox, OneDrive) try to opt in the user to having data automatically uploaded when they take a not really related action (like logging into the google account on their phone, connecting a USB device, or misclicking on an icon in their file list). I do wonder if there's any penalty that'd apply to them if they then lost data that users hadn't realised was being uploaded?
[+] [-] brenden2|6 years ago|reply
I offboarded myself from all of Google's services a while ago, but I also think "cloud" is dead, at least in the cases where the cloud service holds the encryption keys on my behalf. I don't trust, and never will trust, any company to hold on to my data without either selling it to a third party or accidentally leaking it.
[+] [-] crazygringo|6 years ago|reply
The only question is, is your cloud provider less likely to make mistakes with your data than you are?
For most people, the answer is going to be orders of magnitude less likely.
[+] [-] danielrhodes|6 years ago|reply
This is a very black and white way of looking at trust. Trust is earned, it can be broken, it can be rebuilt. All human relationships are built upon trust, and it is fallible just like anything else. To have trust is to create vulnerability. However, just as you mention, that vulnerability comes with an upside.
What you are saying is: because there is vulnerability in trust, you should trust no one.
[+] [-] thedance|6 years ago|reply
[+] [-] pergadad|6 years ago|reply
[+] [-] gman83|6 years ago|reply
[+] [-] pgt|6 years ago|reply
[+] [-] balladeer|6 years ago|reply
Once a while if I have to share any photos with some friends I send them an iCloud link and then remove the photos once they have either downloaded or seen.
I know there's a risk of losing the data if I forget/misplace the key(s) and my hard disk dies (at the same time) but then I could forget my Google credentials too, or worse still (with a higher probability) I could get locked out of my Google A/c and I don't know any Googler, neither do I have too many Twitter followers.
It's been worth it and once setup it's been running smoothly for over a year (across 2 laptop changes/data migration).
[+] [-] tantalor|6 years ago|reply
[+] [-] zubspace|6 years ago|reply
Our business, on the other hand, works closely with government agencies, insurance companies and similar institutions, and the cloud is an absolute no-go. All sensitive data on-premise on the intranet. No need for change.
I believe many people are not aware yet, that things in the cloud cannot be controlled, or they consciously accepted that. Many companies won't take this risk.
[+] [-] kop316|6 years ago|reply
I would love to see Nextcloud create a "time machine" type box, where it runs both as your router and as a "home cloud" service. That way it would be much easier to configure it as a public facing service.
[+] [-] victords|6 years ago|reply
The usual argument is that Google is less likely to make mistakes than the average Joe managing his own infrastructure.
[+] [-] jimbob45|6 years ago|reply
[+] [-] nkrisc|6 years ago|reply
> Google has been sending emails to affected Takeout users. In the email, which was first spotted by 9to5Google, Google writes, "Some videos in Google Photos were incorrectly exported to unrelated user's archives. One or more videos in your Google Photos account was affected by this issue. If you downloaded your data, it may be incomplete, and it may contain videos that are not yours."
> While this message is directed to Google Takeout users who tried to download their own data and accidentally got someone else's, we've yet to see a message directed to the "unrelated users" whose videos ended up in the archive. We've asked Google if it plans to notify users who have had their private videos exposed, and we'll update this article if the company responds.
From https://arstechnica.com/gadgets/2020/02/google-photos-bug-le...
[+] [-] MarioMan|6 years ago|reply
[+] [-] SnowingXIV|6 years ago|reply
[+] [-] thedance|6 years ago|reply
[+] [-] whatisthiseven|6 years ago|reply
For that matter, software itself is full of surprising and undefined behavior, so it really shouldn't be a surprise that large corporations sometimes have "simple" mistakes that appear really big. That is just software in motion.
[+] [-] bouke|6 years ago|reply
[+] [-] dehrmann|6 years ago|reply
[+] [-] gwbas1c|6 years ago|reply
1: I interviewed a HORRIBLE candidate and told my boss in no uncertain terms not to hire the bozo. Then, I look at my colleagues and explain how poorly the interview went.
2: I go away for two weeks to have surgery
3: I come back and learn that we're hiring the bozo
4: My boss asks me to do some pair programming with the bozo, and he doesn't understand some very basic concepts
5: I hear the bozo is debugging webservice code in production
6: We had a data leak from one of the bozo's bugs
From what I remember, it was a very dumb bug based on clear misunderstanding of fundamentals.
[+] [-] beamatronic|6 years ago|reply
[+] [-] friendly_fren|6 years ago|reply
[+] [-] dehrmann|6 years ago|reply
[+] [-] sneak|6 years ago|reply
[+] [-] londons_explore|6 years ago|reply
[+] [-] PeterisP|6 years ago|reply
For all I know, your videos might be in a zip file on my external HDD I use for backups, and I'll never know unless I need to restore data after some disaster and that's the latest takeout that I have.
[+] [-] x__x|6 years ago|reply
[+] [-] ipsum2|6 years ago|reply
[+] [-] londons_explore|6 years ago|reply
[+] [-] gregsadetsky|6 years ago|reply
I would prefer using a simple S3 backend. It seems that finding a reliable photo sync'ing app for iOS (outside of Google Photos or Dropbox) is difficult.
I've been manually using Image Capture and uploading to S3 but that's quite inefficient. Thanks!
[+] [-] kylehotchkiss|6 years ago|reply
[+] [-] cleee|6 years ago|reply
It came preinstalled with my instance of mail-in-a-box (https://mailinabox.email/), which is an easy way of hosting your own email. With my self-hosted instance of mailinabox and LineageOS my phone is completely google-free. :)
Edit: And it has a decent iOS sync client as far as I know.
[+] [-] nahtnam|6 years ago|reply
[+] [-] jayFu|6 years ago|reply
[+] [-] tyingq|6 years ago|reply
[+] [-] dang|6 years ago|reply
[+] [-] Macha|6 years ago|reply
[+] [-] martythemaniak|6 years ago|reply
https://news.ycombinator.com/item?id=20373112
Seems like something similar. Ie, someone else's weird crap was used by my account's Assitant to make a compilation/summary.
[+] [-] subject119|6 years ago|reply
[deleted]
[+] [-] w0m|6 years ago|reply
[deleted]
[+] [-] scarejunba|6 years ago|reply
[+] [-] kerng|6 years ago|reply
Also, very curious to learn more of the technical details down the road?
[+] [-] dsd|6 years ago|reply
[+] [-] minikites|6 years ago|reply
[+] [-] TheCapn|6 years ago|reply
[+] [-] Mindwipe|6 years ago|reply
This is a catastrophic issue and it's terrible Google have sat on this for so long.
[+] [-] TuringTest|6 years ago|reply
https://news.ycombinator.com/item?id=22231922 Reviving Sandstorm (sandstorm.io)