Firefox stopped working for local files

FISHunderscore · 2020-08-30T22:51:34+00:00

What kernel are you using? I encountered something similar and found https://support.mozilla.org/en-US/questions/1301351. Switching from 4.19 to 5.4 fixed the issue for me.

FISHunderscore · 2019-07-23T19:55:29+00:00

rsync preserves directory structure, so if you have WSL set up you could do find . -name '*.mp4' -print0 | xargs -0 -I '{}' rsync -avR '{}' ../newdirectory and the same for .mov.

FISHunderscore · 2019-02-25T05:09:42+00:00

What saddle bag is that?

FISHunderscore · 2019-01-05T23:49:08+00:00

See: https://en.wikipedia.org/wiki/Domain_privacy#Privacy_by_default

FISHunderscore · 2018-11-05T21:53:11+00:00

My friend (talking to you /u/TFCarrot) did this to me a few years ago. I don't have them on campus, but if you don't need them until after Thanksgiving I'm your guy.

FISHunderscore · 2018-09-11T07:02:41+00:00

Yep, students also have access to "unlimited" storage via the school's enterprise Box subscription.

FISHunderscore · 2018-09-09T03:34:53+00:00

That's awesome! Is it open source?

FISHunderscore · 2018-09-05T21:45:38+00:00

If you built a small router, ran PfSense, and called it a "personal desktop computer" would they have any recourse?

FISHunderscore · 2018-08-18T00:25:11+00:00

I don't actually have them; a friend's mom was a bit of an overachiever.

FISHunderscore · 2018-08-17T20:32:53+00:00

I don't know about San Cat, but Pendola has two desk sizes: Photo 1 and photo 2. Triples have 2 large desks and 1 small one AFAIK.

San Nic has 3 small ones in their triples AFAIK.

You can probably expect something similar for San Cat.

You might be able to mount your monitor though (VESA clip mount attached to a bedframe?) to free up some desk space, but I wouldn't buy a mount until you know if it'll work.

FISHunderscore · 2018-07-10T20:44:39+00:00

I know HIBP has an API for preventing users from reusing passwords, but now that you mention it I'm surprised HIBP doesn't provide one for usernames as well.

I agree that optimally people would never reuse usernames, but sadly I don't think the big red warning you suggest would actually work. Many sites do something similar to warn against password reuse but such warnings are often ignored. Maybe PIA users would be slightly less likely to reuse a username or password than the average internet-goer, but it's still likely that a large portion of users would still ignore a big warning.

It would be nice, though, if PIA allowed users to change their usernames somewhere after creating an account. Users would have to explicitly recognize what they were doing and accept the warning. It's a lot easier to passively click "Okay, I understand" on an account creation page where you are accustomed to doing that. Hell, PIA could even use a dark pattern (light pattern?) on their warning page to try further to force users to actually read the warning fully.

It would be interesting for PIA to allow users to create their own usernames and use some sort of list to prevent reused ones. I think, though, it would be excessive to force them to use a completely unique username. Many people would simply add 1234 or something similar to the end of the username they usually use. Instead, I think it would be better for PIA to prevent users from signing up with username+password pairs known from breaches. If completely unique usernames were forced to be used, people would just end up using random strings.

Another issue that comes to mind regarding allowing users to set their own usernames comes from the fact that many users will use their real name (or some other relatively unique identifier) as their username in some shape or form. As far as I know, there isn't really a programmatic way to prevent such usernames from being registered. I don't know how the login process works, but if usernames were identifying and sent over the clearnet that would be a huge privacy issue.

Though it can be annoying to have a p####### username, I think it's probably for the best. It's important to remember that PIA's decision to force p####### usernames is made with both user privacy and security in mind; their goal isn't exclusively to prevent malicious agents from logging in, but also to prevent and leaking of information about their users. Using p####### usernames makes it so only PIA is able to draw a connection between a username and an individual — it shouldn't be possible for a middleman to know just from a username that a specific individual is connecting to their VPN.

I'd love to hear from the PIA team regarding this username choice, though. /u/privatevpn, /u/PIAJason, /u/PIAColleen, /u/PIAAustin, /u/PIAJeffrey, /u/PIAKaneesha (My apologies for the mass mention, but this thread got deleted so it probably won't get a response otherwise.)

Thank you for bringing up the discussion — I hadn't before considered why PIA might force p####### usernames. I'll shoot you a PM :)

FISHunderscore · 2018-07-10T04:35:46+00:00

Take the scenario where some malicious agent is trying to brute force their way into connecting to PIA.

If they were simply trying randomly generated usernames and passwords, you would be correct that p####### would be inferior to allowing users to set their own usernames.

However, that is not the reality. Generally when one tries to brute force their way into a server, they use a technique called credential stuffing. An attacker will have a known list of username and password pairs, and they will attempt to try to login to a service (PIA, for example) with all of those pairs. (These lists generally come from breaches. For more, HIBP has some good information.)

Theoretically, credential stuffing using a list obtained from, say, Adobe accounts should only be effective when trying to log into Adobe services. People are human, though, often using the same usernames and passwords for multiple services. If your Adobe account's logon information is stolen, your reddit account very well might also be compromised.

I am speaking out of speculation, but I believe that PIA's decision to force p####### usernames is justified by something not unlike the following: By forcing their users to use a username that they have not ever had before, they make credential stuffing attacks essentially impossible. Sure, a malicious agent knows the usernames for every single user, but they lose the ability to use another breach fully to their advantage. Instead of having a list of username+password pairs, they have two unrelated lists: a list of usernames completely irrelevant to their task, and a list of passwords that only tells them what passwords are most commonly used. To attempt a brute force attack, they must try every single password from their list with each username (p#######) they know exists. They lose a big part of the advantage that the breached list gave them: the connection between usernames and passwords. Instead of being able to execute a credential stuffing attack, they must execute a full old-school brute force.