Fall of github

Well, as we know, now it's microsoft github, and that's enough reason not to use github. youtube-dl got deleted from github because of the broken copyright laws in the USA (RIAA sent a DMCA takedown to youtube-dl for some reason) youtube-dl does not break the copyright laws in any way, it only provides way to download youtube videos, nothing else. but if you ban youtube-dl because you can use it to download copyrighted things, then we should also ban web browsers, because the allow us to watch copyrighted material, and media players Not to mention github literally does not work in Pale Moon, because of the JS masturbation it has. >Alternative? Git was made to be decentralized, but github literally centralized it. And there's no federated git web interfaces instances. The most close thing we have to that is everyone using their own gitweb instances, and mailing lists (which would replace issues and pull requests, you would send the diffs on the mailing list) But since that's never going to happen (I wish it did though) what we can do is to use, for example, https://codeberg.org, which is a gitea installation which claims to respect privacy >inb4 gitlab gitlab is as harmful as github, everyone probably uses gitlab.com, a cloudflare website, which won't work without JavaScript

I thought someone mentioned in another thread that there's an option to do issue trackers and the like over activitypub. I believe gitlab devs were looking into it? That would be good enough for me. If I had a project complex enough to necessitate a full issue tracker I'd just self host gitlab or something else that can federate with it.

Lurk more, theres like 2-3 threads specifically about this.

>>34961 there are 2-3 threads about other things that have been co-opted to talk about this. i'm happy someone created this one. >>34954 the fact that you failed to make this a thread is some kind of divine intervention. god is telling you to post in either the tech questions thread, the bsd thread, or the distro rec thread.

Apart from self-hosting your git instance, you can also use decentralized remote helpers like GitTorrent or git-remote-ipfs. While the latter one is still updated, GitTorrent is practically dead at this point. I hope more alternatives will spring up in response to the recent youtube-dl takedown. https://github.com/dhappy/git-remote-ipfs https://github.com/cjb/GitTorrent

>>34969 devuan is good. The netinstall is better than the gui install imo and if u have issues with wireless u just need to put the driver files for ur wireless card on the root of ur usb.

>>34969 Devuan is the first non-systemd flavor I actually enjoyed. All my packages are in the official repository which is always great. There have only been one or two packages that I had to compile from source (i.e dmenu) Here's a head start if you've never used debian/openrc before # Inherit the root users $PATH su - # Stop/Start/Restart a service rc-service SERVICE [start|stop|restart] # View services that start at runtime rc-update # Adding/removing services to start at runtime rc-update [add|del] SERVICE All services are stored as shell scripts in /etc/init.d/ Another way of starting a service would be /etc/init.d/lightdm start

>>34954 >youtube-dl does not break the copyright laws in any way, it only provides way to download youtube videos, nothing else. Did you not read the DMCA document? Please do read about the source before making such claims about it. They explain why they believe it breaks the copyright laws, which is different to what your are arguing they didn't do. >https://web.archive.org/web/20203133769069/https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md It probably does break copyright act laws. It circumvent's YouTube's (et al) digital protections that make you watch an ad before allowing you to view a video. That's how RIAA can make money while having their songs and videos including their songs free to play. >As there, the youtube-dl source code available on Github (which is the subject of this notice) circumvents YouTube’s rolling cipher to gain unauthorized access to copyrighted audio files, in violation of YouTube’s express terms of service,3 and in plain violation of Section 1201 of the Digital Millennium Copyright Act, 17 U.S.C. §1201. >Indeed, the comments in the youtube-dl source code make clear that the source code was designed and is marketed for the purpose of circumventing YouTube’s technological measures to enable unauthorized access to our member’s copyrighted works, and to make unauthorized copies and distributions thereof: they identify our member’s works, they note that the works are VEVO videos (virtually all of which are owned by our member companies), they acknowledge the those works are licensed to YouTube under the YouTube standard license, and they use those examples in the source code to describe how to obtain unauthorized access to copies of our members’ works. There is clear intent of them circumventing a feature made to block unauthorized access to the video and audio files. It's not that you are accessing copyrighted content, it's that the tool has clear intent to circumvent security measures to gain unauthorized access to content. The DMCA complaint against youtube-dl is not an issue with GitHub. It's an issue of any host that is at risk of being sued for illegal code. Your other points about MS ownership and partial JS reliance are still valid though. >>inb4 gitlab >gitlab is as harmful as github, everyone probably uses gitlab.com Except that's not true. I do not use gitlab myself, nor do I recommend it due to requiring JavaScript and yes that legitimate annoys me. It is harmful. But I rarely ever see people use gitlab.com. Nearly all gitlab repos I have seen are self-hosted (lots of universities including mine had one, framasoft, Arch), with some exceptions like PostmarketOS. >Alternatives Many small service sites (like disroot, snopyta, nixnet.xyz and others) host public Gitea instances you can use. You can also host your own. (Gitea is a fork of Gogs, I think) There are also sites like notabug.org which host a version of Gogs.

This brings to mind a question, has the youtube-dl community decided upon an alternative non-US on which to continue development as usual?

>>34975 like bob page said, mathematically likely.

>>34974 youtube itself provides the 'security measure' which points to the content in plaintext to the client in the case of a browser, it is not an illegal access to the content

>>34976 What I meant is: I want to continue contributions, where has the community settled-on for setting my remote values properly?

>>34977 The DMCA complaint points to a Hamburg Regional Court decision which considered the YouTube rolling cipher an effective technological protection measure under EU law. I expect the US to agree. The rolling cipher is clearly intent on providing access control and it takes an intentional effort to exploit it. The fact that the end result is sent to you in plaintext is completely irrelevant. If I have an image hosting website and the admin login webpage source has a base64 encoded comment saying 'password is root', and you use that password to login and find and download unlisted images from users all over the website, that's illegal access. You circumvented access control to access the plaintext content. You figured out the password but that doesn't mean you have legal permission, it was clearly meant to keep you out, even it it did a soykaf job.

Nowhere yet. The net is full of mirrors right now, none of which is being officially used for development. The youtube-dl page (https://yt-dl.org/) will likely announce a different repository if GitHub takes their repo down for good. That is, if they decide to officially continue in development. However I don't see a reason why they would halt their development -- as far as I know, the RIAA sent a DMCA to GitHub, not to the youtube-dl project itself.

>>34982 Oops, I was replying to >>34980

>>34983 Something to keep on the lookout for then. I do hope that they'll continue development.

This is not a Github problem. This is a centralized services problem. Moving to Codeberg and calling it a day like that's going to fix anything is brain dead. How decentralized can you make things like the issue tracker and PR system? Would IPFS fold like a wet blanket if the RIAA started suing people hosting the content?

>>34982 >However I don't see a reason why they would halt their development -- as far as I know, the RIAA sent a DMCA to GitHub, not to the youtube-dl project itself. I mean, if they are in a country that respects American copyright law, it would be a risk to continue. Why would RIAA take action against the project on GitHub then just stop? Best course of action would be to have some anonymous person make an ""unofficial"" fork of it on a server hosted outside of US copyright influence (Russia, for example), then mention on the official site that you are aware that someone forked it and here's a link.

>>34985 Like I said, only way to do the decentralized git thing is for everyone to have their own gitweb/cgit instance and manage issues and pull requests in mailing lists.

>>34985

>>34987 >>34985 mentions the issue with that idea. The RIAA doesn't mind suing endless people individually, so IPFS or any other meshnet that doesn't include an anonymizing layer is a no-go.

> Git was made to be decentralized, but github literally centralized it. it's like saying gmail has literally centralized email. Even so, it doesn't change anything.

>>34949 >youtube-dl does not break the copyright laws in any way, it only provides way to download youtube videos, nothing else. but if you ban youtube-dl because you can use it to download copyrighted things, then we should also ban web browsers, because the allow us to watch copyrighted material, and media players nothing of value was lost https://gitlab.com/nephros/youtube-dl/-/tree/master https://codeberg.org/polarisfm/youtube-dl https://git.nixnet.xyz/Amolith/youtube-dl https://code.loranger.xyz/rob/youtube-dl https://git.hackers.town/The_gibson/youtube-dl2.git https://gitlab.com/nephros/youtube-dl https://salsa.debian.org/debian/youtube-dl https://gitee.com/mirrors/youtube-downloader https://git.marcg.pizza/~marcg/youtube-dl https://git.osuv.de/star/youtube-dl

EEE tactics

>>34985 >This is not a Github problem. Yes. >This is a centralized services problem. Not primarily. It's an OPSEC problem. Let's break this down: >youtube-dl allows you to do things YouTube's monetization model doesn't want. The project can and does impact YouTube's revenue and the revenue of industries using it (especially the music industry). >you could legally debate the project is a piracy tool. I believe many of the contributors have done so illegally, whether they know it or not. >the above points warrant operational security measures. There is incentive (money), capability (US international arts-industry legal teams and DMCA laws that can or do prohibit DRM evasion) and proximity (project hosted on US-respecting servers, most likely some major US contributors). This kind of thing was inevitable. As easy as it is to say in hindsight, they really should have seen some form of retaliation coming. There should be some operational security. Use a collaboration platform that is safe from US legal interference. Don't make yourself a target for copyright troll-types. Of course this may have lessened the amount of contributors by a small part, but it would have prevented this bullshit. But they won't learn from their mistake, will they? Nor will similar projects, right? Decentralization could certainly be a useful part of the OPSEC (e.g. if a cyber contractor is paid to hack the host or owner account, or if the centralized server's owner dies or gets sued or clicks ransomware) but it seems secondary to really basic stuff.

>>34993 [not them] I agree somewhat, but they won't be able to sue many Russians.

>>34949 >federated git This seems like it could be a legitimate GNU product >>34970 >https://github.com/dhappy/git-remote-ipfs Has anyone paired this with end-to-end encrypted git repos like Keybase does with remote helpers https://keybase.io/blog/encrypted-git-for-everyone >>34974 >They explain why they believe it breaks the copyright laws, which is different to what your are arguing they didn't do. not that lainon, but here's a short summary ytdl includes youtube links in their automated tests to make sure their code works Three links in the youtube.py file point to youtube pages featuring RIAA music videos ytdl does not distribute the content, only the links Links cannot be copyright The RIAA claims ytdl breaks DRM, it does not ytdl only extracts links, you cannot copyright links, see above for example, one of the links in question, you can see for yourself youtube-dl --skip-download --print-json https://www.youtube.com/watch?v=UxxajLWwzqY notice how you can grab the url out of the json data, load it up with wget, and download it directly it plays fine, because there IS NO DRM, it's not using EME in the browser Therefore, the RIAA cannot argue they own any part of the copyright in the repo Therefore, the RIAA cannot argue that the software breaks DRM Therefore, the RIAA must now argue that ytdl team is "inducing infringement" aka Grokster Three links in a automated test do not do that In fact, ytdl could distribute the copyright material as part of the test directly That would be considered fair use That is what has happened since 1973 with this particular copyright image, https://en.wikipedia.org/wiki/Lenna The RIAA has no case at all in this situation. Zero. Microsoft should know better and should have done better It is obvious that Microsoft is a bad steward for Github and Github is no longer a good place to host a project I say this as someone who opened my github account in their first year I'm a super old user on github with a great username and I'm packing my things right now to move out of there

GitHub has removed the youtube-dl repo after a complaint from the soykafheads from RIAA. https://www.bleepingcomputer.com/news/software/youtube-dl-removed-from-github-after-riaa-dmca-notice/ In response to this, someone hacked(?) the GitHub DMCA repo and replaced everything with the Youtube-dl source code: https://github.com/github/dmca/tree/416da574ec0df3388f652e44f7fe71b1e3a4701f See also https://yt-dl.org/ (official site) https://source.netsyms.com/Mirrors/youtube-dl (mirror of the source code) https://gitee.com/mirrors/youtube-downloader (mirror of the source code)

>>35130 >ytdl includes youtube links in their automated tests to make sure their code works >Three links in the youtube.py file point to youtube pages featuring RIAA music videos >ytdl does not distribute the content, only the links >Links cannot be copyright I agree. >The RIAA claims ytdl breaks DRM, it does not >ytdl only extracts links, you cannot copyright links, see above >for example, one of the links in question, you can see for yourself >youtube-dl --skip-download --print-json https://www.youtube.com/watch?v=UxxajLWwzqY >notice how you can grab the url out of the json data, load it up with wget, and download it directly >it plays fine, because there IS NO DRM, it's not using EME in the browser I am not convinced by this argument. - The DMCA states "No person shall circumvent a technological measure that effectively controls access to a work protected under this title". Whether the content distribution uses EME or other encryption is completely irrelevant and does not imply there is no DRM. - YouTube uses a rolling cipher to inhibit direct access of the underlying video files stored on YouTube’s servers. I argue that this is a technological measure that qualifies as access control to a copyrighted work. YouTube are making it so you need to crack a code to get that working direct download URL. - A decision in Hamburg similarly decided the YouTube rolling cipher qualified as an effective technical measure within the meaning of EU. I see no reason the US would disagree. - The production of that direct URL circumvents an access control measure. The link is not copyrighted, but the act of creating that URL is circumventing access control measures. However, Over at law.stackexchange.com, someone pointed out that: >Complainants are "confused" about actual infringement (which is prohibited by copyright law), and creating a method for infringing copyright. Under DMCA and US copyright law, copying is infringing, programming is not infringing. The complaint does not clearly allege unauthorized copying of another person's intellectual property, and their complaint is based on the theory that certain programming actions constitute copyright infringement. I don't actually think they are confused, I think they are testing the boundaries. So I may also be wrong that they have infringed copyright. They have created a method for infringing (so you downloading a VEVO video is infringement) but their code may be fine, depending on the court.... Also, fuarrrk GitHub. Thanks for moving away.

Anybody else getting BAD signature when verifying youtube-dl-2020.09.20.tar.gz ? The SHA256 hash doesn't match, either. This is all from the official site.

>>35131 >In response to this, someone hacked(?) the GitHub DMCA repo and replaced everything with the Youtube-dl source code: https://github.com/github/dmca/tree/416da574ec0df3388f652e44f7fe71b1e3a4701f This is the funniest and most awesome thing I've read all day.

>>35142 Someone on nano said that something is fishy with the youtube-dl binary from yt-dl.org

>>35158 >something is fishy with the youtube-dl binary from yt-dl.org What about it? It's identical to my pre-takedown copy.

>>35142 From https://yt-dl.org/download.html. youtube-dl-2020.09.20.tar.gz MD5: ce6abd9cc401d2c7d2bb855088d7447b SHA1: 2902fa18c30cc3851d5b7fc2932f3f986432b9ac SHA256: ac1a799cf968345bf29089ed2e5c5d4f4a32031625d808369e61b6362d1c7cde SHA512: ed511016d0cfcbbee0cd651f793cb31cdb46d80243f86186de1cc54cb2a2055fae2f5cc3e16f838fc2ba47f3ff6f3b484219c8a707904fbc30193a2b28a1e30c Good signature from ED7F 5BF4 6B3B BED8 1C87 368E 2C39 3E0F 18A9 236D (Sergey M. <dstftw@gmail.com>). The SHA256 hash is identical to the one specified in Arch's PKGBUILD. The SHA512 hash is identical to the one specified in Gentoo's Manifest.

>>35161 Interesting. The file I downloaded earlier is half the size of the new one. https://web.archive.org/web/20201024232002/http://abf-downloads.openmandriva.org/ytdl/youtube-dl-2020.09.20.tar.gz

>>35162 original-ytdl is the one that is currently listed on their page, weird-ytdl is the one you have provided. Output of diff original-ytdl/ weird-ytdl/ (edited for readability): ------ Common subdirectories: /bin /devscripts /docs /test /youtube_dl ------ Only in weird-ytdl/: CONTRIBUTING.md .github .gitignore tox.ini .travis.yml youtube-dl.plugin.zsh ------ Only in original-ytdl/: README.txt youtube-dl youtube-dl.1 youtube-dl.bash-completion youtube-dl.fish youtube-dl.zsh Output of du -bd 1 : 7965068 ./original-ytdl 6049158 ./weird-ytdl After removing original-ytdl/youtube-dl (the binary): 6203843 ./original-ytdl 6049158 ./weird-ytdl Their sizes are very similar without the binary. It seems to me that you had downloaded a development version of youtube-dl.

>>35167 And after removing all the differing files, their sizes are unsurprisingly both equal to 5999102 Bytes.

>>35132 >- The DMCA states "No person shall circumvent a technological measure that effectively controls access to a work protected under this title". Whether the content distribution uses EME or other encryption is completely irrelevant and does not imply there is no DRM. Irrelevant. Links are not protected works. Youtube "protects" the link to the work, not the work. The link cannot be copyright. DMCA does not apply to it. >- A decision in Hamburg similarly decided the YouTube rolling cipher qualified as an effective technical measure within the meaning of EU. I see no reason the US would disagree. EU courts made a ruling on an American law, the DMCA? Obviously not. Links cannot be copyright, and therefore any copyright law in the US does not apply to links. It's not even a grey area.

https://notabug.org/ is the best alternative I know. Deemix is hosted there and they don't seem to be angry at it

>>35171 The link is not copyrighted. We agreed on that earlier. No-one here in this thread is claiming the link is copyrighted content. The video is copyrighted content protected by an access control mechanism. The act of generating a direct URL is circumventing an access control mechanism protecting the video. The DMCA states "No person shall circumvent a technological measure that effectively controls access to a work protected under this title". The copyrighted work is not the link. The DMCA isn't applying to the link itself. It applies to the content it links to and the way youtube-dl programmatically circumvents it.

>>35177 >The video is copyrighted content protected by an access control mechanism. There is no access control on the content. Anyone with the link can access the content until the link expires. This works identically to every other hyperlink on the web. youtube-dl is deep linking to the content on youtube. Let's review: http://www.dmlp.org/legal-guide/linking-copyrighted-materials Deep linking: that's what youtube-dl is doing. No court has ever found that deep linking to another website constitutes copyright or trademark infringement. Inline linking: that's what happens if you take the direct link and stick it in a video tag on your site. Still not copyright infringement because you aren't distributing the video. Framing: putting the youtube page in an iframe on your website, still not copyright infringement. In no case is having the link and using it against copyright law. Next section, Linking to Infringing Works. Youtube content is not infringing work. Youtube has the right to distribute the content because the RIAA members granted them this. They upload the content to youtube for distribution by youtube. Furthermore, youtube-dl specifically mentions they will not accept extractors to piracy sites. https://gitlab.com/ytdl-org/youtube-dl#adding-support-for-a-new-site >If you want to add support for a new site, first of all make sure this site is not dedicated to copyright infringement. youtube-dl does not support such sites thus pull requests adding support for them will be rejected. This entire section therefore, does not apply to youtube-dl. The last section, Linking to Circumvention Technology Proscribed by the DMCA, does not apply because the links return content, not circumvention tools. DMCA does not apply here. At most, you can argue youtube-dl violated Youtube's ToS. Violating ToS is also not a crime, https://blogs.findlaw.com/ninth_circuit/2018/01/violation-of-a-websites-terms-of-service-is-not-criminal.html

>>35184 For the sake of argument though, let's do exactly what youtube-dl does, right here, in this window You tell me how this "effectively controls access" a requirement for DRM in the DMCA, which doesn't apply to urls, but we're going to pretend it does. 1. Start with link above, https://www.youtube.com/watch?v=UxxajLWwzqY 2. Take the video id, UxxajLWwzqY 3. Plug the video id into, https://www.youtube.com/get_video_info?video_id=<video_id>&eurl=https://youtube.googleapis.com/v/<video_id> 4. get something like https://www.youtube.com/get_video_info?video_id=UxxajLWwzqY&eurl=https://youtube.googleapis.com/v/UxxajLWwzqY 5. Now, download that link into a file 6. Run it through URL decoding to turn %XX back into ASCII chars 7. you see direct links to the youtube content along with other metadata that youtube-dl parses into a json output Which part of that was "breaking DRM" here?

>>35184 The direct URL (which is what I assume you mean by 'the link') is obtained either legitimately in the browser after viewing commercials (if applicable) or by cracking the rolling cipher. If you don't crack the cipher, you don't get access. It was put there to make it harder to access a working direct URL. Its single purpose is to restrict access. The system that uses the cipher and gives you the direct URL legitimately is therefore access control. Do you agree? >In no case is having the link and using it against copyright law. Having the link and using it, in itself, is not against copyright law. However, whoever generated the link (the youtube-dl user) circumvented a control mechanism in order to gain access to content which is protected by copyright law. >Youtube has the right to distribute the content because the RIAA members granted them this. They upload the content to youtube for distribution by youtube. Yes. They do this because YouTube makes an intentional effort to try and block direct downloads. They have access control techniques that aim to stop people who aren't the video uploader from getting the direct URL. YouTube does not intentionally distribute the direct URL to those who don't view ads. If I'm giving out a DVD free of charge to people who sign up to my survey, and you just walk up and grab one when I'm not looking, it doesn't matter if I have rights to distribute the DVD. You circumvented my distribution system. >>make sure this site is not dedicated to copyright infringement Yes, YouTube isn't dedicated to copyright infringement, like Pirate Bay is. That doesn't mean circumventing their access control in order to illegitimately access copyrighted content hosted there isn't copyright infringement. I don't see what your 'anti-pirate-site' argument has to do with this conversation.

>>35188 If accessed that way, I think it's legitimate access and not infringement. Their API just lets you watch it. I made some false assumptions about YouTube's system that this post has cleared up. Thank you.

>>35192 I retract this. None of those steps are evading DRM. Yes. I actually went ahead and tried those steps with a VEVO video, like your example, and none of those links are playing any video. On a standard video, those play fine. That's where the DRM comes in. youtube-dl does further steps on those videos to crack the rolling cipher.

>>35195 Oh, so it's not the ascii decoding cipher, it's some other decoding cipher. That's now different? Would it also be illegal with base64? How about the Caeser cipher, like rot13? You know, Caeser cipher is trivial to decode like ascii/base64 and is also a rolling cipher if you increment the rotation value at each position, http://www.thealmightyguru.com/Wiki/index.php?title=Rolling_cipher You may as well be arguing that ascii encoding is an access control measure, when clearly you admit it isn't. 1. URLs can't be copyright 2. Copyright material in automated tests is fair use 3. DRM is not some easily decoded character rotation At no point can the RIAA win this. youtube-dl has an ironclad defense for every step down that list. You can't disprove 1 & 2, but still are arguing point 3 prematurely. I'll be happy if youtube can implement real DRM on their vevo videos, making it impossible to view a downloaded video once youtube-dl retrieves it. Nothing of value will be lost IMO. I hope youtube will consider their users and let us automatically filter DRM videos from view, since we don't want to see them anyway.

>>35199 >youtube-dl has an ironclad defense for every step down that list To be fair copyright trials are always a complete tossup. The case law is so fuarrrked at this point it's basically worthless. I of course think ethically they are in the right and I think they have a reasonably good case, but who knows what the geriatric judges will decide.

>>35199 >3. DRM is not some easily decoded character rotation What makes you think that? Shitty, easily circumvented access control is still an access control.

This is obviously part of a larger plan. MS bought out github and pulls soykaf like this in a time like now, its no coincidence. Its a plan to subvert and control opensource development, github being the primary site for projects of all kind they now control throne. If anyone thinks google, ms and the recording mafia will ease up they are mistaken. Its just about obvious they will use every trick in the book to further their control and the government will be happy to sell out. I would guess this is a move to cause chaos and then grab more power while everyone is confused. It is highly doubtful this is the last of this sort of thing to happen.

>>35324 >This is obviously part of a larger plan. >MS bought out github and pulls soykaf like this in a time like now, its no coincidence. No. Because of how the DMCA works, this is almost entirely out of Microsoft's hands. From what I understand, if they refused to honer the takedown request they'd be putting themselves in a situation where they could be held criminally liable. MS has done plenty of bad soykaf, but this was no different to what any other hosting company would do.

>>35326 DMCA does not apply. Go away bot.

>>35329 How does it not apply? A DMCA notice is the cause of the takedown. The stuff you said here >>35324 about Microsoft wanting to control open source is certainly accurate. They saw Google's success with android and would certainly like to replicate it in some form, but I don't see how taking down a popular web scraper script could be part of this master plan.

>>35323 >What makes you think that? A rolling cipher is nothing but an encoding scheme. Decoding an encoded url is not circumventing access control, regardless of the encoding scheme. It has been pointed out repeatedly, there is no DRM on the linked media file. Somehow Netflix, Amazon, iTunes, and the entire universe of commercial online video sites have figured out how to use actual DRM like EME. Google tries to claim their API itself is a DRM scheme because Google WANTS to distribute unprotected media. Having downloadable media gives Google an audience that it otherwise would not have. Having youtube-dl defending against RIAA lawsuits instead of Google saves Google money. It's the same slimy bullshit Google always does: Google breaks the law, then lays the blame on others.

>>35367 It's not an encoding, it's an enciphering. Hence, 'cipher'.

>>35369 A rose by any other name. When you can implement them identically, I don't care what you call it. A Caeser cipher is a key/value map just like a url encoding. With URL encoding, decimal 65 = A, with Ceaser Cipher, M = A. Map<Character,Character>. It's a map either way. A rolling Caeser cipher is just a map of maps. Map<Integer,Map<Character,Character>>. Where you have a different map for each index. At no point does a first century BC encoding scheme qualify as DRM.

>>35375 >A rose by any other name An encoding doesn't use a variable key. So what makes the rolling cipher meaningfully different to enciphering the video with AES-256 and sending over a short decryption key? The cipher is stronger and the key is stronger, so what? It still needs to be decrypted by the end user to be used, but you could just illegitimately crack the key and access it any way. That's breaking an access control technology. It's a weak access control, but it's clearly there and intentional. It needs to be purposefully circumvented to gain unauthorized access. A normal link won't work. Therefore it is DRM. The strength of the countermeasure is completely irrelevant. How you represent it as mappings is irrelevant. A Caesar shift would be like using the password 'password'; it doesn't make cracking it legal just because it's easy. It still qualifies as an access control technique.

>>35382 >An encoding doesn't use a variable key. If I have a function Id(k,v) = k ++ v, I have used a "variable key", and in a lot of theoretical crypto textbooks this would even be considered a "cipher". But it is also trivially easy to break without knowing the key. If the RIAA wants to claim that this "rolling cipher" in the youtube links (which I would like to see evidence of, none of the actual links in the file I can see are googlevideo links) constitutes encryption, then they will need to explain how literally any encoding mechanism isn't. Keep in mind that youtube's own code probably "breaks" this "cipher" as a form of proof-of-work to prevent DDOS attacks. >So what makes the rolling cipher meaningfully different to enciphering the video with AES-256 and sending over a short decryption key? you could brute force a rolling cipher in a few microseconds, whereas brute forcing AES would take millions of years. >It's a weak access control, but it's clearly there and intentional. It is clearly intentionally weak. Youtube engineers aren't stupid, they could make real access controls if they wanted. And the cherry on top: fuarrrk the law, I would use and support youtube-dl even if it was breaking actual crypto. I don't care if what they're doing is illegal, if anything it legitimizes them more.

>>35423 >But it is also trivially easy to break without knowing the key. If the RIAA wants to claim that this "rolling cipher" in the youtube links [...] constitutes encryption, then they will need to explain how literally any encoding mechanism isn't. Again, it doesn't matter how trivial it is to break. It is irrelevant. If I setup a WiFi network with the default password, it's still access control. If I secure a database with the password 'password', it's still access control. If I make a link which doesn't show content unless my custom JS program deciphers it for you, it's access control. >It is clearly intentionally weak. Youtube engineers aren't stupid, they could make real access controls if they wanted. It has to be reversible in any common browser by anyone without an account in order to reach their audience. I don't see how they could do anything that a skiddie couldn't copy, so why waste effort? >And the cherry on top: fuarrrk the law, I would use and support youtube-dl even if it was breaking actual crypto. I don't care if what they're doing is illegal, if anything it legitimizes them more. this 1000% I use it daily on copyrighted content. fuarrrk Alphabet and fuarrrk all art industries.

>>35425 >Again, it doesn't matter how trivial it is to break. I disagree. At what point does it go from "access control" to "making a really hard to use API"? >If I make a link which doesn't show content unless my custom JS program deciphers it for you, it's access control. so if I run that custom JS program in a carefully minimal browser environment without a window, strip out the ads, and display the video, am I breaking access controls? That's what youtube-dl used to do before some easier APIs came around, I believe. >It has to be reversible in any common browser by anyone without an account in order to reach their audience. I don't see how they could do anything that a skiddie couldn't copy, so why waste effort? as pointed out by another user, other websites such as netflix managed to get people to install widevine. Of course that is till trivially easy to break using hardware techniques. But still, it's a hell of a lot more difficult to break than what youtube does. >If I make a link which doesn't show content unless my custom JS program deciphers it for you, it's access control. if you then send me that program and don't formally

>>35429 pls ignore the last two lines I have imbibed and my writing skills are no good

>>34974 >marketed How can absolutely free public domain no "buy me a coffee"-button code be termed as marketed when its not sold in any of the UX web2.0 OG soykaf [s]FOSS[/s] ways - or any other for that matter - possible? I think one could argue that it gets difficult to draw a line on the freedoms here if this soykaf gets censored from websites for copyright infringement reasons. "Being able to access" doesnt mean "access" in the first place. If I have some pentesting tool to crack network security that has an example of a hack, how is that different?

>>35382 >An encoding doesn't use a variable key. *Laughs in UTF-8*

>>35382 >Therefore it is DRM It's not DRM, because DRM controls access to copyrighted content Hyperlinks cannot be copyright The rolling cipher is applied to the wrong thing to qualify as DRM It legally cannot be DRM because it's applied to something that cannot be copyright Even IF you could hold a gun to a judge's head and force him to say >A=65 A=M >B=66 B=N >C=67 C=O >and so on are two fundamentally different things, it doesn't matter at all The DMCA doesn't outlaw circumventing content protection schemes if it's not applied to copyright content Digital Millenium Copyright Act, not the Digital Millenium Hyperlink Act

>>35443 That's adorable, counselor, but you should have started your analysis here: >``(b) Additional Violations.— >`` (1) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that— >`` (A) is primarily designed or produced for the purpose of circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof; >`` (B) has only limited commercially significant purpose or use other than to circumvent protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof; or >`` (C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof. >`` (2) As used in this subsection— >`` (A) to 'circumvent protection afforded by a technological measure' means avoiding, bypassing, removing, deactivating, or otherwise impairing a technological measure; and >`` (B) a technological measure 'effectively protects a right of a copyright owner under this title' if the measure, in the ordinary course of its operation, prevents, restricts, or otherwise limits the exercise of a right of a copyright owner under this title.

>>35447 a lot of use of the word "effectively", which absolutely could not be applied to youtube's little scheme here.

>>35456 >a lot of use of the word "effectively", which absolutely could not be applied to youtube's little scheme here. The word "effectively" has a very specific meaning in the legal world, which basically boils down to "has the effect of". It has nothing to do with measuring how effective the method is. It's all about the intention of the method's creator.

>>35457 so if it does not have the effect of making it even marginally difficult to access the content, is it effective DRM?

>>35457 wait, so if I do literally nothing to make the content difficult to access but "intend" that doing nothing would prevent people from accessing my service, then I've made effective DRM?

>>35459 >so if it does not have the effect of making it even marginally difficult to access the content, is it effective DRM? Going by the legal definition (and not the technical definition) of "effective", as far as a judge is concerned, yes.

>>35460 >so if I do literally nothing to make the content difficult to access Enciphering the URL using a 1 increment Caesar shift (A->B) is doing something that would block normal users from directly accessing the destination. It has a significant effect on access that takes intentional effort to crack ("circumvent"). Doing literally nothing has literally no effect so you probably couldn't convince a judge that you intended it to inhibit access. But maybe you could (if you intentionally avoid posting any public link to a database form and a malicious security engineer guesses the URL, you intentionally made it hard to access by not linking. I am not a laywer but you may be able to provide a decent argument)

>>35447 Not one single aspect of that applies to youtube-dl >is primarily designed or produced for the purpose of circumventing protection youtube-dl is primarily designed to download an unprotected file >that effectively protects a right of a copyright owner This is the big one: Hyperlinks are not copyrightable. Nobody's rights are infringed by decoding hyperlinks. You cannot argue otherwise. Case closed. >has only limited commercially significant purpose or use other than to circumvent protection youtube-dl is the basis of other comercial software, which has raised millions of dollars in funding >is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing protection Since youtube-dl doesn't circumvent DRM, they have never marketed it as such

>>35469 >It has a significant effect on access that takes intentional effort to crack ("circumvent"). https://www.youtube.com/watch?v=p4y0rvx6sBU Oh no! We got too cocky URL encoding bros! Quick, we must file a DMCA takedown against this l33t hacking tool called "Microsoft File Explorer." It is circumventing our URL encoding DRMs!

>>35469 >Enciphering the URL using a 1 increment Caesar shift (A->B) is doing something that would block normal users from directly accessing the destination. It has a significant effect on access that takes intentional effort to crack ("circumvent"). so would encoding it in base64. >Doing literally nothing has literally no effect so you probably couldn't convince a judge that you intended it to inhibit access. B I mean if the judge is dumb enough to believe that what youtube does is an "access control mechanism" I bet they'd buy my bs too.

>>35472 >Hyperlinks are not copyrightable. Nobody's rights are infringed by decoding hyperlinks. This is like arguing crack a hash is not illegal (true) therefore it's fine to use the obtained password to gain access to a database (unauthorized access). For the nth time, they aren't claiming the links are copyrightable. The links are a method used to access copyrighted content. You cannot argue otherwise. Case closed. >youtube-dl is the basis of other comercial software, which has raised millions of dollars in funding I am curious, got examples?

>>35475 >so would encoding it in base64. Yes.

>>35476 >This is like arguing crack a hash is not illegal (true) therefore Now you're claiming cracking database passwords is copyright infringement under the DMCA You ignored >>35473 because it totally destroys your argument and you know it There's nothing legally different about youtube-dl downloading a file and a browser downloading a file under the DMCA It is a different user agent, that's it >I am curious, got examples? You're not getting a name, you're getting a fuarrrk you Go back to your boss and tell him he's barking up the wrong tree with youtube-dl Sue Google, they're under contract to put DRM on your content Make them use real DRM like EME Don't you even see what Google is doing? They're wasting your money to try to sue one of their open source competitors out of business And you fell for it

>>35479 >Now you're claiming cracking database passwords is copyright infringement under the DMCA ­>imp­lying >You ignored >>35473 because it totally destroys your argument and you know it I ignored it because it's a YouTube link and a soykafty sarcastic comment. I watched it now and no, it's 100% irrelevant to the argument. When you start downloading the video in a normal browser, that's legitimate access. Extracting the stream from the cache is completely fine and has nothing to do with access control; you were given legitimate access. Imagine being mad about discussion of American law.

>>35479 excuse us we're trying to hold an intellectual discussion here

>>35482 >I watched it now and no, it's 100% irrelevant to the argument. When you start downloading the video in a normal browser, that's legitimate access. lol, okay man. I'll go check the law again. I must have missed the "normal browser" requirement section.

>>35487 Not him, but you seem to have some misplaced faith that copyright law is fair, reasonable, and logically consistent. It isn't. It's all complete bullshit written by and for recording industry lobbyists. The very concept of copyright is absurd; it shouldn't surprise you that the laws written to enforce it are too. You should know that people like myself have been criticizing the anti-circumvention clause for years because the fact is it does cover cases like this. If you think that's bullshit, great! I completely agree that it's bullshit. The best thing you can do is spread the word about how bullshit it is so that some day radical copyright reform is politically feasible.

GitLab forcing you to use javascript is a dealbraker for me.

>>35506 >GitLab forcing you to use javascript is a dealbraker for me. I was always suspicious of Gitlab due to how the vulture capitalists at Hackernews fawn all over them. (I treat HN like an inverse moral compass: if I find myself agreeing with the hivemind there, I stop myself and rethink my position.) But for me the final nail in the coffin was this mess: https://www.theregister.com/2019/10/30/gitlab_backtracks_on_plan_to_add_usage_telemetry_after_user_protests/

>>35512 Something like that should be rewarded, not condemned. They listened to their userbase and chose to make less money by not monetizing their users. How dare they attempt to make money, right?

>>35513 I might have agreed with you if some heads had rolled, especially their CFO Paul Machle. That beancounting prick publicly said "This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that." That they kept him around speaks volumes as to their collective moral character.