Buzzwords of the Day 11-29-2023
*Special Note from the Author - This week's issue was written entirely in Vim!
#This Week's Buzzwords:
declare -a Buzzword = { "AI/LLM", "Exploit", "Backups" }
$Buzzword{0}= "AI/LLM" - Amazon Wants Your Business' Data
This week is chock full of Amazon & AWS news updates, one of which caught our eye in particular. Adam Selipsky, CEO of Amazon's AWS arm, announced their new business tool, an interactive LLM called "Q". Per their announcement, Q is meant as a tool for business development & "rubber-duck" assistant they can train on their specific data. At the time of writing, the tool is available to Amazon Connect users, primarily contact centers. As enticing as the promise of "artificial intelligence"-driven analysis may be, and while Amazon promises that data provided to individual users' Q models will not be used to train any other models, these tools have a track record of "leaking" data into training sets.
This type of model has tremendous appeal, but comes with (in this outlet's opinion) an equally significant risk. These tools are strong at many tasks, but sharing any user data to a service hosted off-site presents tremendous risk of that data proliferating that must be taken into account. With that in mind, this service could pave the way for safer, localized instances of similar models that businesses can leverage with minimal risk of leaking sensitive internal data.
Source Context:
https://www.theverge.com/2023/11/28/23980203/aws-amazon-query-generative-ai
~~~
$Buzzword{1}= "Exploit" - Is it still your OwnCloud if someone hacks it?
The first rule of data retention is that any data backed up does not exist, also phrased as "three is two, and two is one, and one is none". The concept at its core is simple: if your data is important, you should prioritize backing it up to ensure it is always available. There are plenty of third-party options like OneDrive, iCloud, or Google Drive (foreshadowing?), all of which share the same risk: you, the user, share your data to a third party company to retain for you. The services are presented akin to a bank's safety deposit box, where the user can enter/access their box with proper credentials, but the bank itself has no visibility into the contents of that box. However, in practice, it seems more and more like these services operate closer to a bank account: still requiring credential access, still maintained securely, but with clear visibility to the contents by the bank for "security purposes".
For this reason, many users turn to alternative third-party services that allow them still access their cloud storage over the WAN while maintaining the server hosting the service locally. One such service is OwnCloud, which allows users to host their local files to the WAN with credential access control and many "quality of life" features found in competitive services. However, OwnCloud has run into a pretty severe security incident this month. The company published an advisory earlier in November detailing the exploit: in short, they discovered that a crucial API built into their service can respond to a URL request with a link to the PHP environment (phpinfo) data for that instance of OwnCloud. This data includes intensely sensitive data including login credentials for the service. For users running OwnCloud in a docker container (hint: many of them), this data could potentially compromise any additional containers running that share credentials with their OwnCloud instance.
OwnCloud has published statements indicating their awareness of the issue, as well as suggested steps to investigate systems for this compromised feature. Ars Technica reports under 900 installs of the vulnerable API (called graphapi) at the time of writing. The exploit itself is massively critical, as there appears to be no current workaround apart from disabling the graphapi or removing it from local instances of OwnCloud until a future patch solves this issue.
Source Context:
~~~
$Buzzword{2}= "Backups" - So, I can totally trust Google, right?
If self-hosting cloud services can be compromised by an unpatched open vulnerability, surely massive corporations like Google are more secure backup tools, right? This week's news may put a bit of a pin in that trust: it appears as though Google's Drive application (specifically, their PC app versions 84.0.0.0 - 84.0.4.0) has misplaced user data, and lots of it. Users have been reporting lost or missing data from their Drive files on formal support forums, some of which indicate data 1-2 years old. Many of these reports also indicate the users had no local copies available, meaning the data will be truly lost if Google cannot track down the source of this issue.
For the time being, Google is investigating the issue, and sternly warns users not to disconnect their Google account until the issue is resolved, as well as warning against deleting/moving any cached data locally on their machine. ArsTechnica writers suspect these warnings imply an issue with Google's sync feature losing track with local machines somewhere along the line, which could point to a seemingly endless list of possible causes. Additionally, Google handles backups via two completely different processes, depending on whether users are manually backing up data or using Google's "mirroring" feature, which is a bit more automated. At this time, it appears users leveraging both processes have been affected.
Ultimately, the safest backup is a local backup, and this week especially highlights the importance of not trusting any singular backup solution. Stay tuned for a more in-depth breakdown of healthy backup options, as well as a peek inside Jort's storage solutions for their crucial data.
