Spotlight7573 @ Spotlight7573 @lemmy.world

Posts

7

Comments

265

Joined

2 yr. ago

By the repeat infringer policy, I was generally talking about multiple infringing uploads, not just a single video over time. Apologies for the confusion.

One of the nice things about the DMCA for the average user is that it's generally on the copyright holder to notice infringing content is out there and demand that it be taken down, instead of forcing some kind of pre-upload approval system that would never scale to the amount of content that is being uploaded daily.

I totally think it's unfair too though, just trying to point out how the law currently works. I feel it's ridiculous that something could have been created before you were born, you live to a very full life expectancy, and by the time you die the work still hasn't entered into the public domain. That does not feel like copyright is for a "limited time".

The problem is there's the statutory notice and takedown then counter-notice then lawsuit process that must be followed. There is also a requirement to have a policy to deal with repeat infringers and that doesn't really have an 'only for new content' exception as it's generally all still under copyright. If Google doesn't follow those requirements, they can be found liable for the copyright violations instead of being covered under the safe harbor. No business is going to want to open themselves up to that kind of potential liability for all the thousands of hours of videos they get a day.

That said, the whole ContentID and non-DMCA copyright process they have is on them, as that part is voluntary (to some extent, they got pressured by the music industry and friends).

The problem I see, is that it wouldn't actually be more money for the creators despite there being more ads as the user base actually seeing the ads is reduced and the difference has to be made up in volume.

From my understanding, they embed the ad in the video stream itself so that it's indistinguishable from the actual content. I imagine Google could serve ads from the same servers that serve videos and integrate them in a way that would be hard to detect, just like Twitch.

Strictly speaking, isn't that exactly how the DMCA is designed to work? Aren't they technically violating it anytime they actually review something manually and decide to ignore a DMCA notice? I don't think how Google responds to DMCA notices has really been tested with respect to keeping their safe harbor protections.

In order to know that you are talking to the right website on the web, you need someone else that you trust to say they are who they say they are. That is a Certificate Authority. They verify that the example.com you are talking to is the actual example.com through math that's hard to fake. Currently, the process of performing this verification can be either done manually by a person or automatically through software depending on what the Certificate Authority supports. Chrome is planning on changing their policy to require that an automatic option be available for all Certificate Authorities, without necessarily taking away the manual option from those who still want to use it.

https://lemmy.world/modlog?page=1&userId=458302

reason: article date is older than 14 days

reason: not recent (over 14 days)

I'm assuming those are the posts. For some reason they don't show up at the world news specific log:

https://lemmy.world/modlog/1322?page=1&actionType=All&userId=458302

You can set Firefox to just do that for everything:

https://support.mozilla.org/en-US/kb/https-only-prefs

Chrome has a similar option here:

https://support.google.com/chrome/answer/10468685#https-only-mode

Looks like it just concatenates them:

The shared secret is calculated as the concatenation of the X25519 shared secret (32 bytes) and the Kyber768Draft00 shared secret (32 bytes). The resulting shared secret value is 64 bytes in length.

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html>

The problem is people you know may still have social media and they can tag you or include your info in the descriptions, even if you don't have a profile. Companies collecting this info from social media can totally build a shadow profile if they want, especially if they've got like 5 photos that have a matching face and the description has the same tag or name in it.

Regarding the DMV thing, it looks like they don't sell the photos but do sell other data that may be useful in cross-referencing things: https://www.vice.com/en/article/43kxzq/dmvs-selling-data-private-investigators-making-millions-of-dollars

Amassing a huge dataset to search through with all the metadata (usernames, names, etc) is the part than an individual would probably have trouble with doing, not the actual "is this a photo of the person in this other photo" part.

The lies you are able to generate will likely never outweigh all of the accurate data other people create and definitely won't remove it, just add some noise.

It doesn't even have to be your friends. It could just be you walking by in the background of a photo someone else took.

Yeah, I feel like it's going to take both browser vendors shaming sites once a standard is developed/finalized and something like a quantum version of whynohttps.com to drive adoption.

The problem really is the store and decrypt nature of it. It could be used against old data so the time when it needs to be implemented is before it becomes possible to decrypt. I feel like people aren't good about planning like that and tend to be more reacting to what is currently possible.

Considering this proposal is used for the key exchange, they definitely need to update both the client side and server side part to be able to make use of it. That's the kind of thing that may take years but luckily it can fall back to older methods.

It also needs to be thoroughly vetted so that's why it's a hybrid approach. If the quantum resistant algorithm turns out to have problems (like some others have), they're still protected by the traditional part like they would have been, with no leaking of all the data.

Currently being investigated by browser makers but not something they can just do on their own like Signal.

Here's Chromium's current proposal that they're testing:

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

Don't forget the part where they can come up with probable cause for the arrest after the fact.

Is it set to just unspecified? You can select more than one language (or all of them). I'm thinking you might not have English selected.

Can you see my other comment replying to your comment in this post?

It looks like on the post you originally referenced there are 4 with language unspecified and the rest are all tagged as English.

Are you able to see this post?

https://github.com/uazo/bromite-buildtools/issues/59

issue poster: if it's possible for you, to release 32-bit build

uazo: no, see #41

https://github.com/uazo/bromite-buildtools/issues/41

issue poster: can you please also build arm-v7 version of current Bromite?

uazo: no, sorry. my current build system does not allow this due to an issue in sysbox

Edit: also:

https://github.com/uazo/cromite/issues/146

uazo: sysbox does not support 32-bit applications in 64-bit containers. the build without it works (as I think you did), but my server runs with sysbox.