AmbitiousProcess (they/them)

And even if it’s never political, so what?

Someone uses it to promote a dangerous supplement, with thousands of fake, AI-generated videos of people taking it without issues, and suddenly a bunch of people buy it, take it, and suffer severe consequences, or even die.

But good thing it’s not gonna manipulate who you’d vote for amirite? Totally harmless! /s

Well obviously they shouldn’t just ram it before even checking, but if someone goes up to it, sees nobody inside, knocks on the window, and nobody responds, they should absolutely have the ability to forcefully, even if it causes damage, move the car.

Whether that’s by ramming the tram itself into it (which I assume would require changes to the front for safety against damaging the tram itself) or by using some sort of tool that can push it (e.g. something that hooks onto the rails for grip and uses hydraulics to push the car out of the way), damage is acceptable if you decide your bad parking decisions are justified over every single tram rider’s ability to get around, and a ton of money spent to move your car.

Not controversial at all.

It’s already established law that firefighters can shatter the windows of your car and drag the fire hose through it if you park in front of a hydrant.

Usually because otherwise there wouldn’t be much space left for parking at all.

In some places, these trams are gonna run through every major route, leaving no room for parking on smaller streets, and barely any parking that isn’t next to tram rails on larger streets.

If you want to have both trams and cars, then depending on the city, you might have no choice but to put parking spots there given the size of the inner-city roads.

Partially. It’s more that Google’s overall architecture was better for security, inclusive of many different features.

You can find a big ass list here: https://grapheneos.org/faq#future-devices

Oh, of course the legislation is to blame for a lot of this in the end. I’m just saying that Discord could have already partnered with a number of identity verification services that do already have this infrastructure up and running, with standardized and documented ways to call their APIs to both verify and check the verification of a user.

At the end of the day, Discord chose to implement a convoluted process of having users email Discord, upload IDs, then have Discord pull the IDs back down from Zendesk and verify them, rather than implementing a system where users could have simply gone to a third-party verification website, done all the steps there, had their data processed much more securely, then have the site just send Discord a message saying “they’re cool, let 'em in”

In my opinion, they’re still somewhat at fault, because this was them failing to find and configure their software to work with a third-party identity provider who’s infrastructure was built to handle the security of sensitive information, and just choosing to use email through Zendesk because it was easier in the meantime. A platform that I should note has been routinely accessed again and again by attackers, not just for Discord, but for all sorts of other companies.

The main problem is that legislation like the Online Safety Act require some privacy protections, like not collecting or storing certain data unless necessary, but they don’t require any particular security measures to be in place. This means that, theoretically, nothing stops a company from passing your ID to their servers in cleartext, for example.

Now compare this to industries like the credit card industry, where they created PCI DSS, which mandates specific security practices. This is why you don’t often see breaches of any card networks or issuers themselves, and why most fraud is external to the systems that actually process payments through these cards. (e.g. phishing attacks that get your card info, or a store that has your card info already getting hacked)

This is a HUGE oversight, and one that will lead to things like this happening over and over unless it becomes unprofitable for companies to not care.

Bitcoin bros actually did this at one point by making a space heater that was also a Bitcoin miner.

You get heat at similar energy efficiency to just running a regular space heater, but it pays back part of the energy bill with Bitcoin it mines. You could see how this could probably be adapted to other things, like what’s mentioned in the article (distributed cloud compute).

The main issue is that space heaters and other in-home heat generation units are still infinitely less efficient than things like heat pumps in many circumstances, since those can reach over 100% efficiency since they only transfer heat, rather than having to generate it from scratch.

These were images of people’s ID’s, along with photos of their faces to check for a match, not stock photos or even just real selfies on their own.

These were photos submitted via the compromised support provider (Zendesk) via the Discord support portal.

Automated age verification via their partner (k-ID, which has its own issues) is a separate system, which was only available to some users. Other users had to contact Discord support manually and submit photo ID, which went through Zendesk, which was then compromised in this breach.

https://support.discord.com/hc/en-us/articles/360041820932-Help-I-m-old-enough-to-use-Discord-in-my-country-but-I-got-locked-out

Additionally, for the automated process, it’s the video selfie that’s on-device and never transmitted, but photos of your ID and selfie photo are transmitted, just supposedly deleted afterwards. Those ones are *not included in this breach, as far as we’re aware, as it’s an entirely different third-party with wholly separate infrastructure.

The fact the cancellation page has been seen crashing multiple times, and that so many people are actively posting screenshots of their cancellation does lend credibility to the fact that it’s still happening on a large scale, though.

There’s only a few use cases where I’ve found I prefer it to doing things the hard way.

• As a thesaurus, since it’s great for going “what’s that one word that sort of means all encompassing, commonly used in reference to research/studies?” and it’ll end up giving me “holistic.”
• As part of other software, such as how Linkwarden automatically tags bookmarks by category when I add them
• Double checking the answers I’ve come up with in regard to hyper-specific questions (usually about how a given piece of software can/can’t be used, or how it’ll interact with something else) just to make sure I’m not blatantly missing anything.

However, I try to avoid using it for anything that otherwise requires productive mental effort, because I find that I end up being a lot more informed and capable if I spend 5 minutes going through sites, learning about a topic, identifying wrong answers, and being able to put together better new queries in the first place, than I do if I ask a chatbot, even if it pulls from those same sources.

When you have a chatbot summarize or combine/condense information, you’ll always lose nuance and additional context, and very frequently that context will actually be helpful to your overall understanding. There’s also many cases where, for example, someone on a forum explains an issue a bit, and their profile has more related information on it that an LLM simply wouldn’t go for, only summarizing from their one response on that page. This can lead me down a rabbit hole that then leads me to finding other good sources. Maybe someone mentions that a particular site is helpful for what I’m looking for, and that then becomes something I use more frequently when I do searches for things, whereas an LLM would have just ignored that comment.

However gmail is a large, incredibly well known service, and many sites understand that the + on gmail specifically is for subaddresses and will deny using the same email with subaddresses different times.

Contrast that with just using dashes like Port87, and most systems don’t have anything made to parse for dashes, as it could then result in problems where an email service like Gmail, or any other provider out there, allows people to put dashes in their base email, and someone can effectively block someone else from signing up for a service by making a new account named theirname-1, signing up, then the service would think that theirname-1 is also owned by theirname, and block theirname from signing up later.

The + is a relatively well known standard for email subaddressing, but dashes are primarily used by people just inside their email addresses instead of a space, for example. Thus, most server side implementations will never be configured to understand dashes as indicating a label, specifically for your domain, they’ll just see a large volume of constantly created new emails, that act like a temporary email service, and assume you’re one.

This has the same problem as before, where you’re not large enough to justify being specially considered by login pages that will understand what your labels are, but are also not going to get to that scale if you get filtered out as a temporary email service.

I’m probably going to stop responding now, as I think that’s about all I can contribute, but I’d just say that if this is the exact mechanism by which you plan to implement subaddressing, make sure you’re frequently checking any widely used blocklists online for temporary email domains, because someone will probably end up submitting your domain there at some point based on the behavior of the service, and it’s incredibly hard to get off once you’re on. (and consider making a page on the site explaining why you’re not a temporary email service, like SimpleLogin has)

but the fact that big companies definitely will block my domain if I do means it’s a no-go.

They’ll do that with your regular domain regardless if enough people start using it, which is why I’m concerned this might result in your entire primary domain being flagged as a temporary email service.

For example, there’s no distinction from the perspective of the service to a domain creating aliases that are per-account, entirely random each time, and a domain creating aliases that use a standard format of yourname-service, because at the end of the day, users can still make unlimited emails for a given service (e.g. yourname-1, yourname-2, yourname-3, and they all sign up for the same site)

The reason why SimpleLogin, now owned by Proton, doesn’t offer proton.me addresses, and the reason why Proton, Tuta, and other email providers all limit the number of aliases you can make with the base domain to a set amount, and for paid users only (e.g. Proton limits you to 15 total, and you can only delete and replace 1 per year), is because, for example, if everyone could make unlimited emails on proton.me, then proton.me would get flagged as a temporary email service.

I’m not saying I hate the idea at all, I love to see more competition and useful tools coming to the email space when so much of it is dominated by just Google and a few more privacy-focused providers like Tuta and Proton, but I’m worried this mechanism will just get you flagged as a temporary email service by companies, just like most of SimpleLogin’s domains were on many services by default. (though they’re still quite usable on 99% of the web)

From the perspective of sites these emails will be used on, there’s no difference between how your domain acts, and how a temporary email service does, because no system exists that is implemented by all these companies to specially identify emails from your domain, know they’re using “labels”, and filter out duplicate registrations accordingly.

To do so would require scale, but you probably won’t get scale unless you can avoid getting flagged as a temporary email service, which won’t happen unless those services all had such a system in place to the first place.

Even if they do, most people will use identifiable service names, so then you’d just have to brute force with yourname-google, yourname-facebook, yourname-lemmy, yourname-bank, etc. Still a major risk compared to traditional aliasing services in my opinion.

This is useful for preventing general spam and whatnot, but it suffers from the flaw that if you sign up for my service (or more likely, sign up for a service I later get access to a data breach from) using an email like yourname-myservice@port87.com, I can instantly know that your bare address is yourname@port87.com.

A system like SimpleLogin/Proton Pass Aliases would be much better, where addresses are truly unique, don’t leak your original email in their names, but can be applied to any domain (including custom subdomains).

This could either be on the main domain, or to prevent cramming, a secondary domain just for aliases.

the sticker, for anyone curious.

Great article, would highly recommend anyone with the time give it a full read through.

Wikipedia is incredibly valuable, and insanely well edited and put together, and we’re all lucky to have something like it available for free.

Even with Play Services enabled on GrapheneOS through Sandboxed Google Play, this wouldn’t affect it, as this would be a system-level change that only affects stock Android and OEM-modified variants of Android that are “Certified Android”

GrapheneOS would not have to put much, if any effort into blocking this.

Go to the Android developer verification site and fill out the Google Form in the bottom of the page on the right under Share your feedback.

Give any employees inside google that agree with you the materials they need to show management it’s unpopular even with developers, (even if you aren’t actually one) and give Google’s shareholders concern that this isn’t just media speculation, it’s real people with real concerns.