I see plenty of mentions of WebRTC but yes, the blog's target audience are people who are in the WebRTC space. There is also a link to slides explaining WebRTC in the article.
It's 'web real time communication' - you can use it for peer to peer voice or video chat, as well as passing arbitrary data between peers w/ javascript.
As someone who does know what web RTC is, I find your comment interesting. Strange that a hacker news reader wouldn't know what webrtc is nor how to handle being unaware of a technology.
This posting is interesting because webrtc support has lagged in safari.
Webrtc is about more than just video and worth looking up.
I wondered that, too. It seemed like it was just absentmindedly forgotten to be mentioned. On a second, closer read, I realized that it was actually a design issue. The default text was chosen to be grey, and the link text color to be dark blue-grey. Essentially, links are indistinguishable from the text they are interspersed with. If you click the link and jump to it when you see it in the first paragraph, you'll find further details. "As you know, Stefan H from Ericson R&D, and Chair of the webrtc working group @ w3c and myself have been instrumental in starting the webrtc in webkit initiative[THAT WAS THE LINK!]."
...it gives you this:
"WebRTC is a set of browser APIs and protocols being worked on by the W3C and IETF standardization bodies. With WebRTC, developers can quickly add real-time peer-2-peer audio, video and data capabilities to their web applications through a set of standardised JavaScript APIs.
WebKit today lacks support for this exciting new standard. Our intention is to add WebRTC support to WebKit, starting with the WebKit GTK+ port (Linux), by means of the OpenWebRTC implementation. Much of the WebRTC support will be implemented in the core of WebKit and therefore shared among all WebKit ports. This will also enable integration of other WebRTC backends such as webrtc.org."
It would have been nice if that had just been summarized and added into the post though. It's kind of annoying to have to jump around to a bunch of different places when all you're trying to do is soak up information quickly and move on to the next thing. It really pulls you out of the flow of the article, gets you out of the mindset of "I'm just sitting here reading an article." (into something more like "now here's a 1. visual puzzle where I have to figure out which elements are clickable, and 2. one too many click-throughs and back-buttons, figuring out where I was back on the main page, and trying to resume reading.
Did it not occur to you to look it up? An article is not required to define every term it uses - imagine if news stories defined what the "President of the United States" was every time he was written about.
Because it's the lowest common denominator and most "portable" platform out there. It also allows client-to-client communication without an intermediary server.
What's the alternative? Installing native apps that can own your machine, install root kits, and spy on your entire system? Why would I want to install a native app to do any of this (skype, google hangouts, fb messenger, ...) if I can do it in a browser and not have to trust the app?
Statistically speaking, more users get owned via web browsers than via native apps, and that is unlikely to change if people keep on adding new APIs to web browsers because every time a new API is added to my web browser, every web site I visit gets a chance to use the new API to try to own me.
I certainly understand why developers and others find it convenient and profitable to keep on adding APIs the client part of the global client-server document-publishing platform, but I am simply amazed to come across someone using security of all things as an argument or a justification for doing it.
Think about what you are saying! You have a new API you want to make available to developers, but of course it is really hard to create an API that cannot be exploited, so to keep things as secure as possible, every time the user needs to check the weather forecast, look at the new photos of the grandkids or look for a new recipe, some random web server plus zero-or-more third-party ad servers should get a crack at exploiting the new API!
> Statistically speaking, more users get owned via web browsers than via native apps
Source? Seems like a long stretch, especially if you factor in non-windows desktops and all mobile devices.
If you really are concerned about security wouldn't you rather trust basically just Apple and Google or Apple, Google, and every native app developer in the app store?
Having a load of random apps installed on your smartphone is simply less secure than than just using that functionality within a sandboxed and standardised web browser that goes through endless routine security updates.
Its much easier to chose what to install from an app store. If you click on the wrong link, or if you receive malvertising, boom! vulnerabilities in this could cause your phone to be infected.
I can see why WebRTC is useful, but I personally wouldn't want to make regular use of any video or audio chat service that requires a web browser. The last thing I need is yet another tab to keep open (please give me something I can use my operating system's window and process management facilities with), not to mention a native app will probably do the same thing more efficiently.
This is awesome news! I had begun to lose hope that this would happen anytime soon. I'm building my business on using this api to help podcasters record in high quality (http://zencastr.com). Currently I can only support Chrome and Firefox. Adding Safari to the list is most welcome and will open up the possibility for iOS users as well.
Great news! Not because I use WebRTC at all, but because I use Safari.
Why would you do that?? It integrates nicely with the OS. Spell checking, keychain, services, keyboard shortcuts, right-click dictionary lookup, easy link sharing. Little things.
I have recently noticed more and more sites are starting to break on Safari. Ever since Chrome forked webkit, it has started to lag behind. Since Safari has a small marketshare and a different engine from the major players, some sites dropped support for it.
A prime example is file-upload to Github issues. You'd think that uploading files is as old as the web itself, but when you try to do this in Safari, it says something like "Sorry, Safari does not support file attachments. Please use a modern browser like Firefox or Chrome."
If the only way for me to test your small market share desktop browser is to buy hardware from you because you artificially lock your os to your hardware, I'm not going to test on your browser.
On Mac OS, the solution for users is to run a different browser like Chrome or Firefox, as nearly all of my Mac friends do. If this issue starts to affect media consumption sites on iOS's Safari, that's another story since iOS users aren't allowed to use an alternate browser (they're all running Safari underneath).
It's file upload: I'm 99.9% sure that the most braindead 90's style way of doing it will work on all browsers today, and continue to work in the future. Why do you need to break it?
Newer methods allow you to do a lot more - report progress of the upload, even read the file locally before upload (so you can resize images, for example). They're all great features to add, and I guess that GitHub decided that it was worth adding them and not keeping an older experience for Safari users.
IMO, they're both at fault here. GitHub should be able to provide a fallback, but also Safari should be keeping up to date.
Some of it is from falling behind, but a big part of the burden on web devs is that Safari updates just frequently break existing JS and webpages. I don't know if it's because Apple has insufficient testing before releases or because they expect web devs to roll over and do what they want, but either way, it sucks.
Back when Safari had windows builds, I at least made an effort to test locally and fix the bugs they kept introducing. But many of the bugs only reproduced on OS X, and now there's no Windows port, so there's no way I'm going to drop a bunch of money to buy a Mac just so I can do their work for them.
Safari bugs have broken my JS more often than every other browser combined. IE included.
Also, battery life. I switched from Chrome to Safari about a month ago, and have been getting at least 10-20% longer out of my battery depending on whether I'm just browsing/developing.
What bothers me about WebRTC is that it can be used to penetrate privacy measures. More specifically, for IP address discovery. Other than that, full speed ahead!
33 comments
[ 6.1 ms ] story [ 84.3 ms ] threadThe article goes through an effort to explai WebKit and Safari but never makes a single mention about WebRTC. Title of the blog doesn't help either.
https://en.wikipedia.org/wiki/WebRTC is helpful in case those aren't enough.
This posting is interesting because webrtc support has lagged in safari.
Webrtc is about more than just video and worth looking up.
...it gives you this:
"WebRTC is a set of browser APIs and protocols being worked on by the W3C and IETF standardization bodies. With WebRTC, developers can quickly add real-time peer-2-peer audio, video and data capabilities to their web applications through a set of standardised JavaScript APIs.
WebKit today lacks support for this exciting new standard. Our intention is to add WebRTC support to WebKit, starting with the WebKit GTK+ port (Linux), by means of the OpenWebRTC implementation. Much of the WebRTC support will be implemented in the core of WebKit and therefore shared among all WebKit ports. This will also enable integration of other WebRTC backends such as webrtc.org."
http://www.webrtcinwebkit.org
It would have been nice if that had just been summarized and added into the post though. It's kind of annoying to have to jump around to a bunch of different places when all you're trying to do is soak up information quickly and move on to the next thing. It really pulls you out of the flow of the article, gets you out of the mindset of "I'm just sitting here reading an article." (into something more like "now here's a 1. visual puzzle where I have to figure out which elements are clickable, and 2. one too many click-throughs and back-buttons, figuring out where I was back on the main page, and trying to resume reading.
I certainly understand why developers and others find it convenient and profitable to keep on adding APIs the client part of the global client-server document-publishing platform, but I am simply amazed to come across someone using security of all things as an argument or a justification for doing it.
Think about what you are saying! You have a new API you want to make available to developers, but of course it is really hard to create an API that cannot be exploited, so to keep things as secure as possible, every time the user needs to check the weather forecast, look at the new photos of the grandkids or look for a new recipe, some random web server plus zero-or-more third-party ad servers should get a crack at exploiting the new API!
Source? Seems like a long stretch, especially if you factor in non-windows desktops and all mobile devices.
If you really are concerned about security wouldn't you rather trust basically just Apple and Google or Apple, Google, and every native app developer in the app store?
Having a load of random apps installed on your smartphone is simply less secure than than just using that functionality within a sandboxed and standardised web browser that goes through endless routine security updates.
Its much easier to chose what to install from an app store. If you click on the wrong link, or if you receive malvertising, boom! vulnerabilities in this could cause your phone to be infected.
Why would you do that?? It integrates nicely with the OS. Spell checking, keychain, services, keyboard shortcuts, right-click dictionary lookup, easy link sharing. Little things.
I have recently noticed more and more sites are starting to break on Safari. Ever since Chrome forked webkit, it has started to lag behind. Since Safari has a small marketshare and a different engine from the major players, some sites dropped support for it.
A prime example is file-upload to Github issues. You'd think that uploading files is as old as the web itself, but when you try to do this in Safari, it says something like "Sorry, Safari does not support file attachments. Please use a modern browser like Firefox or Chrome."
On Mac OS, the solution for users is to run a different browser like Chrome or Firefox, as nearly all of my Mac friends do. If this issue starts to affect media consumption sites on iOS's Safari, that's another story since iOS users aren't allowed to use an alternate browser (they're all running Safari underneath).
IMO, they're both at fault here. GitHub should be able to provide a fallback, but also Safari should be keeping up to date.
Back when Safari had windows builds, I at least made an effort to test locally and fix the bugs they kept introducing. But many of the bugs only reproduced on OS X, and now there's no Windows port, so there's no way I'm going to drop a bunch of money to buy a Mac just so I can do their work for them.
Safari bugs have broken my JS more often than every other browser combined. IE included.
Apple: please, please decouple Safari from the OS, and use App Store updates to update your browser more frequently.