>It smells a bit like embrace-extend-exterminate to me, even if it's not intentional, it currently is a natural consequence of "claim to do X in a browser" without access to the underlying primitives necessary to do X in a standards-compliant manner.
Sure, so don't support it. If no one supports the protocol or the app, then it will die. That's an acceptable outcome to some. I'm not saying anyone has to support it, I don't even have any vested interest in it. It's just an interesting project and I've spent far too long today on HackerNews defending it when I could be working on my own projects.
To me, it looks more like "Adding Bittorrent into Firefox is pretty much impossible, where can we start instead?"
>In my opinion browsers need to provide thinner abstractions over posix apis (with the appropriate sandboxing and opt-in where necessary).
NaCl & Emscripten should get you some of the way there.
> I think the problem lies with the browser vendors, who aren't implementing the bittorrent protocol in the browser.
browser vendors shouldn't have to implement it. they should expose posix-like APIs (bsd sockets, file IO) or process management+ipc via plain pipes (talk to native bittorrent client) so it could be provided through an extension.
The problem with browsers is that they create a backwards-incompatible API stack. This is understandable for web content. Not so for extensions.
>Only one browser recently has been serious about implementing protocols and features that are beneficial to the user, not companies.
Uhhh, do you just mean things that you specifically care about? Because I consider DNS-over-HTTPS, site isolation, multi-account containers, scipt-blocking, etc. all to be features that were beneficial to users.
>How many other browsers have Tor, Webtorrent, ENS, IPFS support?
I personally don't want Tor, Webtorrent, ENS, or IPFS to be in my browser, nor other cryptocurrency stuff to be near my browser. This is not as much of a selling point as you make it out to be, at least for some users.
I'm not really for or against Brave, but you're presenting your argument as if it is fact; everything you said is entirely opinion.
> it's not clear that having a library would add any security
I don't think that's the main benefit of using/developing an external library for this. To me, using an external library sounds like a good idea because:
- You get code separation. A bit less code on the main Firefox repo, and a repo dedicated only to BMP decoding (or image files in general). Someone who wants to contribute to the BMP decoder wouldn't need to download all FF repo and understand/configure its build system. Big plus!
- The library can be shared among different applications. It doesn't make sense for each browser to have a different implementation of BMP decoding, each with their own bugs. Sharing a library for this kind of stuff would actually benefit security, as a bug fixed by one browser/app developer would benefit the others.
That last one is the biggest thing for me. The BMP example is a very simple one, and not very important. It is in more complex tasks that i think sharing libraries would be much more beneficial.
For example, wouldn't it be great that, instead duplicating so much effort in implementing the streaming capabilities of Media Source Extensions [1], the different browsers shared a library dedicated to that complex task? We could have had a more complete and robust implementation in less total time! And that's just one example; there are tons of complex things browsers do that could be extracted to separate shared libraries.
> or we are stuck with Silverlight and Flash video forever
This proposal simply trades one insecure, binary blob for another. It doesn't really solve the problem.
> rather than getting and updating 2-3 different insecure plugins all the time for doing the same thing?
IIRC each site can provide its own module, so it'll be many more than 2-3 plugins
> Is this just a crusade agains DRM as a whole (good luck with that) from the free software movement, or do they have problems with this exact proposal from the w3c?
Why good luck with that? DRM simply makes honest users jump through hoops and allow themselves to be controlled. Also, the proposal itself doesn't really solve any of the problems that flash and silverlight do. And those binary blobs will still probably not run in linux...
> People like you seem to think that if the W3C rejected DRM then sites would stop using it (and hence this being for the benefit of the user).
When did I say that? Specifically? Why did you assume I'm ignorant of the way corporations operate?
That's on you. Not me.
> It's absolutely beneficial for browsers to have a standardized API for this stuff instead of non-standard plugin hell.
Except the standard that they adopted is not friendly to the end-user. So "Non standard plugin hell" becomes "standard DRM hell."
A while back Widevine stopped working for me after an update. Uninstalling and reinstalling didn't work. End result? Almost no video played in my browser. You know what still would have worked? Pirate Bay.
You can spin it however you want. DRM is good for content providers. It's not good for users.
If Netflix requires DRM - so be it. They've got good engineers, they can provide a DRM plugin that you have to use. Or a standalone player. If a service doesn't have good engineering, their service will suffer.
It doesn't need to be a part of the open web standard.
> Personally I am disgusted that this standard is being promoted by the W3C and Tim Berners-Fucking-Lee. The browser vendors are perfectly capable of building (and even standardizing) this tech by themselves.
I don't understand these two sentences in conjunction, which is most of why I don't understand all the complaining about this issue. If, as almost everyone admits, the browser vendors are going to ship DRM-enabled playback one way or the other, what difference does it make whether it's in the official spec?
The HTML5 spec is just a piece of paper that exists to make web developers' lives easier. I don't understand the need to assign attributes like "purity" to it, especially when (as you yourself said), whether or not the DRM is in the spec changes nothing on the ground.
There is a difference between add-on code for particular proprietary content platforms, and writing DRM support into the web standard. Not implementing a Flash plugin doesn't break compliance with the 'official' browser standards - not bunging in the EME stuff will, presuming it gets fully adopted.
That, as I understand it, is the real point of controversy in this whole thing - whether DRM belongs in web standards. Mozilla was fighting it, uniquely among major browser vendors so far as I know; this move means that they've basically given in.
Whether they are right or wrong to do so is another matter.
> Uhhh, do you just mean things that you specifically care about? Because I consider DNS-over-HTTPS, site isolation, multi-account containers, scipt-blocking, etc. all to be features that were beneficial to users.
I mean implementing ALL useful technologies, the ones you mentioned, the ones I mentioned, not just the ones that don't threaten the moat.
There seems to be a pattern in the mainstream browsers to ignore the P2P tech for reasons ;)
> I personally don't want Tor, Webtorrent, ENS, or IPFS to be in my browser, nor other cryptocurrency stuff to be near my browser. This is not as much of a selling point as you make it out to be, at least for some users.
That's fine! But there are very valid use-cases for streaming torrents, for accessing onion sites, for ENS domain lookups, and accessing IPFS content.
Just because you personally don't want or need them doesn't mean others don't. I'm glad Brave gives the option and ability to easily access these technologies.
> I'm not really for or against Brave, but you're presenting your argument as if it is fact; everything you said is entirely opinion.
I mainly annotated browser monetization & adblocking policies and listed tech in Brave not in other browsers. Please be specific on your criticism and I will address it.
> Why should we build this functionality into the browser? Is it really that much more convenient than installing an app to run the proxy?
Apparently it is, given how highly requested of a feature it is to have everything you could do with VMRC available through the web browser with no plugins or local software.
Again, I still don't think it's a good idea either, but I also don't like a lot of the crazy shit built into modern web browsers for maybe the 1% users, like the mentioned WebMIDI.
Firefox is trying to avoid losing marketshare and you're complaining about a big usability win. In what way could causing every video service on the planet to start steering users towards Chrome/Edge/Safari help that?
(Yes, I realize we don't like DRM but normal people are far more concerned about not having to do anything other than click play on Netflix/Amazon/Hulu/etc.)
Not true. See Google's NaCl and Mozilla and Microsoft's own alternatives to that. Neither went anywhere because each browser pushed in a different direction. It's only through W3C that they managed to build WebAssembly and all agree to use it.
I see this DRM thing the same way. Without W3C they may have built their own DRM solutions (and in fact, they have, years ago), but they wouldn't be compatible with each other, which means they wouldn't get too much adoption either.
> If you advertise your app as a browser then it should not secretly scan files.
Not trying to be snarky, why not? It's one of those statements that seemed obvious until I thought about it. Who even gets to decide what features something called 'X' is allowed to have?
Sure, I would personally prefer that they didn't but I honestly cant think of a reason they should be forbidden from doing so. "Our users' browsers are horribly infected due to malware/adware that's not being purged. So we're including an AV to combat that" seems like enough of a justification.
> I'm glad Linux/Firefox can Netflix, but I'd like it if web standards were open and not patent encumbered.
The actual web standard is open. Netflix was one of the key players in making this an open extensible standard instead of it being an extension or plugin for browsers.
> as if the only issue with these was that they're poorly coded and supported
A major issue is that arbitrary code can do arbitrary things, up to and including installing rootkits on your machine (for example, the Sony rootkit debacle). The sandbox means it can only do what the sandbox allows it to - in the case of Firefox's sandbox, that's very little.
"I should be able to watch whatever content I want on my system without installing proprietary software, even if that software is highly sandboxed and can't even see anything on my system and can't cause any permanent changes" is a political and moral issue more than a technical one.
> the alternative is a worse UX from a plethora of more hostile, wider reaching proprietary DRM implementations.
But we're going to have a plethora of proprietary DRM implementations, each self-important vendor writing their own plugin targeting the EME API. And end-users will still have to track-down the correct combination of architecture and OS for each plugin, except multipled now for every streaming-media vendor that they use.
For example, look here at the most-deployed DRM plugin currently available:
Nothing available for *BSD, Sailfish, FirefoxOS... whereas current users of those platforms at least have Flash.
The W3C's argument is that without EME, DRM-protected media will move off the open web into its own app-silos. But that's exactly what will happen with EME, too, except the apps will be hosted within browsers.
Wouldn't this be a good opportunity to draw the line with browsers-for-the-open-web and apps-for-secret-stuff?
> Distributing something that was not a study as a study was what upset people last time.
People got upset because an add-on for a commercial TV series auto-magically installed itself in their browser without their manual intervention.
You can't just abstract that out into an ethics framework of, "If Firefox sends non-X over a channel reserved for X, then users get upset." I mean, you can, but you're going to be rightly confused and misunderstood.
> If a single company can effectively decide whether a bunch of 3rd party sites that they don't control work on your browser, how is that any different?
That's just a sensationalistic as the headline. There isn't a single company controlling and selling these modules. There is a several of them, in open competition. The OP chose Widevine because they are easiest, but with sufficient perseverance he could probably use any of them, or at least any that distribute x86 binaries. It's damned near impossible to prevent someone from running a binary if they really want to.
I also found the original article difficult to swallow. It gave very little detail - so little we have no idea what Widevine said no to. For example, was it "could you provide Widevine and loan me an engineer to help me integrate it with my browser - but I can't pay you because it's all open source". Or was it "I've got it all going, I'm willing to pay you commercial rates per licence - how can I buy licences?" It if is the former hats off to Widevine for replying at all.
As it is, we only get a small part of his side of the story, no insight at all into why Widevine reacted they way they did, and a headline that's guaranteed to get clicks.
Call me paranoid, but I get the feeling I'm being manipulated.
>Letting users install and run unmaintained software is dangerous.
Which is... exactly what Windows and Linux still do, rightly.
>And they'll blame the browser for that, and rightfully so.
Not at all rightfully so. Moreover the supposed security gain from this is absurd. So a user can't accidentally install a malicious extension... but they can install malicious software. Which, being that it has full access to the system, could patch Firefox if it liked to disable the signing check.
I won't use a browser which implements restrictive code signing practices.
Sure, so don't support it. If no one supports the protocol or the app, then it will die. That's an acceptable outcome to some. I'm not saying anyone has to support it, I don't even have any vested interest in it. It's just an interesting project and I've spent far too long today on HackerNews defending it when I could be working on my own projects.
To me, it looks more like "Adding Bittorrent into Firefox is pretty much impossible, where can we start instead?"
>In my opinion browsers need to provide thinner abstractions over posix apis (with the appropriate sandboxing and opt-in where necessary).
NaCl & Emscripten should get you some of the way there.
reply