Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)
More so, if it is easily sandboxed, it should just be a webapp. Which discord already is.
Just use the website.
Browsers are already easily themed, have plenty of tools to change deeper functionality, and are way more sandboxed than any other app packaging ecosystem.
That would be a fail of the fingerprinting protection. A properly set up TOR browser for example should not allow that detection by any means. If you know how to detect it, please report it as a critical vulnerability.
I could think of maybe some edge case behavior in webrenderer or js cavas etc., which would mainly expose info on the specific browser and underlying hardware, but that is all of course blocked of or fixed in hardened browsers.
Further, if you have a reliable method, you could sell it off to for example Netflix, who are trying to block higher resolutions for Linux browsers but are currently foiled by changing the useragent (if you have widevine set up).
That can’t have been the reason, rather the fact it could tell.
Your browser sends information about its version and the os in the useragent string. It is supposed to lie and say it is a very commonly used useragent, specifically for purposes of fingerprinting. That would be windows, default configuration, firefox version something not you firefox version
This isn’t session hijacking but taking some magical token from Chrome that can generate sessions. Which has far more attack surface.
What if they wanted to buy them from the start and are thinking they can drop the price?
3:1 of 315k is 80k deaths
How was the news?
You heard of standby and the likes? What do you recon that does to programs calculating with time in that exact moment?
If one doesn’t realize you’re op, the entire thing can be interpreted very differently.
Then “Not sure if sarcastic and woosh, or adding to the joke ಠ_ಠ” could be interpreted as something like “I’m not sure if you are adding to the joke and I’m not understanding it”.
Huh, thank you for telling me, I’ll amend the file with that info. This being a thing will probably spare many the troubles I experienced.
I did some digging to reconstruct what happened in my case. The file was created on 2022-12-08, and I remember this being after I rediscovered my earlier approach, from - going by my browsing history - mid september 2022. I worked through plenty of wiki pages at the time, including the btrfs docs on swapfiles, where I probably got my commands. The truncate in there to fix earlier mistakes is something I would keep in, but not add myself, so I must have copied that pages solution. Interestingly, going by archive.org, between dec 02 and dec 13 the documentation on btrfs fi mkswapfile was added to that page.
I am in no way confident in my memory here, but I vaguely recall seeing that command, and being somewhat surprised to not remember it from earlier. That confusion may have even contributed to pushing me to create the file.
Had I seen it, I probably would have tried the command and seen it not exist. Following the note of btrfs 6.1 being required, I would have checked the version and seen that my distro didn’t have btrfs-progs 6.1, not even as an alpha on the development channel.
I may also have remembered there being multiple commands needed earlier, and not wanting to deviate from the proven method dismissed the apparently simpler method.
To complete this very meaningful and productive story, on 2022-12-23 my distro got the early christmas present of btrfs-progs 6.1 as an unstable release in the dev channel. After many retractions and republishings of a total of 4 subversions, on 2023-03-04 the first stable release of 6.1.x was made available.
I was 6 months early. Or rather the btrfs devs were 6 months late.
Edit (actually not edit because I didn’t send yet):
I actually checked the repo and the documentation changed on dec 06. Here is the commit. The corresponding release occurred on dec 22.
Dumping 30mins into writing this actually resulted with a memorable story. By chance I stumbled over the documentation of a new feature, 2 days after it had been written, but 2 weeks before even the first alpha release containing it was created.
Try btrfs, where with only 5 hours of research you can create a swap file without writing the entire file.
Also there is no other option, the 5h are non-optional.
After doing that twice, In my / now lives
/swapfile-howto # this is btrfs not a normal file system.
# We have to create and allocate the file in a btrfs friendly way,
# and tell btrfs to not move or segment it.
touch /swapfile999
chmod 600 /swapfile999
truncate -s 0 /swapfile999
chattr +C /swapfile999
fallocate -l 999G /swapfile999
mkswap /swapfile999
swapon /swapfile999 -p 200
And since people won’t use the website, the website won’t use the list. So the list would be useless.
The maintainer seems to have followed the same interpretation, weighing legitimate use against spam use. This is the official response to the issue as of 8h ago:
Dear Contributors,
We value your suggestions for expanding our list of disposable email providers. Your input is crucial in enhancing our tool’s capabilities.
Decision on Gmail and ProtonMail Inclusion
After thorough evaluation, we have resolved not to include Gmail and ProtonMail in our list. Our rationale is based on the following technical and operational considerations:
1. **Reputation and Reliability** * **Gmail and ProtonMail**: Established, reputable providers with a high trust level for personal and professional communication. * **Distinction**: Unlike typical disposable email services, they offer long-term, reliable email solutions. 2. **Active Abuse and Spam Prevention Mechanisms** * **Effective Systems**: Both providers have robust mechanisms to detect and mitigate abuse and spam. * **Proactive Monitoring**: Ensures a secure email environment, reducing the prevalence of malicious activities. 3. **Commercial Intent of Typical Disposable Email Providers** * **Focus**: Targeting providers driven by ad revenue, facilitating spam/abuse. * **Gmail and ProtonMail's Model**: User-centric, not primarily ad-driven. 4. **Domain Limitations** * **Effectiveness**: Limited domain offerings by Gmail and ProtonMail make them less susceptible to misuse. * **Strategy**: Focusing on providers with extensive, rotating domain lists for more impactful filtering. 5. **Individual User Accountability** * **Accountability Measures**: Both services have mechanisms to penalize users violating terms, decreasing misuse risks.Summary and Next Steps
Including Gmail and ProtonMail does not align with our criteria for identifying disposable email services. Our aim is to target services significantly contributing to online spam and abuse, without impacting legitimate email services. We have reviewed your list and agree on adding some providers, like internxt.com (Reference). We will also incorporate the obvious choices from the tail of your list. We apologize for the delay in addressing this issue but intend to promptly resolve it by focusing on the most impactful additions.
it’s its strenth that decreased
Maybe he automated it?
Noone noticed because noone reads the articles.
We really need an autodr bot that justs pastes the text verbatim like:
This is the best copy I could come up with:
[…]
The original article contains 568 words, the copy also contains 568 words. Saved 0%. I’m a bot and I’m open source!