A similar model was adopted by FirefoxOS from the start: "Web Activities are a way to extend the functionality of HTML5 apps without having to access the hardware on behalf of the user. In other words, you don’t need to ask the user to access the camera or the phone, but instead your app asks for an image or initiate a call and the user then picks the app most appropriate for the task. In the case of a photo the user might pick it from the gallery, the wallpapers or shoot a new photo with the camera app. You then get the photo back as a file blob. The code is incredibly simple:"
The W3C Working group has NOT yet committed themselves to adopting the ORTC API from the community group.
So basically, Microsoft is still on their own. The browser API is not a standard yet and it might still change before it is part of the real WebRTC standard.
WebRTC has 2 parts: protocols & codecs (RTCWeb WorkingGroup at the IETF) and the browser API (WebRTC at the W3C). Al lot of the people are the same people.
All parts of WebRTC was already being worked on before Microsoft really got involved. And Microsoft wanted a more low level browser API than the other WebRTC browser API that was already being worked on. Microsoft wanted this for things like Skype.
Eventually a new community group (not workgroup) was formed at the W3C to work on a new API called ORTC.
The working group at W3C that works on WebRTC have committed themselves to adopt ORTC. So now WebRTC has 2 APIs, only Microsoft has an implementation of ORTC. Firefox, Chrome/Chromium and Opera have an other. And it looks like WebKit/Safari will get WebRTC support too.
The older API is easier to use, because the newer API is more low level, but there are or will be Javascript libraries which will present you with one API which should work with both.
Having a low level isn't such a strange thing any more in browser/webdevelopment land, because as it turns out you can have Javascript libraries which abstract the stuff most don't need to know. Because a lot of times webdevelopers use those anyway, to abstract the differences between browsers.
It's starting to look like more and more browser APIs will be more low level, so high level APIs can be built on top and changed more easily.
A big part from what he says is: Dark markets can circumvent capital controls: - tax avoidance (with the multiple layers of taxes, dark markets are a lot cheaper) - trade barriers (trade anything with anyone)
"When everyone can code there will be no such thing as a "web service" API because enough people would have been smart enough to spend their time developing useful transports rather than always relying on the lowest common denominator/lowest hanging fruit (e.g. http)."
I think this is an interesting discussion, but only if you are looking at the future. Because I'm much more optimistic about the future of http.
First off, yes it would be good to have certain applications use their own protocol.
But having a standardized protocol really helps. Especially if you combine it with something like REST and json and use standard libraries (like libcurl) for that.
http is stateless which means you can easily proxy it.
Now http 1.1 isn't a great protocol, it's old.
But http 2 solved a bunch of parts which needed to be solved like:
less overhead (for example for the headers)
no head of line blocking
multiple streams in the same connection
It didn't get a websocket protocol though, so no tcp like behaviour. Obviously the websocket protocol itself can already do that.
Why would you want something like websocket ?
Because the people who make the standards are working on improving the underlying layers for https (tls) and tcp as well.
Look at what Google has done with quic:
zero roundtrip connections (thus better than plain tcp, it can do that because it uses udp)
multipath support
always uses (datagram)tls so it uses security
The tls 1.3 specification which the ietf (which makes protocols like tcp and http) is adding the pieces needed for a quic like protocol.
I think in a few years a http 2 over quic like tls 1.3 will be in widespread use.
To the developer it looks like http 1.1 but underlying transport will be secure, low latency and fast and it will be part of the library you use.
When you look at what the dns workinggroup is doing, I wouldn't be surprised if they adopt tls 1.3 as a transport well. Because they want to get privacy for the dns protocol as well.
Now if you think we need a more peer2peer and distributed model then I agree. But if you look at the most popular peer2peer application, bittorrent, is even inspired and partly based on http.
If you combine namecoin and some of the dnssec protocol then you can have:
no central root (for at least part of the namespace, namecoin uses.bit )
distributed blockchain based dns names
certificated tied to dns names
certificate validation by the client library when connecting to a http 2 host
local validation of dnssec information which can be used as an anchor to store your public keys
What is the result of all of the above ?:
no use for Certificate Authorities other than maybe 'green bar' if you really want it
no icann
standardized protocols by people agreeing and writing things down
possibility to use http semantics for web and distributed or peer2peer protocol without the overhead
secure by default because of encryption
support for multipath and low latency communication
open source libraries
PS I wrote all the abbreviations in non-caps and removed all the dashes, because I encountered the lameness filter
Not only that, if you really care about this problem. You need to not have the encryption keys on a machine you don't trust. I would keep the server hardware close.
Don't use VMs or servers cloud/hosting providers (maybe dedicated colo-servers in a cage with an alarm on it ?). Or host it yourself. That is the only way to be sure who has access to the hardware.
Also keep it in the same jurisdiction as yourself, dealing with multiple governments just makes things more complicated.
Everything else is just silly business because there is no way encryption can safe you from an attacker with physical access.
Just look at all the buggy IPMI implementations. You have to remember these devices have direct access to RAM (if you decrypt/encrypt data on the server, that is where your unencrypted data is).
Unless: you are only storing encrypted data, you probably don't need machines/VMs for that.
Or your application needs to be designed and build to only store/use encrypted data on the server, like with homomorphic encryption: https://www.youtube.com/watch?...
And the designed for homomorphic encryption part is important, so you don't leak any data by accident.
If they are only a little bit more advanced then our civilization they've probably encrypted all their communication, maybe even encoded it in such a way that it will be hard to distinguish from cosmic noise. If they don't want to be found, they'll be hard to find.
Not saying it's the best thing since sliced bread. Just saying some large websites made it work well for them and they kept using it. They didn't go back to how they were doing it before.
They are talking about making content available everywhere forever.
The IPFS article links to a YouTube video ( https://www.youtube.com/watch?... ) which 'the uploader did not make available to your country'.
Well, that's funny, because the video isn't their original content. The content was produced in my country by a public broadcaster (aka publicly funded TV).
https://popcorntime.io/ which is used by a good chunk of people around the world is written in 'node-webkit'. So node.js with Webkit. Webkit is used for running the HTML-/CSS-/JS-frontend and node.js is used to start and run the Javascript code which for example has the bindings for the bittorrent library.
The transport of packages isn't a good example of a well working sector. The price delivery people get paid per package has dropped to an unsustainable low.
Not surprising because when you order online delivery most of the time is 'free'. Doesn't matter if you order directly from China or from a company in your own town.
Ahh, that is what you mean. Yes, I can see now how you'd call it more capitalistic.
I do think it was a mistake to sell some of those national state owned companies. I hear English rail is kind of a mess. Ironically the well run train companies are usually partly state-owned by foreign European countries.;-)
Yes, I agree it's a better system in the Nordic countries. They spend a lot of money on education and at least one makes it easy to fire people but also spend a lot of money and effort on getting the unemployed new work while they keep almost all of their previous salary in the mean time. Creating a more flexible workforce at a high cost of the tax payers (which I assume leads to a big positive overall).
Let's say when I think of big state/lots of taxes capitalism isn't my first association.
Can you explain what you mean with: socialist French and welfare state Nordic countries ? Because I would lump them all in the same category, but you clearly have 2 different categories.
I'm from Europe and I would think I know more about European countries than the average US citizen, so maybe it's just a cultural divide why I don't understand what you mean.
Do you really believe you can easily find developers that are really good at security code auditing and fixing security issues or use other developers and let them fix these security issues. I don't think these things are related.
Slashdot Mirror
No, fake contacts doesn't solve the problem. The problem is you need a better model is. Funny fact Android already has one:
http://developer.android.com/r...
A similar model was adopted by FirefoxOS from the start:
"Web Activities are a way to extend the functionality of HTML5 apps without having to access the hardware on behalf of the user. In other words, you don’t need to ask the user to access the camera or the phone, but instead your app asks for an image or initiate a call and the user then picks the app most appropriate for the task. In the case of a photo the user might pick it from the gallery, the wallpapers or shoot a new photo with the camera app. You then get the photo back as a file blob. The code is incredibly simple:"
https://hacks.mozilla.org/2013...
It's a form of the https://en.wikipedia.org/wiki/...
Correction, I checked:
The W3C Working group has NOT yet committed themselves to adopting the ORTC API from the community group.
So basically, Microsoft is still on their own. The browser API is not a standard yet and it might still change before it is part of the real WebRTC standard.
You are partly correct.
WebRTC has 2 parts: protocols & codecs (RTCWeb WorkingGroup at the IETF) and the browser API (WebRTC at the W3C). Al lot of the people are the same people.
All parts of WebRTC was already being worked on before Microsoft really got involved. And Microsoft wanted a more low level browser API than the other WebRTC browser API that was already being worked on. Microsoft wanted this for things like Skype.
Eventually a new community group (not workgroup) was formed at the W3C to work on a new API called ORTC.
The working group at W3C that works on WebRTC have committed themselves to adopt ORTC. So now WebRTC has 2 APIs, only Microsoft has an implementation of ORTC. Firefox, Chrome/Chromium and Opera have an other. And it looks like WebKit/Safari will get WebRTC support too.
The older API is easier to use, because the newer API is more low level, but there are or will be Javascript libraries which will present you with one API which should work with both.
Having a low level isn't such a strange thing any more in browser/webdevelopment land, because as it turns out you can have Javascript libraries which abstract the stuff most don't need to know. Because a lot of times webdevelopers use those anyway, to abstract the differences between browsers.
It's starting to look like more and more browser APIs will be more low level, so high level APIs can be built on top and changed more easily.
Lots of people/companies who work together at the W3C have now basically made this policy:
https://extensiblewebmanifesto...
Doesn't matter how we slice or dice it, storage is where the excitement should be.
And Germany, like before with solar (and wind), is putting their money behind it to develop more and better systems for it.
See the kinds of prediction by the Deutsche Bank are making for 2017 for solar even:
http://reneweconomy.com.au/201...
I think they are right as long as Swanson's law for Solar and keeps working. Batteries are also still improving, if slowly.
Their predictions, like 2017, seem kind of early. But let's say it's 2020, maybe including a storage subsidy, I don't think it's impossible.
If you are worried about that, add some CSP (Content Security Policy) headers to the hosted HTML file.
Just run a 100k webserver with an embedded single HTML file running on 127.0.0.1
I like how you can do both too (doesn't work with shortners):
data:text/html,onload=function () { document.write (document.location.hash) }#whatever
Kristov Atlas: Fear Not the Silk Road (Full speech w/ slides)
https://www.youtube.com/watch?...
His intro is pretty long, so maybe you want to skip that:
https://www.youtube.com/watch?...
A big part from what he says is:
Dark markets can circumvent capital controls:
- tax avoidance (with the multiple layers of taxes, dark markets are a lot cheaper)
- trade barriers (trade anything with anyone)
"When everyone can code there will be no such thing as a "web service" API because enough people would have been smart enough to spend their time developing useful transports rather than always relying on the lowest common denominator/lowest hanging fruit (e.g. http)."
I think this is an interesting discussion, but only if you are looking at the future. Because I'm much more optimistic about the future of http.
First off, yes it would be good to have certain applications use their own protocol.
But having a standardized protocol really helps. Especially if you combine it with something like REST and json and use standard libraries (like libcurl) for that.
http is stateless which means you can easily proxy it.
Now http 1.1 isn't a great protocol, it's old.
But http 2 solved a bunch of parts which needed to be solved like:
less overhead (for example for the headers)
no head of line blocking
multiple streams in the same connection
It didn't get a websocket protocol though, so no tcp like behaviour. Obviously the websocket protocol itself can already do that.
Why would you want something like websocket ?
Because the people who make the standards are working on improving the underlying layers for https (tls) and tcp as well.
Look at what Google has done with quic:
zero roundtrip connections (thus better than plain tcp, it can do that because it uses udp)
multipath support
always uses (datagram)tls so it uses security
The tls 1.3 specification which the ietf (which makes protocols like tcp and http) is adding the pieces needed for a quic like protocol.
I think in a few years a http 2 over quic like tls 1.3 will be in widespread use.
To the developer it looks like http 1.1 but underlying transport will be secure, low latency and fast and it will be part of the library you use.
When you look at what the dns workinggroup is doing, I wouldn't be surprised if they adopt tls 1.3 as a transport well. Because they want to get privacy for the dns protocol as well.
Now if you think we need a more peer2peer and distributed model then I agree. But if you look at the most popular peer2peer application, bittorrent, is even inspired and partly based on http.
If you combine namecoin and some of the dnssec protocol then you can have: .bit )
no central root (for at least part of the namespace, namecoin uses
distributed blockchain based dns names
certificated tied to dns names
certificate validation by the client library when connecting to a http 2 host
local validation of dnssec information which can be used as an anchor to store your public keys
What is the result of all of the above ?:
no use for Certificate Authorities other than maybe 'green bar' if you really want it
no icann
standardized protocols by people agreeing and writing things down
possibility to use http semantics for web and distributed or peer2peer protocol without the overhead
secure by default because of encryption
support for multipath and low latency communication
open source libraries
PS I wrote all the abbreviations in non-caps and removed all the dashes, because I encountered the lameness filter
How about touch in virtual reality ?
OK, I'll say it, because someone will anyway: how about touch, virtual reality and porn ? ;-)
You are thinking about how we encode our data.
Maybe they've deliberately created a way to be less detectable going up in the noise.
Not only that, if you really care about this problem. You need to not have the encryption keys on a machine you don't trust. I would keep the server hardware close.
Don't use VMs or servers cloud/hosting providers (maybe dedicated colo-servers in a cage with an alarm on it ?). Or host it yourself. That is the only way to be sure who has access to the hardware.
Also keep it in the same jurisdiction as yourself, dealing with multiple governments just makes things more complicated.
Some more background about the (US) laws from a European perspective:
http://media.ccc.de/browse/con...
Everything else is just silly business because there is no way encryption can safe you from an attacker with physical access.
Just look at all the buggy IPMI implementations. You have to remember these devices have direct access to RAM (if you decrypt/encrypt data on the server, that is where your unencrypted data is).
Unless: you are only storing encrypted data, you probably don't need machines/VMs for that.
Or your application needs to be designed and build to only store/use encrypted data on the server, like with homomorphic encryption:
https://www.youtube.com/watch?...
And the designed for homomorphic encryption part is important, so you don't leak any data by accident.
If they are only a little bit more advanced then our civilization they've probably encrypted all their communication, maybe even encoded it in such a way that it will be hard to distinguish from cosmic noise. If they don't want to be found, they'll be hard to find.
I thought they knew how they want to do Electrolysis without breaking addons to much and how to fairly easily fix any broken addons.
But recently when they said they would move to supporting WebExtensions this could mean a delay of the transition.
It's the right idea in the long term of course.
I wonder what the impact will be on the number of users Firefox has if the advantage of addons ecosystem gets smaller.
Fastest will probably be 'Servo', which is the new browser engine by Mozilla.
It's a parallel browser engine, it can render multiple parts at the same time:
https://www.phoronix.com/scan....
It's also written in Rust a language probably less prone to security issues than C++ (which all the other engines are written in).
A general article about Servo:
https://lwn.net/Articles/64796...
Not saying it's the best thing since sliced bread. Just saying some large websites made it work well for them and they kept using it. They didn't go back to how they were doing it before.
They are talking about making content available everywhere forever.
The IPFS article links to a YouTube video ( https://www.youtube.com/watch?... ) which 'the uploader did not make available to your country'.
Well, that's funny, because the video isn't their original content. The content was produced in my country by a public broadcaster (aka publicly funded TV).
Never noticed that problem.
But I hear people say the same thing about Chrome. But only on machines that have the RAM available.
And they both share the same V8 Javascript engine. So I assume V8 just keeps RAM if it's available.
Ohh, and Paypal too: https://www.paypal-engineering...
Also not a small website.
Large parts of the of the user-facing websites of Walmart are running on node.js
That's also a popular website ;-)
https://popcorntime.io/ which is used by a good chunk of people around the world is written in 'node-webkit'. So node.js with Webkit. Webkit is used for running the HTML-/CSS-/JS-frontend and node.js is used to start and run the Javascript code which for example has the bindings for the bittorrent library.
The transport of packages isn't a good example of a well working sector. The price delivery people get paid per package has dropped to an unsustainable low.
Not surprising because when you order online delivery most of the time is 'free'. Doesn't matter if you order directly from China or from a company in your own town.
Ahh, that is what you mean. Yes, I can see now how you'd call it more capitalistic.
I do think it was a mistake to sell some of those national state owned companies. I hear English rail is kind of a mess. Ironically the well run train companies are usually partly state-owned by foreign European countries. ;-)
Yes, I agree it's a better system in the Nordic countries. They spend a lot of money on education and at least one makes it easy to fire people but also spend a lot of money and effort on getting the unemployed new work while they keep almost all of their previous salary in the mean time. Creating a more flexible workforce at a high cost of the tax payers (which I assume leads to a big positive overall).
Let's say when I think of big state/lots of taxes capitalism isn't my first association.
Can you explain what you mean with: socialist French and welfare state Nordic countries ? Because I would lump them all in the same category, but you clearly have 2 different categories.
I'm from Europe and I would think I know more about European countries than the average US citizen, so maybe it's just a cultural divide why I don't understand what you mean.
Do you really believe you can easily find developers that are really good at security code auditing and fixing security issues or use other developers and let them fix these security issues. I don't think these things are related.