I have a 7950X, a pile of RAM, and an unfairly expensive RTX 4000-series GPU. The cursor occasionally hitches for ~400ms whenever doing things like opening task manager or resuming from the lock screen, so that checks out unfortunately.

The problem with a common UA string is that you would know the request came from someone browsing Lemmy with Sync. Ideally, media requests to any third party should be indistinguishable from a regular web browser. As for empty strings: in my experience, some websites block requests with an empty or missing User-Agent header.

I still think the best approach would be to let the user pick a UA. Having a list of common browser/device pairs that update the version numbers automatically would probably be a good idea, though.

The image needs to have already been downloaded the moment the client even fetches it, or you can use the image to track of a particular user is online/has read the message.

Oh wow… That’s an excellent point. And even if the client downloads it the moment it fetches the message, that would still be enough to help determine when somebody is using Lemmy. I don’t think advertisers would have a reason to do that¹, but I wouldn’t put it past a malicious individual to use it to create a schedule of when somebody else is active.

¹ It’s probably easier for them to host their own instance and track the timestamp of when somebody likes/dislikes comments and posts since that data is shared through federation.

This needs to be implemented in the backend. Images already get downloaded to and served from the server’s pictr-rs store in some instances, so there’s code to handle this problem already.

That would be ideal, I agree. This comment on the GitHub issue explains why some instances would want the ability to disable it, though. If it does eventually get implemented, having Sync as a fallback for instances where media proxying is disabled would be a major benefit for us Sync users.

A small side note: that comment also points out a risk of a media proxy running the risk of downloading illegal media. I don’t necessarily think lj would need to worry about it in the same way, though. From my understanding, the risk with that is that an instance would download the media immediately after receiving a local or federated post pointing it. An on-demand proxy would (hopefully) not run the same risk since it would require action (or really bad timing) on the part of a user.

On the other hand, such a system would also pose a privacy problem: suppose someone foolishly believes Lemmy’s messaging feature is secure and sends a message with personal pictures (nudes, medical documents, whatever). Copying that data around to other servers probably isn’t what you want.

Fair, but it’s a bit of a moot point. Sending the message between instances is already copying that data around, and even if it’s between two users of a single instance, it’s not end-to-end encrypted. Instance admins can see absolutely everything their users do.

Orbot can do per-app VPNs for free if you’re willing to take the latency hit.

Interesting! I wasn’t aware that there were any Android VPNs capable of doing per-app tunneling.

Ideally, yeah.

I’m not confident that instances would actually enable image proxying, though. The bandwidth for that costs money, and instances don’t necessarily have a consistent revenue stream that would make it feasible to run a proxy in addition to hosting the instance itself.

With Sync Ultra being a subscription, I think it would be more viable for lj to maintain an image proxy for Ultra subscribers. And if Lemmy ever adds image proxying itself, the instance proxies could be used where available instead.

For spoofing the user agent, I still think that some level of obscurity could help. The IP address is the most important part, but when sharing an internet connection with multiple people, knowing which type/version of device would help disambiguate between people with that IP (for example, a house with an Android user and an iPhone user). I wouldn’t say not having the feature is a deal breaker, but I feel like any step towards making it harder to serve targeted ads is a good step.

Fair point on just using a regular VPN, but I’m hoping for something a bit more granular. It’s not that all traffic would need to be proxied, though. If I use some specific Lemmy instance or click on an image/link, that was my choice to trust those websites. The concern here is that simply scrolling past an embedded image will make a request to some third-party website that I don’t trust.

With regard to my examples, WEI provides full confidence and stability in identifying the browser.

Relying on detecting browsers by differentiating between their features and quirks involves on having a large suite of checks to run, some of which might become incorrect as browsers change over time. It’s a maintenance burden, to say the least.

In other posts, I’ve tried to point out how some of the articles and comments around WEI are more speculative than factual and received downvotes and accusations of boot-licking for it. Welcome to the club, I guess.

The speculation isn’t baseless, but I’m concerned about the lack of accurate information about WEI in its current form. If the majority of people believe WEI is immediately capable of enforcing web page integrity, share that incorrect fact around, and incite others, it’s going to create a very good excuse for dismissing all dissenting feedback of WEI as FUD. The first post linking to the GitHub repository brought in so many pissed off/uninformed people that the authors of the proposal actually locked the repo issues, preventing anyone else from voicing their concerns or providing examples of how implementing the specification could have unintended or negative consequences.

Furthermore, by highlighting the DRM and anti-adblock aspect of WEI, it’s failing to give proper attention to many of the other valid concerns like:

• Discrimination against older hardware/software that doesn’t support system-level environment integrity enforcement (i.e. Secure Boot)
• The ability for WEI to be used to discriminate between browsers and provide poor (or no) service to browsers not created by specific corporations.
• The possibility of WEI being used in a way to force usage of browsers provided by hostile vendors
• The ability for it to be used to lock out self-built browsers or forked browsers.
• The potential for a lack in diversity of attesters allowing for a cartel of attesters to refuse validation for browsers they dislike.

I very well could be wrong, but I think our (the public) opinions would have held more weight if they were presented in a rational, informed, and objective manner. Talking to software engineers as people generally goes down better than treating them like emotionless cogs in the corporate machine, you know?

Firefox will probably survive if they bow and add WEI support.

I can’t imagine Google, Microsoft, and Apple opening themselves up to further monopolization scrutiny by trying to keep attestation restricted to their own browsers on their own operating systems.

Self-built or community forks are probably screwed, though.

And here’s a concern about the decentralized-but-still-centralized nature of attesters:

From my understanding, attesting is conceptually similar to how the SSL/TLS infrastructure currently works:

• Each ultimately-trusted attester has their own key pair (e.g. root certificate) for signing.

• Some non-profit group or corporation collects all the public keys of these attesters and bundles them together.

• The requesting party (web browser for TLS, web server for WEI) checks the signature sent by the other party against public keys in the requesting party’s bundle. If it matches one of them, the other party is trusted. If it doesn’t, they are not not trusted.

This works for TLS because we have a ton of root certificates, intermediate certificates, and signing authorities. If CA Foo is prejudice against you or your domain name, you can always go to another of the hundreds of CAs.

For WEI, there isn’t such an infrastructure in place. It’s likely that we’ll have these attesters to start with:

• Microsoft
• Apple
• Google

But hey, maybe we’ll have some intermediate attesters as well:

• Canonical
• RedHat
• Mozilla
• Brave

Even with that list, though, it doesn’t bode well for FOSS software. Who’s going to attest to various browser forks, or for browsers running on different operating systems that aren’t backed by corporations?

Furthermore, if this is meant to verify the integrity of browser environments, what is that going to mean for devices that don’t support Secure Boot? Will they be considered unverified because the OS can’t ensure it wasn’t tampered with by the bootloader?

Adding another issue to the pile:

Even if it isn’t the intent of the spec, it’s dangerous to allow for websites to differentiate between unverified browsers, browsers attested to by party A, and browser attested to by party B. Providing a mechanism for cryptographic verification opens the door for specific browsers to be enforced for websites.

For a corporate example:

Suppose we have ExampleTechFirm, a huge investor in a private AI company, ShutAI. ExampleTechFirm happens to also make a web browser, Sledge. ExampleTechFirm could exert influence on ShutAI so that ShutAI adds rate limiting to all browsers that aren’t verified with ShutAI as the attester. Now, anyone who isn’t using Sledge is being given a degraded experience. Because attesting uses cryptographic signatures, you can’t bypass this user-hostile quality of service mechanism; you have to install Sledge.

For a political example:

Consider that I’m General Aladeen, the leader of the country Wadiya. I want to spy on my citizens and know what all of them are doing on their computers. I don’t want to start a revolt by making it illegal to own a computer without my spyware EyeOfAladeen, nor do I have the resources to do that.

Instead, I enact a law that makes it illegal for companies to operate in Wadiya unless their web services refuse access to Wadiyan citizens that aren’t using a browser attested to by the “free, non-profit” Wadiyan Web Agency. Next, I have my scientists create and release a renamed versions of Chromium and Firefox with EyeOfAladeen bundled in them. Those are the only two browsers that are attested by the Wadiyan Web Agency.

Now, all my citizens are being encouraged to unknowingly install spyware. Goal achieved!

Can’t have a runtime error if you don’t have a compiled binary *taps forehead*

(For the record, I say this as someone who enjoys Rust)

I hope you were being sarcastic, because, ideally, nobody implements this.

Good article. Not clickbait/ragebait, and it explains the specification simply and succinctly, while also demonstrating why it’s dangerous for the open web.

But the real questions is, can we change them?

Imagine this:

• Good thing → Zelda chest opening sound.
• Bad thing →The Office “Oh, god, please no.”
• User interaction → Honking goose.
• Log in → Futurama “Welcome to the world of tomorrow!”
• Log out →AOL “You’ve got mail”

I’m not a lawyer, nor do I have the full context of the legislation you’re quoting, but my interpretation of that paragraph is that it only applies to aircrafts that are carrying passengers.

. . . in the air space in possession of another, by a person who is traveling in an aircraft, is privileged . . .

You’re the one who does this for a hobby, though. I’m sure that you know the laws more than I do :)

Fair and respectable points, but I don’t think we’re going to see eye to eye on this. It seems like we have different priorities when it comes to reporting on issues.

Honestly, I don’t disagree with you in thinking that the ulterior motive of the proposal is to undermine user freedom, user privacy, and/or ad blockers. Given Google’s history with Manifest V3 and using Chrome’s dominance to force vendors to adopt out-of-spec changes to web standards (passive scroll listeners come to mind), it would be burying my head in the sand to expect otherwise. My issue here is with portraying speculation and personal opinions as objective truths. Even if I agree that a locked down web is the most likely outcome, it’s just not a fact until someone working on that proposal outright says it was their intent, or it actually happens.

That doesn’t mean I think we should ignore the Doomsday device factory until it starts creating Doomsday devices, either, though. Google will never outright state that is their goal to cripple adblockers or control the web, and if it comes to happen, they’ll just rely on corporate weasel words to claim that they never promised they wouldn’t. And since we can’t trust corporations to be transparent and truthful, we shouldn’t be taking their promises or claims at face value. You’re absolutely right about that.

Going back to reporting about this kind of stuff, though: It’s not wrong for the original post to look past the surface-level claims, or for people to point out the corporate speak and lack of commitment. If there’s a factory labeled “Not Doomsday Devices” that pinkie promises they aren’t building Doomsday devices, I definitely would want someone to bring attention to it. I just don’t think the right way to do it is with a pitchfork-wielding mob of angry citizens who were told the factory is unquestionably building anthrax bioweapons, however.

We don’t gain much from readers being told things that will worry them and piss them off. I mean—sure—there’s now more awareness about the issue. But it’s not actually all that constructive if they aren’t critically engaging with the proposal. Google and web standards committees aren’t going to listen to a bunch of angry Lemmy users reiterating the same talking points over and over. They’re just going to treat it as a brigade and block further feedback until people forget about it (which they did).

If the topic was broached in a balanced and accurate way that refrained from making conclusions before providing readers with the facts, there would be less knee-jerk reactions. Maybe this is just me being naive, but I think it’s more likely that Google would be receptive to well-thought-out, respectful criticism as opposed to a significant quantity of hostile accusations.

With that being said, I will concede that I overcorrected for the original post too much. I should have written a response covering the issue in a way that I found more ideal, rather than trying to balance out the bias from the original post. My goal was to point out the ragebait title and add missing information so readers could come to their own informed conclusions, not defend Google.

Would my government? Aladeen, 100%.
^{If that doesn’t make sense, it’s a reference to a movie.}

Did you read until the end, or was it more important to accuse me of either being stupid or a corporate shill? I have nothing against you, and I don’t see how it’s constructive to be hostile towards me.

I said that the proposal itself does not aim to be DRM or adblock repellent, and cited the text directly from the document. It’s possible that something got lost in communication, but that wasn’t me trying to suggest that we should just blindly trust that this proposal has the users’ best interests at heart, or that motivations behind creating it could never, ever be disingenuous.

Hell, I even made sure to edit my post to clarify how the proposal—if implemented—could be used to prevent ad blockers. The paragraphs right after the one you quoted say:

To elaborate on the consequences of the proposal…

Could it be used to prevent ad blocking? Yes. There are two hypothetical ways this could hurt adblock extensions:

1. As part of the browser “environment” data, the browser could opt to send details about whether built-in ad-block is enabled, any ad-block extensions are enabled, or even if there are any extensions installed at all.

Knowing this data and trusting it’s not fake, a website could choose to refuse to serve contents to browsers that have extensions or ad blocking software.

2. This could lead to a walled-garden web. Browsers that don’t support the standard, or minority usage browsers could be prevented from accessing content.

Websites could then require that users visit from a browser that doesn’t support adblock extensions.

Given Google’s history, the assertion made by the title isn’t wrong. That doesn’t mean that it’s objective and informative, however.

The title suggests that the intent is to create DRM for web pages and “make ad blockers near-impossible”. From an informational standpoint, it correctly captures the likely consequences that would occur should the proposal be implemented. What it (nor the post body) does not do is provide an explanation, information, or context to explain why the proposal demonstrates the claim that is being made.

The reader is not informed about Google’s history of trying to subvert ad blockers, nor are they shown how the proposal will lead to DRMed web pages and adblock prevention. The post is a reaction-inducing title followed by a link to a proposal and angry comments on GitHub. That’s not informative; that’s ragebait.

Suppose I give the post the benefit of the doubt, and consider the bar for being “informative” to be simply letting people know about something. It’s still not objective. I’m not saying the OP should support Google or downplay the severity of the proposal, but they could have got the same point across without including their own prejudices:

“Google engineers propose new web standard that would enable websites to prevent access from browsers running adblockers or website-altering extentions.”

For the record: I agree with what this post is trying to say. I just disagree with how it’s said. Lemmy isn’t hemorrhaging ad money, and it isn’t overwhelmingly noisy. We don’t need to bring over toxic engagement tactics to generate views.

Oh, for sure. When bullet point number one involves advertising, they don’t make it hard to see that the underlying motivation is to assist advertising platforms somehow.

I think this is an extremely slippery and dangerous slope to go down, and I’ve commented as such and explained how this sort of thing could end up harming users directly as well as providing ways to shut out users with adblocking software.

But, that doesn’t change my opinion that the original post is framed in a sensationalized manner and comes across as ragebaiting and misinforming. The proposal doesn’t directly endorse or enable DRMing of web pages and their contents, and the post text does not explain how the conclusion of adblockers being killed follows from the premise of the proposal being implemented. To understand how OP came to that conclusion, I had to read the full document, read the feedback on the GitHub issues, and put myself in the shoes of someone trying to abuse it. Unfortunately, not everyone will take the time to do that.

As an open community, we need to do better than incite anger and lead others into jumping to conclusions. Teach and explain. Help readers understand what this is all about, and then show them how these changes would negatively impact them.