5
submitted 2 months ago* (last edited 2 months ago) by eth0p@iusearchlinux.fyi to c/thelyricsgame@lemmy.ca

Solved by @MumboJumbo@lemmy.world.

Since this might be a bit difficult based on how generic it is, here's a hint: that sand isn't supposed to be sand

[-] eth0p@iusearchlinux.fyi 31 points 2 months ago

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.

2
Everlong - Foo Fighters (iusearchlinux.fyi)
submitted 2 months ago* (last edited 2 months ago) by eth0p@iusearchlinux.fyi to c/thelyricsgame@lemmy.ca
12
[Solved] Clocks - Coldplay (iusearchlinux.fyi)
submitted 2 months ago* (last edited 2 months ago) by eth0p@iusearchlinux.fyi to c/thelyricsgame@lemmy.ca

@JackGreenEarth@lemm.ee solved this one.

8
[Solved] Desert Rose - Sting (iusearchlinux.fyi)
submitted 2 months ago* (last edited 2 months ago) by eth0p@iusearchlinux.fyi to c/thelyricsgame@lemmy.ca

@Lemmeenym@lemm.ee figured it out.

[-] eth0p@iusearchlinux.fyi 51 points 4 months ago

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 20 points 10 months ago

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.

33
submitted 11 months ago* (last edited 11 months ago) by eth0p@iusearchlinux.fyi to c/syncforlemmy@lemmy.world

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

[-] eth0p@iusearchlinux.fyi 31 points 11 months ago

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?

[-] eth0p@iusearchlinux.fyi 36 points 11 months ago* (last edited 11 months ago)

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!

[-] eth0p@iusearchlinux.fyi 19 points 11 months ago

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

[-] eth0p@iusearchlinux.fyi 19 points 11 months ago

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

[-] eth0p@iusearchlinux.fyi 75 points 11 months ago

Having thought about it for a bit, it's possible for this proposal to be abused by authoritarian governments.

Suppose a government—say, Wadiya—mandated that all websites allowed on the Wadiyan Internet must ensure that visitors are using a list of verified browsers. This list is provided by the Wadiyan government, and includes: Wadiya On-Line, Wadiya Explorer, and WadiyaScape Navigator. All three of those browsers are developed in cooperation with the Wadiyan government.

Each of those browsers also happen to send a list of visited URLs to a Wadiyan government agency, and routinely scan the hard drive for material deemed "anti-social."

Because the attestations are cryptographically verified, citizens would not be able to fake the browser environment. They couldn't just download Firefox and install an extension to pretend to be Wadiya Explorer; they would actually have to install the spyware browser to be able to browse websites available on the Wadiyan Internet.

[-] eth0p@iusearchlinux.fyi 12 points 11 months ago

Frankly, I don't trust that the end result won't hurt users. This kind of thing, allowing browser environments to be sent to websites, is ripe for abuse and is a slippery slope to a walled garden of "approved" browsers and devices.

That being said, the post title is misleading, and that was my whole reason to comment. It frames the proposal as a direct and intentional attack on users ability to locally modify the web pages served to them. I wouldn't have said anything if the post body made a reasonable attempt to objectively describe the proposal and explain why it would likely hurt users who install adblockers.

[-] eth0p@iusearchlinux.fyi 12 points 11 months ago* (last edited 11 months ago)

I suspect to get downvotes into oblivion for this, but there's nothing wrong with the concept of C2PA.

It's basically just Git commit signing, but for images. An organization (user) signs image data (a commit) with their public key, and other users can check that the image provenance (chain of signed commits) exists and the signing key is known to be owned by the organization (the signer's public key is trusted). It does signing of images created using multiple assets (merge commits), too.

All of this is opt-in, and you need a private key. No private key, no signing. You can also strip the provenance by just copying the raw pixels and saving it as a new image (copying the worktree and deleting .git).

A scummy manufacturer could automatically generate keys on a per-user basis and sign the images to "track" the creator, but C2PA doesn't make it any easier than just throwing a field in the EXIF or automatically uploading photos to some government-owned server.

[-] eth0p@iusearchlinux.fyi 48 points 11 months ago

Aw. I was going to post the link to his video, but you beat me to it.

But yeah, Technology Connections makes some excellent and informative videos. To anyone else who sees this: If heat pumps, refrigeration, or climate control technology aren't your cup of tea, he also covers older technology based around electromechanical designs (as in, pre-dating microcontrollers and programmable logic) and analog media recording devices.

[-] eth0p@iusearchlinux.fyi 13 points 11 months ago* (last edited 11 months ago)

I glossed through some of the specifications, and it appears to be voluntary. In a way, it's similar to signing git commits: you create an image and chose to give provenance to (sign) it. If someone else edits the image, they can choose to keep the record going by signing the change with their identity. Different images can also be combined, and that would be noted down and signed as well.

So, suppose I see some image that claims to be an advertisement for "the world's cheapest car", a literal rectangle of sheet metal and wooden wheels. I could then inspect the image to try and figure out if that's a legitimate product by BestCars Ltd, or if someone was trolling/memeing. It turns out that the image was signed by LegitimateAdCompany, Inc and combined signed assets from BestCars, Ltd and StockPhotos, LLC. Seeing that all of those are legitimate businesses, the chain of provenance isn't broken, and BestCars being known to work with LegitimateAdCompany, I can be fairly confident that it's not a meme photo.

Now, with that being said...

It doesn't preclude scummy camera or phone manufacturers from generating identities unique their customers and/or hardware and signing photos without the user's consent. Thankfully, at least, it seems like you can just strip away all the provenance data by copy-pasting the raw pixel data into a new image using a program that doesn't support it (Paint?).

All bets are off if you publish or upload the photo first, though—a perceptual hash lookup could just link the image back to original one that does contain provenance data.

view more: next ›

eth0p

joined 1 year ago