reddthat

joined 2 years ago
MODERATOR OF
[–] reddthat@reddthat.com 1 points 2 years ago (6 children)

Do you have a reference for that? Gmail is 25...

[–] reddthat@reddthat.com 7 points 2 years ago (2 children)

25MB is "the" limit because gmail is basically the email provider.

https://support.google.com/mail/answer/6584?hl=en&co=GENIE.Platform=Desktop#zippy=%2Cattachment-size-limit

If you send an attachment above 25 it makes it a gdrive link

[–] reddthat@reddthat.com 19 points 2 years ago (16 children)

Am I the only one thinking this is fake because its a 32MB file?

Email usually caps out at 25MB...

[–] reddthat@reddthat.com 8 points 2 years ago

Thin clients are the best for this. You can take your pick on an abundant of options on eBay.

Jellyfin isn't that power hungry, and it would run on a rPi if you set it up right. You're only problems are when it decides to transcoder file and you can get around that by using Kodi with the jellyfin add-on. (And choosing the native paths option. Kodi grabs all the data via, SMB, NFS, etc)

This way you can use Jellyfin as a media enrichment solution, not worry about the CPU or GPU encoding and just worry about watching everything.

[–] reddthat@reddthat.com 11 points 2 years ago

Also, no. Pict-rs the service behind all the Lemmy image hosts, has a config of max-images=1 set by default

Lemmy also does not use the background mode it uses the active mode for uploading images to pictrs for processing.

This means that your images need to completely upload, process, and return back the url within 15/30s otherwise it fails and you get that random red box JSON error line 1.

If you scaled that out to multiple images (let's say 5), you would run into the risk of timeouts happening.
On-top of that Lemmy doesn't have that capability (yet?).

People usually upload 1 main image, then in the body of the post you can upload more images in there. Add them with the picture icon.

[–] reddthat@reddthat.com 2 points 2 years ago (1 children)

It's not the browser's fault for sending data to Google tag manager... It's a website's fault.

At least with a non-chrome browser you can install uBlock and protect your self more than a chrome browser could.

Why take the chance?

[–] reddthat@reddthat.com 2 points 2 years ago

Sorry! Was drinking! It was probably lost in the wall of text.

I only got up to 3 months, with a retention policy of 7day, 4weeks, 3months as the dedupe is very good. If I didn't have dedupe it would be only up to 4 weeks.

The reasons are, I notice if I've lost a file in <3months and if I lose a drive the latest backup would be the one I restore from. (Yesterday in this case).
Why would I ever need the 1 year old backup?

Hope that makes more sense.

[–] reddthat@reddthat.com 0 points 2 years ago (2 children)

Keep it as long as your data changes. 3 months is a good amount for myself. The backups are only good for deleted documents (for me).
I always think to myself, at what point will that data still be valuable? Most of the time all the important stuff sticks around forever, and if you delete a document how long till you realised? A day? A month? Half a year?

That might help cull some of the older data.

You could always use a different host for your offsite. We use Wasabi storage which is $6-7/TB/m for Reddthat, and for object storage it's great. Or could even use B2 etc. But for personal data a good 70$/y might be out of your budget. If borgbackup can handle s3 it can handle wasabi.

[–] reddthat@reddthat.com 2 points 2 years ago

Someone will after seeing it today

[–] reddthat@reddthat.com 3 points 2 years ago (2 children)

?

Did you reply to the wrong post?

[–] reddthat@reddthat.com 5 points 2 years ago (4 children)

The percentages are not the percentages of total battery loss, they are the total amount of time active for the amount of loss you have had. As far as I understand it.

Ie: You have lost ~15% battery, but the total number of % listed is in the 50% mark. (+ All the system apps)

A new Android security update came out. Maybe it was installing it in the background? Maybe you had low wifi signal and do your phone has to use more power (and generates heat) to connect.
There are many reasons why a phone can get hot. Can't trust those battery numbers unfortunately

 

Oooo grabbing the 🍿

 

. help me out!

 
8
submitted 2 years ago* (last edited 2 years ago) by reddthat@reddthat.com to c/australia@reddthat.com
 
1
submitted 2 years ago* (last edited 2 years ago) by reddthat@reddthat.com to c/techsploits@reddthat.com
 

It started on March 17th, 2022 and was resolved on May 26th, 2023.

What was potentially exposed?

User account information and order details including names, physical addresses, email, phone numbers.

Your system76.com credentials and credit card were not compromised at any point. It was not the contents of our entire database, but a random selection of what happened to be in our web servers' memory at the time. It is not possible to determine which users had their information visible over the course of time when this leak was occurring.

Can any of this data still be accessible?

This data was embedded directly into the source code of our website, so it will be included in any archives that were taken during this time period. We have already been in contact with the internet archive, and they have removed their data, but there are other potential places where it could have been stored.

What pages on our site contained this data?

Due to the nature of the flaw, the data was being included to some extent on every page on our site.

Why was there a delay before resolving this and making an announcement?

We wanted to do our best to clean up any residual customer data that was easily accessible before disclosing the nature of this leak. This involved working with the internet archive to delete their copy of the data before public disclosure.

Is there any evidence that any of this data was misused?

To date, the only indications of misuse that we have are reports of spam emails being sent to customers.

Why did it take so long to discover?

There were a number of factors that play into this, but they do not change the fact that it should not have been happening for over a year.

You would need to look at just the right location in a very long single-line string. This is a common method for minimizing javascript and most developers are used to seeing such long lines on a website. There's usually not much reason to look into them in more detail.

It was not something a dev would ever see in their local environment. It was also not noticeable in our staging environment due to the difference in activity there.

It is entirely unexpected to see sensitive data exposed in this fashion.

What are the technical details?

One of the technologies that we use on our website is server-side rendering with nuxt. Several years ago a caching layer was implemented so that the server-side rendering wouldn't have to ask our backend API every time it needed the same information. It worked fine, but front-end technologies shifted and the way it was implemented became outdated.

Last year our team made an update to a seemingly unrelated piece of code, to fix a deprecation message no less. However, this exposed the initial implementation of this cache to a new style of handling state, which it had not been written for and was not prepared to handle.

So what happened is the following: state that shouldn't have been shared was shared between sessions. This is one of the major pitfalls of using server-side rendering in a web application. Unlike an API, the code in an SSR application doesn't always have distinct boundaries between what happens on a single client vs. what happens on the server.

What is being done to prevent similar leaks in the future?

For the time being we are running an automated scan to alert us if sensitive data is ever found on our website again. We are also continually performing manual inspections to make sure nothing else is in there that shouldn't be, but we are confident that we have identified and fixed this issue.

In the long term, we are moving towards a static model (SSG instead of SSR) for our website, which will eliminate the majority of the risk of shared state.

This is a mistake that we will learn from and we offer our sincerest apologies for leaking information that was entrusted to us. We deeply regret the incident and remain committed to safeguarding your information and trust.

 

At least Guardian Australia is saying get lost to them. Now if only we could get them off youtube and all other internet content.

view more: ‹ prev next ›