It has no support for OTR, which is the most widely supported multi-protocol encryption standard. They're working on supporting it now, but it isn't there yet, and I think the major distributions should've waited to make it the default IM client until OTR support was there.
*woosh* You failed to understand the point. Mark Cuban's article itself does not constitute tortious interference, but the scheme he describes would, if enacted.
After reading the Wikipedia article I think you are definitely correct. There is a case to be made that this behavior would constitute tortious interference. The parent deserves to be modded up.
Oh, no! I missed a negative in a widely used idiomatic phrase that most people already know. Oh, the horror of misunderstanding that I've caused, it's simply dreadful!
I happen to be precisely aware of exactly what the bureaucratic stupidity was, and that wasn't it. Now it is possible that slightly later in the hiring process the difficulty you describe might have come to pass.
Google was all set to offer me a job and it fouled on a bit of bureaucratic stupidity. But I passed their technical interview. I have no degree, and my lack of degree didn't figure into the bureaucratic stupidity.
It took a lot of people inside the company recommending me for them to give me a serious interview. But it happened. So the idea that they only hire people with graduate level degrees is a myth.
When I was 15 someone recommended the second book in "The Art of Computer Programming" series by Knuth. It was "Searching and Sorting". I read it.
I knew more about the common algorithms their order, and other details of when they were and weren't useful than your average college graduate before I even got to college. I wrote my own b-tree indexing system when I was 18.
When I was in and/or hanging around college I ended up helping a graduate level student with their AI homework. He didn't understand what a heap was or why it would be useful in an A* search. He didn't know how to code a linked list.
That stupid piece of paper is nearly meaningless. And when I've interviewed people it was only a minor data point. I usually used their time at college to probe how much they remembered about the stuff they did work on and whether or not they had a fine grasp of the details. I could care less about their degree or their grades.
It is irritating to see the birth of yet another corporate-speak word. Unfortunately I don't think incite is going to ever be a good replacement. Incite has the strong connotation of encouraging someone to do something bad instead of something good.
Unfortunately, given its origins, "incentivize" is likely to acquire the same connotation over time.
Well, I've never had a cable modem for a wide variety of reasons. It's always been clear to me that cable companies had no concept of the idea of 'common carrier' and so I have never trusted them.
But all the DSL ISPs I've used, except for the very biggest, have had somewhere around 300-900Mbits to places outside their network. If they have 10000 customers, 900Mbits would give them 90Kbits/customer. Clearly way too low. And at least one of the ISPs I've had that fit this model is extremely customer focused and was very upfront about their network and bandwidth usage and the like. I know they weren't doing badly as an ISP, but I also know they weren't ripping people off.
Clearly, you can't rate limit people down to 90Kbps because that's all the bandwidth you can absolutely guarantee to the outside world. You have to give them really high burst bandwidth. And that strategy works until you get someone who uses the burst bandwidth 24/7 downloading file after file after file. I know those people exist, I lived in a house with one and had to rate limit him so I could have a decent connection (meaning I could remote ssh into my box and be able get 100 millisecond response times when typing instead of several second response times). He finally stopped because my rate limiting caused his bulk downloading to interfere with his game of WoW.
So, what you have to do is make sure that people who are using burst bandwidth get the high speed, and the people who are using bulk bandwidth get the lowest priority. That will generally mean that their download rate actually only goes down a little because the burst bandwidth people don't take much. But if you don't put the bulk downloaders at lowest priority, the burst people suffer, and that's not fair at all.
I disagree pretty strongly. There are people I know of who are constantly downloading as much as they possibly can all the time. No matter what the network capacity increases to they will always eat up all that they possibly can.
I do agree that our infrastructure in the US is really bad and could be improved. And I agree that comcast is pretty deceptive, and I think a lot of DSL providers are also kind of deceptive.
But people who constantly use as much bandwidth as they possibly can are a problem. Perhaps the ISP should advertise 'burst bandwidth 8Mbps, sustained 500Kbps'. That wouldn't really change anything in my opinion.
In almost all networks, no matter how well structured they are, you are going to end up with too little bandwidth between groups than is required to sustain all those nodes communicating with each other at their individual full bandwidth to the network. You want networks structured this way because burst bandwidth is generally a lot more important than sustained, especially between disparate groups of nodes. And in fact it's nearly impossible to have networks structured any differently. Even high speed networks designed to sustain distributed supercomputers have this problem.
No, with this it doesn't matter what coders do. If a node says all of it's traffic is high priority it all gets shoved in the same bucket and that bucket then receives very low priority if it's always the one using up all the bandwidth.
The only way priority will help someone is if they really mark only the things they care about most as high priority, or the ones they care about least as low priority.
Yes, that is the biggest issue as I see it. State tracking.:-/
And yes, this would require you to partition your network into sections where you had enough switch bandwidth for all your customers in a particular section to be able to send data to eachother at full speed. Congestion would be measured at the section boundaries.
So, it's not the easiest solution. But it's a heck of a lot more fair and less suspect than just trying to curb a particular application you don't like.
Maybe they should look at how telecommunications companies are connecting people as the problem instead of how people are using the Internet.
Anyway, to my mind, there are a clear set of traffic shaping policies that satisfy net neutrality and make sure the network is still usable by everyone. And that's to shape by physical connection, not application. I have an 8 megabit DSL line, but I think my ISP has about 450-600 mbits of bandwidth to the Internet. The aggregate bandwidth of all of their DSL customers is likely at least 10 times their available bandwidth to the Internet, and that's a perfectly normal and reasonable situation.
If ever any given connection they have to the Internet becomes saturated, they should prioritize traffic in such a way as to make sure everybody trying to use that connection gets their fair share. That means customers that only burst traffic and aren't using their max for hours get priority over the people who are using as much bandwidth as they can for hours. As the bandwidth becomes more constrained, the criteria for what counts as a burst should become shorter and the max burst bandwidth should be lowered.
Trying to kill off all your bittorrent customers, especially since you think they're competing with your more profitable centralized video distribution business sure seems attractive, but it's evil and all the wrong approach. Just allocate bandwidth fairly to your customers and the bittorrent people will be punished for using all their bandwidth by having molasses web surfing compared to everybody else.
If bittorrent customers don't like this, they can agree to start marking the traffic they want to have as low priority and then that traffic will be the first to go when there's a bandwidth crunch.
Yes. Programs should encourage people to make correct assumptions, not incorrect ones. Programs that lead people to make incorrect ones have design flaws. Such design flaws have killed people in the past.
Not really. What you really want with a sandbox is for a program's every access to system resources outside of a small predefined set to be vetted by the user. SELinux can't really do that.
But, the blog article does give you a really nice way to quickly create an environment for a program to run in that has access to almost no system resources, and while that's not all you want, it is still pretty useful subset.
Most programs that run other programs actually run them in an obvious fashion. The fact that ldd doesn't seem to run the program because it feeds the program an environment variable that causes the program to print out some information and exit leads people to make a bad assumption about how ldd works. In my opinion, this is a really bad design flaw in ldd and should've been fixed years ago.
I know it violated my assumptions about what ldd was doing.
I know the G1 has some DRM issues, and that irritates me. Will this new e-reader also have them? If so, how pervasive and extensive will it be? It sounds like they intend to allow PDF reading. So maybe you can just avoid buying anything with DRM on it?
Ultimately you are arguing for a Pandora's Box's of security. Just because you can't think of a way for one of these URLs to leak out now doesn't mean someone else won't come up with a way to make it happen and once that's the case, there is no stuffing them back into the box of obscurity.
While the rest of your comment is basically correct, though I will point out that I feel that Google's current UI does not make it clear to people exactly what they're sharing, I do take objection to this.
The browser history is an interesting question, and definitely an avenue in which the URLs may end up with more exposure than a user intends. Though, IMHO, a user is already being inordinately cavalier with security to be doing anything private on a public terminal. But I still stand by the notion that long URLs are perfectly secure for what they are intended for. And there isn't any other good way to accomplish the same goal.
The other techniques make you force the party you want to share with get an account with that service in order to be able to name them. I find this to range from dumb to reprehensible, and I consider it a solution worse than the problem.
The only solution I would consider other than just handing you a funny URL is allowing you to specify a list of OpenIDs that were allowed to see it. But right now, I think most people would find that horribly confusing, and it requires a lot of implementation effort.
Indexing by google isn't the only way for these things to leak. For example, they could be indexed by yahoo, or msn, or just some schmoe who happens upon the wrong web page, or some concerted stalker who manually 'happens across' ALL webpages relevant to that user and picks them up.
Indeed this is true. But none of those services is going to index a URL that a user didn't explicitly make public, even if the user was being stupid. I don't call that 'figuring out' because that implies some notion of obscurity that has to be peeled back.
There is a wide chasm between intentionally publishing for all to see and "no user intrevention" - I see no explanation for the text making it out.
It is interesting that once you have the URL for the shared voice mail you can find out many of the details about it. I can see how nieve user would quite possibly assume they were just sharing the audio portion. I would agree that Google's user interface should make it clearer exactly how much information is being shared or change it so the URL will only allow access to the audio and no other details.
But, IMHO, that's not a problem of funny long URLs that don't require authorization. It's that the UI surrounding those URLs is confusing and leads people to share more than they were intending.
Don't misdirect. I didn't say one thing about guessing. You presumed it and that's PRECISELY the broken thinking that leads to failures of security like this case - nobody had to guess any of these random numbers, yet here they are for the world to see.
I was responding to the part of your post you said:
Even if they don't index it, the URLs are still going to be accessible to anyone who can figure out the URL.
In fact, the whole purpose of those URLs is for people to explicitly share their voicemails with others who may or may not have a google account. People have to go to the voicemail they want to share, click on the appropriate option and then paste the URL into some public forum for the URL to make it into a search engine. There is no 'figuring out the URL'. Google told them what it was specifically so they could make it public if they wanted to.
More presumption. There is no such option in google voice - I just checked. Furthermore, it would be silly to do that for the transcriptions of the messages, just copy the actual text and email it to the 'someone' it is being shared with. No one shares regular email the way you describe, why would they for text versions of voice-mail, or really, even audio versions, it's not like such a short, low-quality audio recording is too big to send as an attachment.
There is, in fact, just such an option because a friend notified me about this several hours before it hit Slashdot and I checked. Go and click the 'more' menu link for a voicemail, and then click on the 'embed' option. Poof, up pops the URL.
If there were really a problem where random URLs made it out onto the net with no user intervention then there would be many more than the 25 or so that would match those search criteria. As it is, people had to cut&paste those URLs out of that embed box into a facebook posting or blog posting or put them into some other public forum.
It's more like a hash collision problem. Given the length of the URLs, I'm guessing the random numbers are a few hundred bits, not just 100. With that, it would take a literally astronomical number of voicemail messages (possible one message per gram of mass of the Earth) before you had even a small hope of making a valid guess.
So, everybody should have to get a Google account so Google can authenticate them so you can give them explicit permission? That's whate every other service does, but it's dumb and wrong.
Really, the only decent other solution is to allow you to specify a list of OpenIDs that can listen to the voicemail.
Slashdot Mirror
That does indeed solve the issue for me. But it takes two to encrypt, and all my friends might not do that.
It has no support for OTR, which is the most widely supported multi-protocol encryption standard. They're working on supporting it now, but it isn't there yet, and I think the major distributions should've waited to make it the default IM client until OTR support was there.
*woosh* You failed to understand the point. Mark Cuban's article itself does not constitute tortious interference, but the scheme he describes would, if enacted.
After reading the Wikipedia article I think you are definitely correct. There is a case to be made that this behavior would constitute tortious interference. The parent deserves to be modded up.
Oh, no! I missed a negative in a widely used idiomatic phrase that most people already know. Oh, the horror of misunderstanding that I've caused, it's simply dreadful!
I happen to be precisely aware of exactly what the bureaucratic stupidity was, and that wasn't it. Now it is possible that slightly later in the hiring process the difficulty you describe might have come to pass.
Google was all set to offer me a job and it fouled on a bit of bureaucratic stupidity. But I passed their technical interview. I have no degree, and my lack of degree didn't figure into the bureaucratic stupidity.
It took a lot of people inside the company recommending me for them to give me a serious interview. But it happened. So the idea that they only hire people with graduate level degrees is a myth.
When I was 15 someone recommended the second book in "The Art of Computer Programming" series by Knuth. It was "Searching and Sorting". I read it.
I knew more about the common algorithms their order, and other details of when they were and weren't useful than your average college graduate before I even got to college. I wrote my own b-tree indexing system when I was 18.
When I was in and/or hanging around college I ended up helping a graduate level student with their AI homework. He didn't understand what a heap was or why it would be useful in an A* search. He didn't know how to code a linked list.
That stupid piece of paper is nearly meaningless. And when I've interviewed people it was only a minor data point. I usually used their time at college to probe how much they remembered about the stuff they did work on and whether or not they had a fine grasp of the details. I could care less about their degree or their grades.
Symmetry breaking. Space has a preferred direction. I have no basis for believing this, I just think it would result in the most amusing tizzy.
It is irritating to see the birth of yet another corporate-speak word. Unfortunately I don't think incite is going to ever be a good replacement. Incite has the strong connotation of encouraging someone to do something bad instead of something good.
Unfortunately, given its origins, "incentivize" is likely to acquire the same connotation over time.
Well, I've never had a cable modem for a wide variety of reasons. It's always been clear to me that cable companies had no concept of the idea of 'common carrier' and so I have never trusted them.
But all the DSL ISPs I've used, except for the very biggest, have had somewhere around 300-900Mbits to places outside their network. If they have 10000 customers, 900Mbits would give them 90Kbits/customer. Clearly way too low. And at least one of the ISPs I've had that fit this model is extremely customer focused and was very upfront about their network and bandwidth usage and the like. I know they weren't doing badly as an ISP, but I also know they weren't ripping people off.
Clearly, you can't rate limit people down to 90Kbps because that's all the bandwidth you can absolutely guarantee to the outside world. You have to give them really high burst bandwidth. And that strategy works until you get someone who uses the burst bandwidth 24/7 downloading file after file after file. I know those people exist, I lived in a house with one and had to rate limit him so I could have a decent connection (meaning I could remote ssh into my box and be able get 100 millisecond response times when typing instead of several second response times). He finally stopped because my rate limiting caused his bulk downloading to interfere with his game of WoW.
So, what you have to do is make sure that people who are using burst bandwidth get the high speed, and the people who are using bulk bandwidth get the lowest priority. That will generally mean that their download rate actually only goes down a little because the burst bandwidth people don't take much. But if you don't put the bulk downloaders at lowest priority, the burst people suffer, and that's not fair at all.
I disagree pretty strongly. There are people I know of who are constantly downloading as much as they possibly can all the time. No matter what the network capacity increases to they will always eat up all that they possibly can.
I do agree that our infrastructure in the US is really bad and could be improved. And I agree that comcast is pretty deceptive, and I think a lot of DSL providers are also kind of deceptive.
But people who constantly use as much bandwidth as they possibly can are a problem. Perhaps the ISP should advertise 'burst bandwidth 8Mbps, sustained 500Kbps'. That wouldn't really change anything in my opinion.
In almost all networks, no matter how well structured they are, you are going to end up with too little bandwidth between groups than is required to sustain all those nodes communicating with each other at their individual full bandwidth to the network. You want networks structured this way because burst bandwidth is generally a lot more important than sustained, especially between disparate groups of nodes. And in fact it's nearly impossible to have networks structured any differently. Even high speed networks designed to sustain distributed supercomputers have this problem.
No, with this it doesn't matter what coders do. If a node says all of it's traffic is high priority it all gets shoved in the same bucket and that bucket then receives very low priority if it's always the one using up all the bandwidth.
The only way priority will help someone is if they really mark only the things they care about most as high priority, or the ones they care about least as low priority.
Yes, that is the biggest issue as I see it. State tracking. :-/
And yes, this would require you to partition your network into sections where you had enough switch bandwidth for all your customers in a particular section to be able to send data to eachother at full speed. Congestion would be measured at the section boundaries.
So, it's not the easiest solution. But it's a heck of a lot more fair and less suspect than just trying to curb a particular application you don't like.
Maybe they should look at how telecommunications companies are connecting people as the problem instead of how people are using the Internet.
Anyway, to my mind, there are a clear set of traffic shaping policies that satisfy net neutrality and make sure the network is still usable by everyone. And that's to shape by physical connection, not application. I have an 8 megabit DSL line, but I think my ISP has about 450-600 mbits of bandwidth to the Internet. The aggregate bandwidth of all of their DSL customers is likely at least 10 times their available bandwidth to the Internet, and that's a perfectly normal and reasonable situation.
If ever any given connection they have to the Internet becomes saturated, they should prioritize traffic in such a way as to make sure everybody trying to use that connection gets their fair share. That means customers that only burst traffic and aren't using their max for hours get priority over the people who are using as much bandwidth as they can for hours. As the bandwidth becomes more constrained, the criteria for what counts as a burst should become shorter and the max burst bandwidth should be lowered.
Trying to kill off all your bittorrent customers, especially since you think they're competing with your more profitable centralized video distribution business sure seems attractive, but it's evil and all the wrong approach. Just allocate bandwidth fairly to your customers and the bittorrent people will be punished for using all their bandwidth by having molasses web surfing compared to everybody else.
If bittorrent customers don't like this, they can agree to start marking the traffic they want to have as low priority and then that traffic will be the first to go when there's a bandwidth crunch.
Yes. Programs should encourage people to make correct assumptions, not incorrect ones. Programs that lead people to make incorrect ones have design flaws. Such design flaws have killed people in the past.
Not really. What you really want with a sandbox is for a program's every access to system resources outside of a small predefined set to be vetted by the user. SELinux can't really do that.
But, the blog article does give you a really nice way to quickly create an environment for a program to run in that has access to almost no system resources, and while that's not all you want, it is still pretty useful subset.
Most programs that run other programs actually run them in an obvious fashion. The fact that ldd doesn't seem to run the program because it feeds the program an environment variable that causes the program to print out some information and exit leads people to make a bad assumption about how ldd works. In my opinion, this is a really bad design flaw in ldd and should've been fixed years ago.
I know it violated my assumptions about what ldd was doing.
I know the G1 has some DRM issues, and that irritates me. Will this new e-reader also have them? If so, how pervasive and extensive will it be? It sounds like they intend to allow PDF reading. So maybe you can just avoid buying anything with DRM on it?
Ultimately you are arguing for a Pandora's Box's of security. Just because you can't think of a way for one of these URLs to leak out now doesn't mean someone else won't come up with a way to make it happen and once that's the case, there is no stuffing them back into the box of obscurity.
While the rest of your comment is basically correct, though I will point out that I feel that Google's current UI does not make it clear to people exactly what they're sharing, I do take objection to this.
The browser history is an interesting question, and definitely an avenue in which the URLs may end up with more exposure than a user intends. Though, IMHO, a user is already being inordinately cavalier with security to be doing anything private on a public terminal. But I still stand by the notion that long URLs are perfectly secure for what they are intended for. And there isn't any other good way to accomplish the same goal.
The other techniques make you force the party you want to share with get an account with that service in order to be able to name them. I find this to range from dumb to reprehensible, and I consider it a solution worse than the problem.
The only solution I would consider other than just handing you a funny URL is allowing you to specify a list of OpenIDs that were allowed to see it. But right now, I think most people would find that horribly confusing, and it requires a lot of implementation effort.
Indexing by google isn't the only way for these things to leak. For example, they could be indexed by yahoo, or msn, or just some schmoe who happens upon the wrong web page, or some concerted stalker who manually 'happens across' ALL webpages relevant to that user and picks them up.
Indeed this is true. But none of those services is going to index a URL that a user didn't explicitly make public, even if the user was being stupid. I don't call that 'figuring out' because that implies some notion of obscurity that has to be peeled back.
There is a wide chasm between intentionally publishing for all to see and "no user intrevention" - I see no explanation for the text making it out.
It is interesting that once you have the URL for the shared voice mail you can find out many of the details about it. I can see how nieve user would quite possibly assume they were just sharing the audio portion. I would agree that Google's user interface should make it clearer exactly how much information is being shared or change it so the URL will only allow access to the audio and no other details.
But, IMHO, that's not a problem of funny long URLs that don't require authorization. It's that the UI surrounding those URLs is confusing and leads people to share more than they were intending.
Do you know of anyplace where the story of the Canopy group has been neatly summarized? I'm curious about it and all I can find are endless details.
Don't misdirect. I didn't say one thing about guessing. You presumed it and that's PRECISELY the broken thinking that leads to failures of security like this case - nobody had to guess any of these random numbers, yet here they are for the world to see.
I was responding to the part of your post you said:
Even if they don't index it, the URLs are still going to be accessible to anyone who can figure out the URL.
In fact, the whole purpose of those URLs is for people to explicitly share their voicemails with others who may or may not have a google account. People have to go to the voicemail they want to share, click on the appropriate option and then paste the URL into some public forum for the URL to make it into a search engine. There is no 'figuring out the URL'. Google told them what it was specifically so they could make it public if they wanted to.
More presumption. There is no such option in google voice - I just checked. Furthermore, it would be silly to do that for the transcriptions of the messages, just copy the actual text and email it to the 'someone' it is being shared with. No one shares regular email the way you describe, why would they for text versions of voice-mail, or really, even audio versions, it's not like such a short, low-quality audio recording is too big to send as an attachment.
There is, in fact, just such an option because a friend notified me about this several hours before it hit Slashdot and I checked. Go and click the 'more' menu link for a voicemail, and then click on the 'embed' option. Poof, up pops the URL.
If there were really a problem where random URLs made it out onto the net with no user intervention then there would be many more than the 25 or so that would match those search criteria. As it is, people had to cut&paste those URLs out of that embed box into a facebook posting or blog posting or put them into some other public forum.
That's true. I oversimplified.
It's more like a hash collision problem. Given the length of the URLs, I'm guessing the random numbers are a few hundred bits, not just 100. With that, it would take a literally astronomical number of voicemail messages (possible one message per gram of mass of the Earth) before you had even a small hope of making a valid guess.
So, everybody should have to get a Google account so Google can authenticate them so you can give them explicit permission? That's whate every other service does, but it's dumb and wrong.
Really, the only decent other solution is to allow you to specify a list of OpenIDs that can listen to the voicemail.