eth0p

joined 1 year ago
[–] eth0p@iusearchlinux.fyi 2 points 7 months ago (1 children)

If you happen to find any more, please let me know! I have a special place in my heart for the Oracle games, and I would love to play more games like them.

[–] eth0p@iusearchlinux.fyi 6 points 7 months ago* (last edited 7 months ago) (3 children)

I highly, highly recommend Prodigal. It's an absolute gem of a game if you're a fan of the Oracle games, and it's currently on sale too. It nailed the GBC art style and palette, and it has an interesting story full of mysteries.

There's also Beyond the Mountains, which is a passion project by a single developer. It's not as polished as one would hope, but it's free, and it's a fun game that can be completed in a couple of hours.

[–] eth0p@iusearchlinux.fyi 1 points 7 months ago

If that were the case, wouldn't the mouse jump when the latest frame is presented? For me, it's more that it just stays still until after Windows stops having a fuss.

[–] eth0p@iusearchlinux.fyi 31 points 7 months ago (4 children)

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.

[–] eth0p@iusearchlinux.fyi 2 points 7 months ago

This looks extremely familiar... do all universities do this?

[–] eth0p@iusearchlinux.fyi 51 points 9 months ago (1 children)

I went to one of their concerts, and their lead singer, David Draiman, was one of the most wholesome and honest guys I've ever seen. Funny headline, but I hope he recovers quickly and without any long-term effects.

[–] eth0p@iusearchlinux.fyi 4 points 1 year ago* (last edited 1 year ago) (1 children)

Unless something changed in the specification since I read it last, the attested environment payload only contains minimal information. The only information the browser is required to send about the environment is that: this browser is {{the browser ID}}, and it is not being used by a bot (e.g. headless Chrome) or automated process.

Depending on how pedantic people want to be about the definition of DRM, that makes it both DRM and not DRM. It's DRM in the sense that it's "technology to control access to copyrighted material" by blocking bots. But, it's not DRM in the sense that it "enables copyright holders and content creators to manage what users can do with their content."

It's the latter definition that people colloquially know DRM as being. When they're thinking about DRM and its user-hostility, they're thinking about things like Denuvo, HDCP, always-online requirements, and soforth. Technologies that restrict how a user interacts with content after they download/buy it.

Calling web environment integrity "DRM" is at best being pedantic to a definition that the average person doesn't use, and at worst, trying to alarm/incite/anger readers by describing it using an emotionally-charged term. As it stands right now, once someone is granted access to content gated behind web environment integrity, they're free to use it however they want. I can load a website that enforces WEI and run an adblocker to my heart's content, and it can't do anything to stop that once it serves me the page. It can't tell the browser to disable extensions, and it can't enforce integrity of the DOM.

That's not to say it's harmless or can't be turned into user-hostile DRM later, though. There's a number of privacy, usability, ethical, and walled-garden-ecosystem concerns with it right now. If it ever gets to widespread implementation and use, they could later amend it to require sending an extra field that says "user has an adblocker installed". With that knowledge, a website could refuse to serve me the page—and that would be restricing how I use the content in the sense that my options then become their way (with disabled extensions and/or an unmodified DOM) or the highway.

The whole concept of web environment integrity is still dubious and reeks of ulterior motives, but my belief is that calling it "DRM" undermines efforts to push back against it. If the whole point of its creation is to lead way to future DRM efforts (as the latter definition), having a crowd of people raising pitchforks over something they incorrectly claim it does it just gives proponents of WEI an excuse to say "the users don't know what they're talking about" and ignore our feedback as being mob mentality. Feedback pointing out current problems and properly articulating future concerns is a lot harder to sweep under the rug.

[–] eth0p@iusearchlinux.fyi 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] eth0p@iusearchlinux.fyi 2 points 1 year ago* (last edited 1 year ago)

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^1^, but I wouldn't put it past a malicious individual to use it to create a schedule of when somebody else is active.

^1^ 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.

[–] eth0p@iusearchlinux.fyi 20 points 1 year ago (4 children)

Thank you for making an informative and non-alarmist website around the topic of Web Environment Integrity.

I've seen (and being downvoted for arguing against) so many articles, posts, and comments taking a sensationalized approach to the discussion around it, and it's nice to finally see some genuine and wholly factual coverage of it.

I really can't understate how much I appreciate your efforts towards ethical reporting here. You guys don't use alarm words like "DRM," and you went through the effort of actually explaining both what WEI does and how it poses a risk for the open web. Nothing clickybaity, ragebaity, and you don't frame it dishonesty. Just a good, objective description of what it is in its current form and how that could be changed to everything people are worried about.

Is there anything that someone like me could help contribute with? It seems like our goals (informing users without inciting them, so they can create useful feedback without FUD and misinformation) align, and I'd love to help out any way I can. I read the (at the time incomplete) specs and explainer for WEI, and I could probably write a couple of paragraphs going over what they promised or omitted. If you check my post history, I also have a couple of my own example of how the WEI spec could be abused to harm users.

[–] eth0p@iusearchlinux.fyi 3 points 1 year ago* (last edited 1 year ago)

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.

[–] eth0p@iusearchlinux.fyi 3 points 1 year ago (3 children)

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.

 

A recent post at Lemmy.ml pointed out that images are loaded directly by Lemmy clients, and aren't proxied through any instances.

This has some implications for targeted advertising and tracking. For example, if I ran an ad network, I could post a benign-looking comment that has a tracking pixel embedded as an image. Say I posted one on a Lemmy post about cooking: when a user scrolls near that comment, the image would get loaded and I would be given an association between an IP address and device type → some interest. If not many people use that IP and device type tuple, I could determine that you were interested in cooking and try to serve you ads for kitchenware.

Adding the option to specify the HTTP user agent when viewing images (or better yet, randomize it between a bunch of valid ones) would be a nice option for privacy-conscious users who don't want advertisers (or websites collecting HTTP request data to sell to advertisers) to be able to build profiles on them.

If you wanted to add extra value to Sync Ultra, you could even offer image proxying as one of its features :)

Edit: According to this comment, the regular Lemmy website will load embeds for direct messages. If that's also true for Sync, it means someone could find your IP address by just sending you a message with an embed. That has some even bigger privacy implications.

Edit: Sync doesn't embed the image, but it loads it to display a thumbnail:
Screenshot of my inbox showing a thumbnail of the image

view more: next ›