Sorry to burst the bubble, but this is nonsense. If you don't want something to be downloaded, don't put it on-line.
If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
Some companies that do web development (commercially, internally, or whatever) have tighter release schedules than the cool DevOps style Continuous Deployment that we see the unicorn startups like Basecamp, GitHub, Slack, etc. doing where code can get pushed to production a dozen times a day. The place I work at has governmental regulations and SLAs we have to comply with when we deploy, which puts us on a cadence with something akin to Chrome's release schedule (e.g., Dev is CI/CD, QA is CD, UAT is kept to about once a week, Prod is every 4 weeks with capabilities at a 2 week hot fix window). Additionally, we just don't have the resources or budget available to keep one developer twiddling his or her thumbs all day waiting for new buttons to show up on a browser control that we have to hide or mitigate the impact of.
I completely understand what your argument is, and it's valid. We have QA run integration, regression, validation and smoke tests any time code is promoted up the environment chain that tries to catch issues like this, and we do our best to keep on top of it all. This issue isn't something that effects us, but it shows a reactionary approach to dealing with these issues. Teams that do spend their time reacting to changes like a new button, or an underlying OS update breaking some compatibility or what-have-you have always been a thorn in my side. It's no way to deliver value to their customers since their time is consistently being hijacked from new features to put out fires, which is stressful and leads to burn out very quickly.
It used to be that we had standards for this kind of thing precisely so that huge amounts of effort on ongoing browser testing wasn't necessary.
And you have plenty of control over the way this sort of content is presented. Unfortunately all this sort of change and the supportive attitude widely seen in this discussion will do is push sites towards the less flexible and user-friendly options, particularly the sites that didn't previously go for things like DRM.
Developing for the web has always been this way.
No, it hasn't. "Evergreen" browsers that move the goalposts every few weeks are a relatively recent development, and particularly in the area of media elements and the related controls their approach has been a nightmare from day one.
If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
How is that attitude going to get more new and useful content onto the web?
Or lobby really hard to implement DRM into browsers and lock down all devices allowed to access internet right? :P
The mean reason why DRM will be used in HTML5 will not be for media but for advertising.
Blocking ads will then be targeted as circumvention of DRM.
Google et all must be drooling at prospect of unblockable ads
Pre-legal speculation disclaimer: IANAL.
They'd have to define DRM as not only preventing ripping the video outside of its normal context but any type of alteration prior to display, even if it occurs after the encryption module terminates. That'd be hard because the decoder ordinarily makes some alterations to the decrypted video stream, e.g., scaling for different displays, overlaying subtitles, applying filters, etc.
HDCP is intended to make DRM circumvention apply to any intermediary devices, like capture cards, but that wouldn't work for computers since HDCP is just working between the display and the GPU driver, if it supports HDCP; the program used to playback the content would be unconcerned with this.
Again I'm not a lawyer but I don't see how blocking ads could be construed as counteracting DRM, as long as the analysis is occurring after the normal decryption cycle.
The wiggle room for publishers is probably in whether or not destroying the ads creates a "derivative work" or not. The consumer's argument that the page is not saved and displayed only temporarily would probably not work due to the RAM copy doctrine.
Things like the Family Movie Act [0], which was passed in 2005 to pre-empt a lawsuit filed against ClearPlay, a DVD player that provided fast-forward and mute macros to bypass objectionable content in legitimate DVD copies, would not apply since they explicitly authorize "making imperceptible [...] limited portions of the audio or video content of a motion picture [...] for private home viewing"; scope limited to motion pictures only.
Ad blockers have been challenged several times in European courts, where they've won, but I don't see how they could expect to win a copyright challenge in American courts (beyond blatant judicial activism).
My assumption is that big shots like Google have not pursued this yet because they're more worried about the Streisand Effect than allowing relatively advanced users to install ad block. Knowing that the blockers are legal in Europe, there's probably nothing they could do to stop people from using them, and it'd just create a huge PR issue.
Maybe the DRM angle is intended to get European courts to rule against ad blockers? I don't know.
As far as blocking video ads goes, you don't even need to access the video. EME protected video components still show their length in the browser. Blockers which never actually see the content are entirely possible by just looking for videos less than a minute or so.
MAI v. Peak is the case that proclaimed the "RAM copy doctrine", which says that loading a computer from disk onto RAM constitutes a new copy under the Copyright Act, and therefore may infringe.
The specific case was about whether Peak, a computer maintenance and repair company, had the right to load diagnostic software that the computer's owners had purchased. The Court ruled that they did not, and that by copying the program data from disk to RAM (that is, running the program), the computer technicians had violated copyright.
Congress addressed this case specifically with reference to computer repair by carving out a special exemption for repair technicians to run the software that the computer's owner had purchased. Said exemptions don't apply to anyone else, though the owner can "make or authorize the making of" copies if they are necessary to actually use the product (I don't know why the owner's authorization to make a copy wasn't good enough for Peak).
Practically speaking, of course it's unenforceable on the large scale because as you say, it'd be hard to detect who is doing it, and the more fuss they make about this type of stuff, the more damage they do to themselves.
I'm talking about the AACS 2.0 Blu-Ray DRM format, which requires you to have a compilant BR player, compliant motherboard with DRM support, compliant CPU with DRM module (!), compliant GPU, AVR and display. All of those components are built to lock you out from modifying or capturing the picture stream from BR to the display itself.
With the draconian craziness of DRM and widespread support for it (even here on HN), it's easy to see this kind of lockout being deployed on the web as well, especially if that allows advertisers to shove more ads in your face without the possibility of using an adblock.
Most people see websites as they see movies: they type facebook.com and hey, an image. Enter login and password and enter and hey, another image.
The fact that things are built on top of other things (websites -> html and assets) is deep magic.