"The Amazon Browser Apps may also collect information about the websites you view, but that information is not associated with your Amazon account or identified with you. "
"The Alexa functionality in the Amazon Browser Apps collects and stores information about the web pages you view. In some cases, that information may be personally identifiable, but Alexa does not attempt to analyze web usage data to determine the identity of any user. "
I find it exceptionally sick and depressing a toolbar which advertises itself to give user quick access to amazon feels a need to go one step further taking advantage of the same customer to spy on or facilitiate the spying on all of their activity. Is the amazon toolbar really not self-serving enough?
Added *.amazon.com to my DNS block list and now I feel slightly better.
Really fixing any of these issues will take decades due to TCP's position at the bottom of the stack.
Oh nonsense these extensions are all fully backwards compatible and quite reasonable to implement. Vendors reap tangable value to all TCP applications not just web browsers by implemention.
Here is some reading for you, just below the first page, you can see some "real-world" tests against 25 of the top 100 websites in the world using SPDY, which HTTP 2.0 borrows from
Hey great, a real world test without use of HTTP 1.1 pipelining, fast open or fast start. Sign me up.
The FAQ is full of wishful thinking and hyperbole..
"Q: Doesn't HTTP pipelining already solve the latency problem?"
"No. While pipelining does allow for multiple requests to be sent in parallel over a single TCP stream, it is still but a single stream (either a long request at the head-of-line or packet loss) will delay the entire stream"
Yea well head of line applies to SPDY and everything else layered atop TCP so no help there. Server stall is interesting but only applies for dynamic assets and a faster server would help. You also have several concurrent TCP sessions from which to suck down other content in the interim.
Furthermore header compression is not something to be proud of... It is dangerous cuz it leaks signals that can be used to infer encrypted content.
Block protocols that do handshaking perform poorly over high latency links. Windowing protocols fixes this by having always data flowing.
??? What is a block protocol? Using TCP fast open you can begin to transmit your request before the first round trip completes.
HTTP 1.1's keep alive pipelining, is a form of handshake, where not until the receiver gets the very last byte can it then transmit that it wants something else. Multiplexing is the fix, by always having data flowing since there is another resource to send.
RFC2616 section 8.1.1 "HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time."
Similar things occur because of packet loss in HTTP 1.1. Since the receiver can't begin to request anther resource until it has finished receiving the prior one, the packet loss effectively stops/pauses the transmission until a new packet is received. HTTP 2.0 fixes this because another resource can be requested at any time, and the server can even send down resources the client hasn't requested yet.
The assertion requests can't be queued is false. This makes HTTP 2.0 just as bad as HTTP pipeline in face of stalls from packet loss. The only way to mask stalls is by having multiple concurrent TCP sessions or use a message oriented protocol that does not suffer from head of line blocking. (e.g. not TCP)
but the tradeoff is it can transfer a ton of data over one TCP socket, greatly simplifying the network layer of HTTP
One thing it does not do is make anything more simple. Everything that was there must still be there plus a whole lot more.
, and most certainly adding a lot of performance. For webserver admins, this will make life a lot easier
This is not at all clear to me. Perhaps faster over fat low latency links sending hundreds of little thumbnail images... however vs multiple concurrent TCP sessions on high latency lossy links you are HOL stalled by multiplexing within TCP.
Concurrent TCP sessions has been a reasonably effective way of masking TCP/HTTP shortcommings. If you throw in some newfangled TCP options such as fast open/start even over reasonable links I would be surprised to see any difference v HTTP pipelining in real world benchmarks.
And aint it swell to hear they have chosen to reserrect CRIME attacks with header compression.
We have failed to provide basic communication infrastructure that protects the end user.
Expecting people to use optional add-on technology requiring x additional software and y additional knowledge is obviously not going to happen regardless of how small x and y can be made.
The only way to fix the problem is wholesale replacement of existing bullshit (e.g. SMTP) with a solution that is secure by default. Users simply must not have the choice of skipping rational and meaningful key exchange steps before communication. It can be made easy or hard to give users control of the security tradeoff but it must not be optional.
The reason people are upset is that they fear that their government will use information about us against us. We worry that if our motives are misconstrued we will be sent to prison and forgotten about.
Some want to be left alone and not have their every move constantly evaluated and analyzed.
Some want to protect the government from corruption caused by unchecked aggregation of power.
Some don't trust individuals within the government with access to very creepy privledged information. Plenty of LEAs have been convicted of stalking.
There is no practical way for the government to actually spy on all of its citizens.
I would have said there is no practical way to construct a single datacenter with the capability to store five billion terrabytes but it is being constructed anyway.
How many years of global production does it even take all remaining drive manufacturers operating full tilt to produce one billion 5 terrabyte drives or any combination yielding the same capacity? Or you could go with archival media but here your ability to mine it is degraded.
The moral of this story in a contest between the naysayer and those with a will to find a way the naysayers often end up on the loosing side.
Good laws of this sort are those which do not impose technical solutions but rather provide general systems level requirements.
The problem with "duh use encryption" there is no guarantee of any kind simply applying encryption makes a system more secure against a specific threat.
Every time you get into the weeds you are guaranteed to codify errors and hurt those who choose to innovate using different but better or equally valid approaches.
The NSA does not need back doors nor do they need to nerf primitives. We are clearly incapable of effectivly using the crypto we have.
Planet sized trust anchors, unflinching leaps of faith, widely deployed password authentication schemes vulnerable to offline attack. New such schemes continue to be invented and advanced. Just last week I stumbled on idiots from Avaya submitting an I-D to add more hash algorithms (SHA-*) to http digest authentication cuz MD5 is "broke". You can't make this shit up if you tried. The problem with "open standards" is not NSA subversion it is the lack of thought by those producing and reviewing standards.
We accept a world where all primary means of network communication are insecure by default. Email, SMS, mobile calls, IM. Those niche systems which deploy crypto either punt key management or do it soo poorly as to be unusable to most.
"To the cloud" campaigns have mostly resulted in vendors having control of all your data and all your keys.
There are a few outliers where developers have actually put trust management front and center rather than punting or ignoring it. The problem is these channels currently account for rounding error quantities of information flows.
.... but unless they have the worlds top obfuscating coders working there (quite possible) , how long do you think it would be until someone spots the suspect code especially in something as well trodden as the Linux kernel or GNU utilities? I would guess not too long.
I wish people would stop clinging to such foolishness.
We need only look to our historical track record of *innocent* mistakes taking the form of expliotable vulneribilities discovered years or decades after the fact.
Look what was revealed in the linux kernel as a result of a few coverity scans.
Nor is it even necessary to expliot a "well trodden" module to compromise a system.
The profit potential for a MS content *consumption* platform may be greater than the traditional desktop and MS is trying - desperately, having come *way* late to the game - to capitalize on that. If they have to throw the (perhaps declining) legacy user base under the bus to achieve market share they will - in a heartbeat. Loyalty is to the bottom line
The problem with this thinking is many of the same people who have a need for desktop computers buy or influence the purchase of server / backoffice SKUs. Unecessarily pissing them off has second order effects over Microsofts entire "ecosystem".
In the early days of "big data" stores would look at the numbers and stop carrying certain goods when they did not individually meet profit thresholds.. only later did they find out their own narrowly focused policies were causing them to loose money in the aggregate as people preferred to shop in one place where they can get all of the items they wanted without driving all over town.
I understand there are people who would be happy without a desktop. These people have ever only owned computers to send email or browse the web. They now have more choices which better fit their usage patterns. Good for them and good for vendor innovation in this domain.
Pissing off the subset of users who do not fall into the above category for no technically necessary reason is ultimatly counterproductive to Microsoft and Microsofts shareholders.
Yeah, there's a Start button. Big deal. All it does is drop you into Metro -- pardon me. Into The-Interface-Formerly-Known-As-Metro. There's still no Start Menu, which is what the "I want the Start Button" was all about.
This is what happens when you go and make deals wih the devil. You get what you asked for.
Nope. Suppose you have 1% packet loss. By sending 1/50 of your data as parity packets, you can avoid most retransmition delays. Sending duplicate packets also works, but is a naive trivial case. There are much more sophisticated approaches as well (LDPC, hamming codes etc). Regardless, there are many cases where a round trip delay is way worse than a a small increase in data size, so selectively doing FEC where it is beneficial can be very useful. QUIC has the info to know when its beneficial.
Read the design document again.. they say key packets in session setup can be proactivly duplicated..later they explicitly state that simple packet duplication counts as "FEC".... FEC is normally implemented within or below the packetization layer within the link where it makes sense and can scale to replace individual corrupted symbols in the transmission stream..when you get to the packet layer your severly constrained if you don't fill the MTU you are wasting resources. Correction codes will either consume more bandwidth or have very limited ability to do anything about packet loss. There just are not enough packets transmitted within the lifetime of the average http session for this to work in practice without substantial overhead. Also there are scary second order effects to think about. Increasing data consumption in response to congestion can very easily become a cause of more congestion.
I wasn't aware of any that were part of the standard TCP stack, but there may be some.
Congestion algorithms typically have no corrosponding expression on TCP data fields transmitted over the wire. It is simply a discipline controlled by the operating system. There have been quite a number of them developed over the years.
Nothing prevents this from being done, but I don't think it is. Its easier to do with QUIC, and standard.
Why? QUIC is currently not a standard and people have been talking about correlated behaviors to set ICW and friends for a long time.
If you want to oppose my claim that that Google is "Google is aware of network congestion problems" right after asserting everyone is aware of it, go ahead, but I'll just think you are silly.
Being aware of a problem does not mean you have the skills or resources necessary to correct the problem. Just because I know my car broke down it does not automatically follow I have any idea how to fix it. Everyone knows the importance of congestion avoidance. I suspect very few are actually smart enough to advance the state of the art.
The problem with google from tcpm lurking is that when they say we have reduced x by y they stop their analysis and assume victory. There is no talk about second order effects sometimes present in their own data.
Content networks see different traffic flows from that of an eyeball or transit network. The upstream channel of an eyeball network is mostly nill...networks with more symmetric traffic should be accounted for as well. It has to be more than google says to be applicable to the whole Internet.
TCP has some major issues with congestion control that isn't playing well with buffer-bloat.
Nothing plays well with buffer bloat thats why you fix buffer bloat.
The Internet is bursty in nature. TCP takes too long to ramp-up.
This is what TCP quick start is for.
but one of the big issues that is starting to become a problem as speeds increase but latency is staying fixed, is the congestion control. Because TCP starts off slow and ramps up, it tends not to make use of available bandwidth. Un-used bandwidth is bad.
Path oversubscription is far worse.
The other issue is current TCP uses packet-loss to decide when to back off.
What else would it use?
The issue this creates is packet-loss tends to affect a lot of connections at the same time. You get this synchronization where lots of computers experiencing packet-loss all at the same time, so they all back-off at the same time. Suddenly the route is under-utilized. All of the connections start building up again until the route is over-utilized, then they all back-off at the same time.
Hence the jitter parameter in the retransmit timer computation.
This issue alone could possible cause large portions of the Internet to fail. It has happened in the past and the variables are getting to be similar again. Essentially you're left with a large portion of the Internet routes in a constant violent swing between over-utilized and under-utilized.
The historical congestive collapses occured because nobody was using any congestion control.
There is a lot of theory on how to fight these issues, but the only real way to figure this out is
And RFCs and working code even. The year is 2013...please adjust your chronometer accordingly.
Wrong. QUIC is better at congestion control than TCP, and is fair when used along side TCP. QUIC monitors both packet loss, and latency which gives it more information than TCP for flow control.
BS there are a number of congestion algorithms for TCP that use latency.
The ACKs also include proof of received packets so an invalid ACK attack to cause a server to flood a network (which works with TCP) does not work with QUIC
ACK attack requires guessing sequence numbers or being able to spy on the data path which severly limits the usefulness vs much much lower hanging fruit (DNS/chargen amplification)
QUIC also optionally (when beneficial) includes FEC to recover lost packets so it can still detect congestion via packet loss
Yea "FEC" as in sending duplicate packets from what I've read.
but without the retransmittion delay TCP gets.
I don't understand this shit. If there is no cost then how can there be meaningful congestion avoidance? TCP has fast retransmit why is that not enough?
Also, the multiple multiplexed streams over QUIC get to work together to collect congestion information, which further provides an advantage for congestion control over TCP.
Hu? What prevents the OS vendor from using data from multiple TCP sessions as input to a congestion decision?
In short: QUIC is much better at congestion control than TCP, and suffers less latency from the Packet loss used to signal the congestion.
In short the points you offered to get to this conclusion only make sense if you pretend TCP = RFC 793 and ignore decades of innovation.
There may be some cases that are not covered yet, but the design doc clearly shows that Google is aware of network congestion problems has the problems mostly (if not complexly) solved at least
This is nothing new. Everyone is aware of the importance of congestion avoidance.. thanks in no small part to IETF D.A.R.E campaign (Datagram Abuse Resistance Education)
as well as TCP, but likely better. Asserting Google does not know how to control congestion on a network is troll worthy: Google runs a huge global network.
Reducing RTT for connection setup and encryption is a nobel goal yet I'm not clear on why technically this can't be solved without the reinvention of TCP over UDP.
TCP fast open coupled with TLS session tickets/snap start offers essentially the same possibility for actual transmission of an encrypted request before completion of first round trip.
Multiple concurrent TCP streams normally end up having much the same properties as multiplexed UDP in the aggregate so I don't buy head of line koolaid either.
What I think is really going on here they want an excuse to bring congestion control algorithms into user space where they can program whatever congestion algorithms they want into their browser and bypass having to deal with the OS vendors.
The design of congestion algorithms is a black art... I worry about algorithms designed using data from google networks not generally applicable to the Internet or otherwise too aggressive which could ultimatly give browser vendors and sites an unfair advantage or prove to be detremental to the larger Internet.
Even in their text they talk about "speculative" double posting of packets just to mitigate against the *possibility* of incurring delays due to dropped packets. There must some kind of real pain felt when packet loss occurs otherwise things turn to shit. Google is always blabing away about "tail loss" and avoiding the dreaded RTO but they never seem to care about the repercussions.
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection? TCP uses the overhead caused by ACK packets as a rate limiter on clients.
The "zero" RTT is like TLS session resumption or session tickets in that it only works by assuming a set of initial parameters. If it fails then you fallback to additional rounds to hello/ handshake TLS parameters.
But equally there are thousands of really talented programmers who examine the source code very thoroughly, many of whom contribute back.
Not really, most of each of thousands of projects have at most a few core developers and extraneous people who occasionally submit patches to fix specific itches. There is no "A team" scouring all open source for vulnerabilities from the simple fact such vulnerabilities most certainly do exist as innocent bugs and have not been reported by such teams.
To illustrate this point the linux kernel is developed by armies of smart people yet an automated tool found a laundry list of shit that has been around for years nobody noticed.
If there were back doors then there is a high chance that they would have been detected.
There is no difference between a backdoor and a vulnerability. The logic that deliberate backdoors would be detectable in source code when we know from experience innocent bugs having the same effect as a backdoor have a proven track record of not being detectable is simply wishful thinking and wrong.
Plus anyone really paranoid about it CAN go and check the source code to make sure for themselves.
I suppose anyone can drain the earths oceans with an eye dropper as well.
Most times I would end up walking the floor its because I am interested in the technology or possibly talking with engineering folks much smarter than myself who sometimes get let out of their cages and are able to attend.
When I see a booth filled with babes and well dressed sales guys picking their noses it is a huge turn off when I go to their booth I can always expect to find extraneous people with no domain knowledge and sales goons knowing less about their own product than I.
There are plenty of booths with attractive women who actually work for the company and know their shit. Much more of a turn on to me than supermodels standing around looking pretty.
Have not attended mass market consumer oriented shows. Something like E3 I can see being a different matter entirely where more chicks always make things better.
The problem with W3C's argument is it fails to recognize the enormous market value in making sure content is accessible to most number of eyeballs possible.
If megamediacorp wants to distribute content anywhere to any device any browser then they can't use technology not widely deployed or implemented. For example requiring third party plugins could provide missing functionality but they take a hit in knowing their content is not universally reachable.
If instead you just give in and widely implement whatever blackbox content feels will protect their content today then media companies no longer feel any pressure not to DRM/encrypt EVERYTHING and before you know it all content is DRM'd.
As a practical matter I never understood the DRM issue as the simple truth is that if you can decrypt it to view it you can certainly copy it. The only way for DRM to actually work is a fully trusted environment where the user is denied full access to their devices and physical hardware is tamper proof. Even if this were achivable nothing stops out of band re-recording of media. Not only is DRM evil but it is pointless... a total waste of time and resources as were the DVD and Blueray copy protection schemes. It can't work unless everyone is denied the right to own a general purpose computer.
As a system admin, I tend to use WHOIS to figure out who is hitting my firewall, or to investigate if traffic is flowing to suspicious domains. Would really suck if WHOIS became a pay service, making it easier for the bad guys to hide.
Number lookups are driven by a completely separate system and governance structure from domain record lookup.
Stupid question bonus round.. wouldn't this cut into domain privacy surcharges all yer registrar friends try and rake in? I mean if records can no longer be accessed by joe spammer such privacy services become useless...don't it?
I for one would fully support abolishing ICANN and replacing it with an institution that at least tries to care about what is actually best for the Internet. We see failure after failure in policy from ICANN consistantly doing what is good for business regardless of its effect on the network. e.g. TLD sprawl and ongoing "study" designed to greenlight "dotless" names. Sheer madness. Shame we continue to allow them to get away with being a bunch of greedy little pricks.
Slashdot Mirror
"The Amazon Browser Apps may also collect information about the websites you view, but that information is not associated with your Amazon account or identified with you. "
"The Alexa functionality in the Amazon Browser Apps collects and stores information about the web pages you view. In some cases, that information may be personally identifiable, but Alexa does not attempt to analyze web usage data to determine the identity of any user. "
I find it exceptionally sick and depressing a toolbar which advertises itself to give user quick access to amazon feels a need to go one step further taking advantage of the same customer to spy on or facilitiate the spying on all of their activity. Is the amazon toolbar really not self-serving enough?
Added *.amazon.com to my DNS block list and now I feel slightly better.
I've found the best way to get developers to stop being lazy is to give them shit hardware.
The mistake is buying the latest quad core 2GB android goodness... Give them a 5 yr old piece of shit and the resulting mobile apps will rock.
1. Using many TCP connections circumvents congestion control.
If that were true TCP congestion control would be pointless wouldn't it... Many TCP connections is exactly what the Internet does 24x7.
TCP requires a handshake for each connection, adding overhead
http://en.wikipedia.org/wiki/TCP_Fast_Open
TCP slow start must be repeated for every connection, adding overhead
Did I mention fast open?
http://en.wikipedia.org/wiki/TCP_Fast_Open
Really fixing any of these issues will take decades due to TCP's position at the bottom of the stack.
Oh nonsense these extensions are all fully backwards compatible and quite reasonable to implement. Vendors reap tangable value to all TCP applications not just web browsers by implemention.
Here is some reading for you, just below the first page, you can see some "real-world" tests against 25 of the top 100 websites in the world using SPDY, which HTTP 2.0 borrows from
Hey great, a real world test without use of HTTP 1.1 pipelining, fast open or fast start. Sign me up.
The FAQ is full of wishful thinking and hyperbole..
"Q: Doesn't HTTP pipelining already solve the latency problem?"
"No. While pipelining does allow for multiple requests to be sent in parallel over a single TCP stream, it is still but a single stream (either a long request at the head-of-line or packet loss) will delay the entire stream"
Yea well head of line applies to SPDY and everything else layered atop TCP so no help there. Server stall is interesting but only applies for dynamic assets and a faster server would help. You also have several concurrent TCP sessions from which to suck down other content in the interim.
Furthermore header compression is not something to be proud of... It is dangerous cuz it leaks signals that can be used to infer encrypted content.
http://en.wikipedia.org/wiki/CRIME_(security_exploit)
Block protocols that do handshaking perform poorly over high latency links. Windowing protocols fixes this by having always data flowing.
??? What is a block protocol? Using TCP fast open you can begin to transmit your request before the first round trip completes.
HTTP 1.1's keep alive pipelining, is a form of handshake, where not until the receiver gets the very last byte can it then transmit that it wants something else. Multiplexing is the fix, by always having data flowing since there is another resource to send.
RFC2616 section 8.1.1
"HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time."
Similar things occur because of packet loss in HTTP 1.1. Since the receiver can't begin to request anther resource until it has finished receiving the prior one, the packet loss effectively stops/pauses the transmission until a new packet is received. HTTP 2.0 fixes this because another resource can be requested at any time, and the server can even send down resources the client hasn't requested yet.
The assertion requests can't be queued is false. This makes HTTP 2.0 just as bad as HTTP pipeline in face of stalls from packet loss. The only way to mask stalls is by having multiple concurrent TCP sessions or use a message oriented protocol that does not suffer from head of line blocking. (e.g. not TCP)
but the tradeoff is it can transfer a ton of data over one TCP socket, greatly simplifying the network layer of HTTP
One thing it does not do is make anything more simple. Everything that was there must still be there plus a whole lot more.
, and most certainly adding a lot of performance. For webserver admins, this will make life a lot easier
This is not at all clear to me. Perhaps faster over fat low latency links sending hundreds of little thumbnail images... however vs multiple concurrent TCP sessions on high latency lossy links you are HOL stalled by multiplexing within TCP.
Concurrent TCP sessions has been a reasonably effective way of masking TCP/HTTP shortcommings. If you throw in some newfangled TCP options such as fast open/start even over reasonable links I would be surprised to see any difference v HTTP pipelining in real world benchmarks.
And aint it swell to hear they have chosen to reserrect CRIME attacks with header compression.
Most popular protocol? What ever happened to TCP?
From looks of the draft it has been reimplemented within HTTP.
We are the problem not the end user.
We have failed to provide basic communication infrastructure that protects the end user.
Expecting people to use optional add-on technology requiring x additional software and y additional knowledge is obviously not going to happen regardless of how small x and y can be made.
The only way to fix the problem is wholesale replacement of existing bullshit (e.g. SMTP) with a solution that is secure by default. Users simply must not have the choice of skipping rational and meaningful key exchange steps before communication. It can be made easy or hard to give users control of the security tradeoff but it must not be optional.
The reason people are upset is that they fear that their government will use information about us against us. We worry that if our motives are misconstrued we will be sent to prison and forgotten about.
Some want to be left alone and not have their every move constantly evaluated and analyzed.
Some want to protect the government from corruption caused by unchecked aggregation of power.
Some don't trust individuals within the government with access to very creepy privledged information. Plenty of LEAs have been convicted of stalking.
There is no practical way for the government to actually spy on all of its citizens.
I would have said there is no practical way to construct a single datacenter with the capability to store five billion terrabytes but it is being constructed anyway.
How many years of global production does it even take all remaining drive manufacturers operating full tilt to produce one billion 5 terrabyte drives or any combination yielding the same capacity? Or you could go with archival media but here your ability to mine it is degraded.
The moral of this story in a contest between the naysayer and those with a will to find a way the naysayers often end up on the loosing side.
Good laws of this sort are those which do not impose technical solutions but rather provide general systems level requirements.
The problem with "duh use encryption" there is no guarantee of any kind simply applying encryption makes a system more secure against a specific threat.
Every time you get into the weeds you are guaranteed to codify errors and hurt those who choose to innovate using different but better or equally valid approaches.
The NSA does not need back doors nor do they need to nerf primitives. We are clearly incapable of effectivly using the crypto we have.
Planet sized trust anchors, unflinching leaps of faith, widely deployed password authentication schemes vulnerable to offline attack. New such schemes continue to be invented and advanced. Just last week I stumbled on idiots from Avaya submitting an I-D to add more hash algorithms (SHA-*) to http digest authentication cuz MD5 is "broke". You can't make this shit up if you tried. The problem with "open standards" is not NSA subversion it is the lack of thought by those producing and reviewing standards.
We accept a world where all primary means of network communication are insecure by default. Email, SMS, mobile calls, IM. Those niche systems which deploy crypto either punt key management or do it soo poorly as to be unusable to most.
"To the cloud" campaigns have mostly resulted in vendors having control of all your data and all your keys.
There are a few outliers where developers have actually put trust management front and center rather than punting or ignoring it. The problem is these channels currently account for rounding error quantities of information flows.
.... but unless they have the worlds top obfuscating coders working there (quite possible) , how long do you think it would be until someone spots the suspect code especially in something as well trodden as the Linux kernel or GNU utilities? I would guess not too long.
I wish people would stop clinging to such foolishness.
We need only look to our historical track record of *innocent* mistakes taking the form of expliotable vulneribilities discovered years or decades after the fact.
Look what was revealed in the linux kernel as a result of a few coverity scans.
Nor is it even necessary to expliot a "well trodden" module to compromise a system.
The profit potential for a MS content *consumption* platform may be greater than the traditional desktop and MS is trying - desperately, having come *way* late to the game - to capitalize on that. If they have to throw the (perhaps declining) legacy user base under the bus to achieve market share they will - in a heartbeat. Loyalty is to the bottom line
The problem with this thinking is many of the same people who have a need for desktop computers buy or influence the purchase of server / backoffice SKUs. Unecessarily pissing them off has second order effects over Microsofts entire "ecosystem".
In the early days of "big data" stores would look at the numbers and stop carrying certain goods when they did not individually meet profit thresholds.. only later did they find out their own narrowly focused policies were causing them to loose money in the aggregate as people preferred to shop in one place where they can get all of the items they wanted without driving all over town.
I understand there are people who would be happy without a desktop. These people have ever only owned computers to send email or browse the web. They now have more choices which better fit their usage patterns. Good for them and good for vendor innovation in this domain.
Pissing off the subset of users who do not fall into the above category for no technically necessary reason is ultimatly counterproductive to Microsoft and Microsofts shareholders.
Yeah, there's a Start button. Big deal. All it does is drop you into Metro -- pardon me. Into The-Interface-Formerly-Known-As-Metro. There's still no Start Menu, which is what the "I want the Start Button" was all about.
This is what happens when you go and make deals wih the devil. You get what you asked for.
Nope. Suppose you have 1% packet loss. By sending 1/50 of your data as parity packets, you can avoid most retransmition delays. Sending duplicate packets also works, but is a naive trivial case. There are much more sophisticated approaches as well (LDPC, hamming codes etc). Regardless, there are many cases where a round trip delay is way worse than a a small increase in data size, so selectively doing FEC where it is beneficial can be very useful. QUIC has the info to know when its beneficial.
Read the design document again.. they say key packets in session setup can be proactivly duplicated..later they explicitly state that simple packet duplication counts as "FEC".. .. FEC is normally implemented within or below the packetization layer within the link where it makes sense and can scale to replace individual corrupted symbols in the transmission stream..when you get to the packet layer your severly constrained if you don't fill the MTU you are wasting resources. Correction codes will either consume more bandwidth or have very limited ability to do anything about packet loss. There just are not enough packets transmitted within the lifetime of the average http session for this to work in practice without substantial overhead. Also there are scary second order effects to think about. Increasing data consumption in response to congestion can very easily become a cause of more congestion.
I wasn't aware of any that were part of the standard TCP stack, but there may be some.
Congestion algorithms typically have no corrosponding expression on TCP data fields transmitted over the wire. It is simply a discipline controlled by the operating system. There have been quite a number of them developed over the years.
Nothing prevents this from being done, but I don't think it is. Its easier to do with QUIC, and standard.
Why? QUIC is currently not a standard and people have been talking about correlated behaviors to set ICW and friends for a long time.
If you want to oppose my claim that that Google is "Google is aware of network congestion problems" right after asserting everyone is aware of it, go ahead, but I'll just think you are silly.
Being aware of a problem does not mean you have the skills or resources necessary to correct the problem. Just because I know my car broke down it does not automatically follow I have any idea how to fix it. Everyone knows the importance of congestion avoidance. I suspect very few are actually smart enough to advance the state of the art.
The problem with google from tcpm lurking is that when they say we have reduced x by y they stop their analysis and assume victory. There is no talk about second order effects sometimes present in their own data.
Content networks see different traffic flows from that of an eyeball or transit network. The upstream channel of an eyeball network is mostly nill...networks with more symmetric traffic should be accounted for as well. It has to be more than google says to be applicable to the whole Internet.
TCP has some major issues with congestion control that isn't playing well with buffer-bloat.
Nothing plays well with buffer bloat thats why you fix buffer bloat.
The Internet is bursty in nature. TCP takes too long to ramp-up.
This is what TCP quick start is for.
but one of the big issues that is starting to become a problem as speeds increase but latency is staying fixed, is the congestion control.
Because TCP starts off slow and ramps up, it tends not to make use of available bandwidth. Un-used bandwidth is bad.
Path oversubscription is far worse.
The other issue is current TCP uses packet-loss to decide when to back off.
What else would it use?
The issue this creates is packet-loss tends to affect a lot of connections at the same time. You get this synchronization where lots of computers experiencing packet-loss all at the same time, so they all back-off at the same time. Suddenly the route is under-utilized. All of the connections start building up again until the route is over-utilized, then they all back-off at the same time.
Hence the jitter parameter in the retransmit timer computation.
This issue alone could possible cause large portions of the Internet to fail. It has happened in the past and the variables are getting to be similar again. Essentially you're left with a large portion of the Internet routes in a constant violent swing between over-utilized and under-utilized.
The historical congestive collapses occured because nobody was using any congestion control.
There is a lot of theory on how to fight these issues, but the only real way to figure this out is
And RFCs and working code even. The year is 2013...please adjust your chronometer accordingly.
Wrong. QUIC is better at congestion control than TCP, and is fair when used along side TCP. QUIC monitors both packet loss, and latency which gives it more information than TCP for flow control.
BS there are a number of congestion algorithms for TCP that use latency.
The ACKs also include proof of received packets so an invalid ACK attack to cause a server to flood a network (which works with TCP) does not work with QUIC
ACK attack requires guessing sequence numbers or being able to spy on the data path which severly limits the usefulness vs much much lower hanging fruit (DNS/chargen amplification)
QUIC also optionally (when beneficial) includes FEC to recover lost packets so it can still detect congestion via packet loss
Yea "FEC" as in sending duplicate packets from what I've read.
but without the retransmittion delay TCP gets.
I don't understand this shit. If there is no cost then how can there be meaningful congestion avoidance? TCP has fast retransmit why is that not enough?
Also, the multiple multiplexed streams over QUIC get to work together to collect congestion information, which further provides an advantage for congestion control over TCP.
Hu? What prevents the OS vendor from using data from multiple TCP sessions as input to a congestion decision?
In short: QUIC is much better at congestion control than TCP, and suffers less latency from the Packet loss used to signal the congestion.
In short the points you offered to get to this conclusion only make sense if you pretend TCP = RFC 793 and ignore decades of innovation.
There may be some cases that are not covered yet, but the design doc clearly shows that Google is aware of network congestion problems has the problems mostly (if not complexly) solved at least
This is nothing new. Everyone is aware of the importance of congestion avoidance.. thanks in no small part to IETF D.A.R.E campaign (Datagram Abuse Resistance Education)
as well as TCP, but likely better. Asserting Google does not know how to control congestion on a network is troll worthy: Google runs a huge global network.
Google is still just a CONTENT network.
Reducing RTT for connection setup and encryption is a nobel goal yet I'm not clear on why technically this can't be solved without the reinvention of TCP over UDP.
TCP fast open coupled with TLS session tickets/snap start offers essentially the same possibility for actual transmission of an encrypted request before completion of first round trip.
Multiple concurrent TCP streams normally end up having much the same properties as multiplexed UDP in the aggregate so I don't buy head of line koolaid either.
What I think is really going on here they want an excuse to bring congestion control algorithms into user space where they can program whatever congestion algorithms they want into their browser and bypass having to deal with the OS vendors.
The design of congestion algorithms is a black art... I worry about algorithms designed using data from google networks not generally applicable to the Internet or otherwise too aggressive which could ultimatly give browser vendors and sites an unfair advantage or prove to be detremental to the larger Internet.
Even in their text they talk about "speculative" double posting of packets just to mitigate against the *possibility* of incurring delays due to dropped packets. There must some kind of real pain felt when packet loss occurs otherwise things turn to shit. Google is always blabing away about "tail loss" and avoiding the dreaded RTO but they never seem to care about the repercussions.
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection? TCP uses the overhead caused by ACK packets as a rate limiter on clients.
The "zero" RTT is like TLS session resumption or session tickets in that it only works by assuming a set of initial parameters. If it fails then you fallback to additional rounds to hello/ handshake TLS parameters.
But equally there are thousands of really talented programmers who examine the source code very thoroughly, many of whom contribute back.
Not really, most of each of thousands of projects have at most a few core developers and extraneous people who occasionally submit patches to fix specific itches. There is no "A team" scouring all open source for vulnerabilities from the simple fact such vulnerabilities most certainly do exist as innocent bugs and have not been reported by such teams.
To illustrate this point the linux kernel is developed by armies of smart people yet an automated tool found a laundry list of shit that has been around for years nobody noticed.
http://www.coverity.com/library/pdf/linux_report.pdf
If there were back doors then there is a high chance that they would have been detected.
There is no difference between a backdoor and a vulnerability. The logic that deliberate backdoors would be detectable in source code when we know from experience innocent bugs having the same effect as a backdoor have a proven track record of not being detectable is simply wishful thinking and wrong.
Plus anyone really paranoid about it CAN go and check the source code to make sure for themselves.
I suppose anyone can drain the earths oceans with an eye dropper as well.
Most times I would end up walking the floor its because I am interested in the technology or possibly talking with engineering folks much smarter than myself who sometimes get let out of their cages and are able to attend.
When I see a booth filled with babes and well dressed sales guys picking their noses it is a huge turn off when I go to their booth I can always expect to find extraneous people with no domain knowledge and sales goons knowing less about their own product than I.
There are plenty of booths with attractive women who actually work for the company and know their shit. Much more of a turn on to me than supermodels standing around looking pretty.
Have not attended mass market consumer oriented shows. Something like E3 I can see being a different matter entirely where more chicks always make things better.
The problem with W3C's argument is it fails to recognize the enormous market value in making sure content is accessible to most number of eyeballs possible.
If megamediacorp wants to distribute content anywhere to any device any browser then they can't use technology not widely deployed or implemented. For example requiring third party plugins could provide missing functionality but they take a hit in knowing their content is not universally reachable.
If instead you just give in and widely implement whatever blackbox content feels will protect their content today then media companies no longer feel any pressure not to DRM/encrypt EVERYTHING and before you know it all content is DRM'd.
As a practical matter I never understood the DRM issue as the simple truth is that if you can decrypt it to view it you can certainly copy it. The only way for DRM to actually work is a fully trusted environment where the user is denied full access to their devices and physical hardware is tamper proof. Even if this were achivable nothing stops out of band re-recording of media. Not only is DRM evil but it is pointless... a total waste of time and resources as were the DVD and Blueray copy protection schemes. It can't work unless everyone is denied the right to own a general purpose computer.
That's the phrase everyone has wanted to hear, including myself. Microsoft may have backpedaled, but that was the right thing to do.
This is so disingenuous that it qualifies as an outright lie.
As a system admin, I tend to use WHOIS to figure out who is hitting my firewall, or to investigate if traffic is flowing to suspicious domains. Would really suck if WHOIS became a pay service, making it easier for the bad guys to hide.
Number lookups are driven by a completely separate system and governance structure from domain record lookup.
Stupid question bonus round.. wouldn't this cut into domain privacy surcharges all yer registrar friends try and rake in? I mean if records can no longer be accessed by joe spammer such privacy services become useless...don't it?
I for one would fully support abolishing ICANN and replacing it with an institution that at least tries to care about what is actually best for the Internet. We see failure after failure in policy from ICANN consistantly doing what is good for business regardless of its effect on the network. e.g. TLD sprawl and ongoing "study" designed to greenlight "dotless" names. Sheer madness. Shame we continue to allow them to get away with being a bunch of greedy little pricks.