Composable moderation/custom labeling and custom algorithmic feeds are two things that Mastodon doesn’t have that Bluesky does.

Isn’t the main problem that most people don’t use the E2E encrypted chat feature on Telegram, so most of what’s going on is not actually private and Telegram does have the ability to moderate but refuses to (and also refuses to cooperate)?

Something like Signal gets around this by not having the technical ability to moderate (or any substantial data to hand over).

Before people can be persuaded to use them, we have to persuade or force the companies and sites to support them.

A multi-billion dollar social media company sued an ad industry group that was trying to have help companies have some kind of brand safety standards to prevent a company’s ads from appearing next to objectionable content. They reportedly had two full-time staff members. This isn’t some big win, it’s bullying itself.

Basically with passkeys you have a public/private key pair that is generated for each account/each site and stored somewhere on your end somehow (on a hardware device, in a password manager, etc). When setting it up with the site you give your public key to the site so that they can recognize you in the future. When you want to prove that it’s you, the website sends you a unique challenge message and asks you to sign it (a unique message to prevent replay attacks). There’s some extra stuff in the spec regarding how the keys are stored or how the user is verified on the client side (such as having both access to the key and some kind of presence test or knowledge/biometric factor) but for the most part it’s like certificates but easier.

With a breach of this size, I think we’re officially at the point where the data about enough people is out there and knowledge based questions for security should be considered unsafe. We need to come up with different authentication methods.

The plan was only to kill off third-party cookies, not first-party so being able to log into stuff (and stay logged in) was not going to be affected. Most other browsers have already blocked or limited third-party cookies but most other browsers aren’t owned by a company that runs a dominant ad-tech business, so they can just make those changes without consulting anyone.

Also, it looks like there might be some kind of standard for federated login being worked on but I haven’t really investigated it: https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API

They definitely knew it would impact their ad business but I think what did it was the competition authorities saying they couldn’t do it to their competitors either, even if they were willing to take the hit on their own services.

Impact on their business (bold added): https://support.google.com/admanager/answer/15189422

• Programmatic revenue impact without Privacy Sandbox: By comparing the control 2 arm to the control 1 arm, we observed that removing third-party cookies without enabling Privacy Sandbox led to -34% programmatic revenue for publishers on Google Ad Manager and -21% programmatic revenue for publishers on Google AdSense.
• Programmatic revenue impact with Privacy Sandbox: By comparing the treatment arm to control 1 arm, we observed that removing third-party cookies while enabling the Privacy Sandbox APIs led to -20% and -18% programmatic revenue for Google Ad Manager and Google AdSense publishers, respectively.

For scenario one, they totally need to delete the data used for age verification after they collect it according to the law (unless another law says they have to keep it) and you can trust every company to follow the law.

For scenario two, that’s where the age verification requirements of the law come in.

No, no, no, it’s super secure you see, they have this in the law too:

Information collected for the purpose of determining a covered user’s age under paragraph (a) of subdivision one of this section shall not be used for any purpose other than age determination and shall be deleted immediately after an attempt to determine a covered user’s age, except where necessary for compliance with any applicable provisions of New York state or federal law or regulation.

And they’ll totally never be hacked.

From the description of the bill law (bold added):

https://legislation.nysenate.gov/pdf/bills/2023/S7694A

To limit access to addictive feeds, this act will require social media companies to use commercially reasonable methods to determine user age. Regulations by the attorney general will provide guidance, but this flexible standard will be based on the totality of the circumstances, including the size, financial resources, and technical capabilities of a given social media company, and the costs and effectiveness of available age determination techniques for users of a given social media platform. For example, if a social media company is technically and financially capable of effectively determining the age of a user based on its existing data concerning that user, it may be commercially reasonable to present that as an age determination option to users. Although the legislature considered a statutory mandate for companies to respect automated browser or device signals whereby users can inform a covered operator that they are a covered minor, we determined that the attorney general would already have discretion to promulgate such a mandate through its rulemaking authority related to commercially reasonable and technologically feasible age determination methods. The legislature believes that such a mandate can be more effectively considered and tailored through that rulemaking process. Existing New York antidiscrimination laws and the attorney general’s regulations will require, regardless, that social media companies provide a range of age verification methods all New Yorkers can use, and will not use age assurance methods that rely solely on biometrics or require government identification that many New Yorkers do not possess.

In other words: sites will have to figure it out and make sure that it’s both effective and non-discriminatory, and the safe option would be for sites to treat everyone like children until proven otherwise.

Doesn’t necessarily need to be anyone with a lot of money, just a lot of people mass reporting things combined with automated systems.

I’m pretty sure the main picture on the article is what the revised opt in/out message looks like. Previously it was opt in with just a message describing the feature with a check box to have it open Settings when you were finished with the out of box experience so that you can look at the options later.

https://support.google.com/maps/answer/14169818

Update Google Maps to use Timeline on your device

Important: These changes are gradually rolling out to all users of the Google Maps app. You’ll get a notification when an update is available for your account.

Location History is now called Timeline, and you now have new choices for your data. To continue using Timeline, you must have an up-to-date version of the Google Maps app. Otherwise, you may lose data and access to your Timeline on Google Maps.

Timeline is created on your devices.

Basically they’re getting rid of the web version because they’re moving the data to being stored on local devices only. Part of this might be because they got a lot of flak for stuff like recording location data for people who went near reproductive health clinics and other sensitive things. They can’t be forced to respond to subpoenas for data if they don’t have the data and can thus stay out of it, so I wouldn’t necessarily say it’s all that altruistic on their part.

Someone has already demonstrated using an off-the-shelf infostealer to steal the Recall database from a test computer. It won’t take any special skills or technology for this to be a problem.

I feel like even if it was open-source, it would still be too big of a target for malware and data exfiltration to ever be justified for most people.

It’s always been a possibility that someone could do this but this makes it a default on feature for a lot of users you might interact with and makes them a prime target for malware to steal the sensitive data that wouldn’t have existed in most cases before.

To protect against casual theft of a device causing the data to be in the thief’s hands in addition to the actual device.

The average person unfortunately is not likely to properly backup their encryption keys so if they forget their password (or don’t use one and rely on the default of just TPM), they’ll complain about losing their data. Having the key backed up gives them a way to get their data back in non-theft situations.

A keylogger isn’t retroactive to before the keylogger was installed though. Recall is. Also, with Recall you don’t need to write keylogging software and get it past antimalware scans (and keep it from getting detected), you just have to get an infostealer past them one single time to take the Recall database.

https://blog.mozilla.org/addons/2024/05/14/manifest-v3-updates/

We also wanted to take this opportunity to address a couple common questions we’ve been seeing in the community, specifically around the webRequest API and MV2:

1. The webRequest API is not on a deprecation path in Firefox
2. Mozilla has no current plans to deprecate MV2 as mentioned in our previous MV3 update

That said, I believe Firefox users have gotten a lot of benefits by having extensions made that work in both Firefox and Chromium-based browsers. I don’t believe there will still be as much effort for a Firefox-only extension but I believe there will be a sufficient number of motivated users and developers to still develop blockers and other extensions that take advantage of Firefox continuing to support MV2 and webRequest.