That’s your worst-case scenario, right? Minors with ready access to vanilla photographs of naked people, on above-board commercial websites? So what. Tell me this abusive horseshit is the only way to stop that and I’ll still reject this abusive horseshit.
The pearl-clutching horrors imagined by conservative dullards are a mundane experience for millions of people, and relatively few of them become dog-fuckers or axe-murderers. Almost like a healthy libido is normal and 18 isn’t the day you take the shrink-wrap off your genitals.
Teenagers masturbating is a non-event. It’s as unremarkable and unpreventable as atomic decay. It will happen. Do you want it to happen to whatever quasi-erotica passes through the filter? Bugs Bunny in drag, beach volleyball, that one episode of their favorite show where everybody shrinks? Shoddy AOL filters probably made more furries than Disney ever did. AI’s gonna twist kids right up. Tell me with a straight face that’s better than real photos of fake tits.
By all means, keep actual smut off broadcast TV. Expect websites to put the weird stuff behind warnings. Don’t sell porn to minors. But if your website doesn’t take a credit card to visit, hey guess what, anyone can see it, and anyone will. Oh well. People who think that’s the end of the world are lunatics who mean it literally.
The first "porn" I saw was in middle school. It was a single bootable floppy disk with a pitiful menu of crude -- almost repulsive -- animations on an Apple II, basically no better than stick figures. The lesson I took away from it? How to program animations on an Apple II. And also that using one-voice beeps and honks over a bitbang speaker to suggest the buildup to an orgasm is hilarious.
/e/ includes microG per default and thus calls google servers. /e/ includes unique identifyer per update call tracking its users. Graphene uses several proxy servers to hide user information, /e/ does not in similar way. And so on…
☝️ this is correct. GSF calls home and /e/ is a different beast. The founder of Murena and /e/ is on Fedi so you could drop him a message on Mastodon and see how he answers.
According to the information provided on the DivestOS website (source: divestos.org/pages/faq), microG only contacts Google servers if specific options are enabled. This means that certain features or functionalities may require communication with Google servers, but it is not a continuous or automatic process.
As for /e/, it does not include unique identifiers per update call. However, it does collect your IP address when you initiate an update.
Additionally, when using the network location provider feature, your approximate location may be shared with Mozilla. However, you have the option to easily disable this feature if you prefer not to share your location.
It’s important to note that /e/ foundation is a non-profit organization and does not engage in any advertising business. They have no company to sell any data to.
Chrome or Chromium? Because that “hardening” is only the switches they allow you to use, so if its full of proprietary tracking software it is not hardened at all
Chrome. I know that might be hard to believe but the switches work. You can absolutely stop Google from prefetching their usual services. Plus I don’t login with a Google account on the browser, that makes a huge difference.
There really isn’t much difference. I used Ungoogled-chromium before now. I use Chrome for selfish reasons. The flatpak for it(dev version) is auto updated with no human input required so I get fixes and security patches earlier and I kinda like that release.
Just so you know, Chromium Browsers are more secure if you use the native package. But just for privacy reasons I would not run Chrome unrestricted in my system.
Chromium Browsers are more secure if you use the native package.
This conclusion is relative for everyone as we all have different security needs. Plus there’s no easier, better supported way to sandbox Chrome on Linux other than using Flatpak’s permission model.
It’s also ironic for you to be speaking about security when you are installing/updating your browser using random curl bash scripts.
You havent looked at the repo. And we are talking about different sandboxes here.
The browsers sandbox websites, this is broken if the entire browser is sandboxed as you need to remove that capability to do so.
My bash script pulls in the official brave repo and gpg key, fix the access permissions and that is it. Brave has no documentation on how to use their repo without dnf so this is needed.
The repo has gpg verification enabled and the system will update the browser.
Please dont spread misinformation if you havent even looked at the “random bash script” that does not handle the updatingô
Those IPs eventually end up on block lists as users do dumb things with them. You could definitely benefit from auto cycling through them but it’s still going to be luck of the draw, ultimately. Normally you’ll get a different IP each time you connect, even to the same location/server so if your VPN client has a CLI component, even a basic one, you could write a simple script to tell it to ‘disconnect’ and then ‘connect’ periodically, for instance.
Depending on which VPN client you’re using on the router, that would be the simplest approach to explore imo.
ETA you could also explore getting a residential IP from your VPN provider if they offer that. It’s a little more expensive but they don’t end up on block lists as much. Less hassle.
Thank you. I’ll explore the CLI option. My VPN provider does not offer residential IPs but I hear Proton will be offering dedicated IPs soon and will probably use that in addition to.
No worries. I do know that Windscribe has both CLI as well at custom configs that you can plug into router clients (i.e. wireguard, openvpn, etc), and they also offer residential IPs.
Thanks to everyone for replying! I have decided to stick with brave for now since after an update to the flatpak the thing’s font is back to readable again.
Okay why do these random packages keep popping up with this? For attention?
It's irrelevant, they are barely used by anyone and if a site blocks legitimate e-mail providers, then it is not a site worth registering with in the first place.
Just because not many people use a package, doesn’t mean it is irrelevant. For open source packages (or anything really), as soon as one additional person uses a package, that package becomes relevant. The person/people using it become its advertisers, and when enough people are seen using a product, especially a free one, a larger group will use either that package or something similar to cut their own programming costs.
This is simplified, but the point is that we need to stop this sort of thing at the root (the package itself) before it gets noticed by larger groups and companies who might actually get away with this BS. Always remember, we are tech/privacy nerds. We are the minority, and the average person doesn’t care until something hurts them directly.
On my job, they use Microsoft as main workspace, so one time when they tried to e-mail me on my personal e-mail, i never received one, they always sent again to my protonmail… IDK why Microsoft does it… but now it makes me think Microsoft is even more evil than i thought
It’s possible that your work has problems with spam and has thus set up their own spam filter and that filter might be more aggressive.
There are also ways to change the spam filtering in m365 mail.
It’s also possible that your work hasn’t setup mail properly and protonmail is the one that rejects the mails. We had an issue at work where OOF auto replies didn’t work to external gmails (and probably others) because Gmail rejected the emails (I had confirmed that Gmail was the one that rejected it via the email traces in exchange). That wasn’t Microsoft’s fault.
I can send stuff to my proton mail without issues from two different Microsoft 365 mails.
One missed email should not be interpreted as malicious intent. It’s also honestly quite likely someone just misspelled or something.
Those are the good providers. If there were another good provider and this is being done with intent than they will just block that domain as well. I use a custom domain with proton, I think that would protect against this but maybe some folks more engaged could chime in before you take that as advice.
Blacklists like these aggressively and unapologetically collect all privacy-focused email domains they find, including simple forwarding and tagging services. With more and more sites using these lists to reject or black-hole email addresses, it has become difficult to protect one’s self from spam and cross-site account tracking.
Dear web developers, please don’t use these lists. Well-intended or not, they are privacy and user-hostile.
Devs can use them to block DISPOSABLE mails, not PRIVACY legitimate emails. That’s why it is critical to remove privacy oriented email domains from such lists
I’m okay with people using burner email addresses to get my free content, I just need to be able to filter them out of my list so it doesn’t drive up bounces and hurt deliverability.
AWS SES, for example, is fucking rabid about bounces. Being able to filter out addresses you know are going to bounce is pretty important.
Can a list like this be used for anti-privacy measures? Absolutely! Does that mean we should never create lists like this? For me that depends on whether or not you think we should prevent encryption because bad actors can use it for bad purposes.
You’re getting into very sketchy territory by saying a dev who is using a public GitHub repo to solve their problems needs to take it down because of how others are abusing it. Should the original dev be punished by their email provider because they shouldn’t be allowed to use this? Should anything that has potential harm be required to be a private repo? Who gets to decide all of that?
In the interest of specifics, can you point to where this specific list has done harm? I spent a fair amount of time looking around to make sure I wasn’t going out on a limb for someone with neutral views.
You’re getting into very sketchy territory by saying a dev who is using a public GitHub repo to solve their problems needs to take it down
No, I don’t believe I said any such thing. Since you mention it, though, I think taking this list down and removing the false positives before bringing it back up would be the responsible thing to do.
In the interest of specifics, can you point to where this specific list has done harm?
I know from personal experience and investigation (both as a user and on the admin side) that there are now many cases of privacy-focused email addresses being rejected, or even worse, accepted and then silently black-holed, due to the domains being inappropriately added to lists like this one. I don’t know of a place where people report such cases so they can be documented in aggregate, but if I find one, I’ll be sure to bookmark it in case your question comes up again in the future.
So you’re lumping this resource into a bucket with other resources that were malicious but you have no direct connection from this resource to harm you claim it causes? You’re saying a dev using this list to allow people to download free content but prune emails to save his bounce rate is doing bad things and needs to convert their FOSS use-case to yours?
Who gets to decide? You didn’t answer that and in the interest of good faith I’ll pull that one down as the important one since it follows from the argument I feel you’re making.
You’ve ignored my questions attempting to flesh out your point and refuse to link this specific list to anything bad. I don’t think you understand good or bad faith. Good luck with that!
I feel like having different attributes for each domain might be helpful so that those services using the list can filter for just the things they care about such as burner emails, anonymous registration, whether it requires any email/phone verification, etc. Right now domains kind of have the problem of just being on the list or not, with no indication on why they might be a problem.
The beauty of open source code is that you can fork this project and add that. The repo maintainer seems to have a simple litmus test for whether or not something should be on the list: is it something that will cause a bounce for email distribution? That’s a really subjective test so you kinda have to talk to the repo maintainer about answering it. I suspect they feed it into a library, perhaps one of the ones linked, for use with their platform, so their problem is most likely solved.
privacy
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.