Facebook insecure by design
In accord with the recent thread, "facebook spying on us?" We should also worry about other spying on us. Without some sort of rudimentary security, all that personally identifiable information is exposed on our ISP networks, over WiFi, etc. Facebook claims to be able to run over TLS connections. Not so much (see attached picture). This wasn't an "app", this is the simple default content of a page accessed after a Google search. https://www.facebook.com/ceelogreen
Actually, the reason for what happened in your example is that Cee Lo's page has what is **technically** an app (called I Want You, as seen in the sidebar under his profile photo) set as the default screen for when you view his page. The app (that does admittedly looks like it could be an official feature from facebook) uses externally-hosted HTTP-only content, which Facebook will detect and warn you about. -- Ben On 9/30/2011 5:05 AM, William Allen Simpson wrote:
In accord with the recent thread, "facebook spying on us?"
We should also worry about other spying on us. Without some sort of rudimentary security, all that personally identifiable information is exposed on our ISP networks, over WiFi, etc.
Facebook claims to be able to run over TLS connections. Not so much (see attached picture).
This wasn't an "app", this is the simple default content of a page accessed after a Google search.
William Allen Simpson wrote:
In accord with the recent thread, "facebook spying on us?"
We should also worry about other spying on us. Without some sort of rudimentary security, all that personally identifiable information is exposed on our ISP networks, over WiFi, etc.
Facebook claims to be able to run over TLS connections. Not so much (see attached picture).
This wasn't an "app", this is the simple default content of a page accessed after a Google search.
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Mike
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas <mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to. Supporting TLS in their case is not good enough... they would need to force all connections to be over TLS, to achieve security against MITM. As soon as an app causes the end user to switch to a non-TLS connection, they are vulnerable.
Mike
-- -JH
On 10/2/11 12:36 PM, Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas<mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to.
My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true.
William Allen Simpson wrote:
On 10/2/11 12:36 PM, Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas<mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to.
My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true.
Bingo. Mike
On 02/10/2011 19:01, Michael Thomas wrote:
William Allen Simpson wrote:
On 10/2/11 12:36 PM, Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas<mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to.
My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true.
Bingo.
Mike
+1
On Mon, Oct 3, 2011 at 4:27 AM, William Allen Simpson < william.allen.simpson@gmail.com> wrote:
On 10/2/11 12:36 PM, Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas<mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to.
My understanding of his statement is that Facebook itself is the MITM,
collecting all our personal information. Too true.
I assume that any MITM is actually going to try and prevent our data from making it to the end point i.e the real attacker. -- Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik <at> ansto dot gov dot au<jason.leschnik@ansto.gov.au> [U@] jml974@uow.edu.au
Jason Leschnik wrote:
On Mon, Oct 3, 2011 at 4:27 AM, William Allen Simpson < william.allen.simpson@gmail.com> wrote:
On 10/2/11 12:36 PM, Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomas<mike@mtcc.com> wrote:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to.
My understanding of his statement is that Facebook itself is the MITM,
collecting all our personal information. Too true.
I assume that any MITM is actually going to try and prevent our data from making it to the end point i.e the real attacker.
What fun would that be? Seriously though, a MITM doesn't have to be disruptive; there are a zillion and three other reasons. Like getting a big budg hollywood movie made about you. Mike
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack. In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook. Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit. -- -JH
On 10/2/11 15:25 , Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack.
In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook.
alice sends charlie a message using bob's api, bob can observe and probably monetize the contents.
Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit.
charlie is probably untrustworthy, bob is probably moreso (mostly because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there.
-- -JH
On 10/2/11 15:43 , Joel jaeggli wrote:
On 10/2/11 15:25 , Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack.
In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook.
alice sends charlie a message using bob's api, bob can observe and probably monetize the contents.
Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit.
charlie is probably untrustworthy, bob is probably moreso (mostly ^ trustworthy because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there.
-- -JH
Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that. ----- Original Message ----- From: "Joel jaeggli" <joelja@bogus.com> To: "Jimmy Hess" <mysidia@gmail.com> Cc: <nanog@nanog.org> Sent: Sunday, October 02, 2011 4:05 PM Subject: Re: Facebook insecure by design
On 10/2/11 15:25 , Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack.
In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook.
alice sends charlie a message using bob's api, bob can observe and probably monetize the contents.
Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit.
charlie is probably untrustworthy, bob is probably moreso (mostly ^
On 10/2/11 15:43 , Joel jaeggli wrote: trustworthy
because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there.
-- -JH
[ if you were already over this topic, plonk the thread ] ----- Original Message -----
From: "Bill.Pilloud" <bill.pilloud@gmail.com>
Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that.
No. Because "sensitive" is a word with different definitions at different times for different people. I don't mind my friends knowing that I (used to) go to Rocky Horror every Saturday night and run around in my underwear. I don't particularly want a potential employer to know that, and I might not want a new girlfriend to know it *immediately*. The promise of Social Networking is *precisely* that it permits this more fine-grained *control* (that's the key word, for those who weren't playing the home game) over the information you disseminate, as opposed to just posting all of it on your blog. *Telling people you're going to provide them that control* and then being sloppy about it -- or worse, purposefully evil -- is the thing that has people up in arms. As usual, the underlying issue is one of trust. Alas, I see no theoretical way that distributed systems like Diaspora *can* provide some of the functions that are core to systems like Facebook, *exactly by virtue* (vice?) of the fact that they are distributed; there is no central Trust Broker. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
You know I don't need Facebook to introduce (broker) me to anyone! I am more than happy managing my own relationships (gradations of trust included!) Oh and my friends are distributed in the real world as well! This works pretty well even without a "social network" or a "system". When the Diginotar certification authority was badly compromised I got a bunch of information from many sources using those protocols which span the standards sphere of the Internet each bringing information that I value at varying levels of trust and applicability. Between and in combination of all this input I was able to take action and remove Diginotar from my keychain. I could have waited for Apple to stir its stumps but didn't need to. All those independent distributed "trust brokers" did a fine job! thanks folks! Christian On 4 Oct 2011, at 16:38, Jay Ashworth wrote:
As usual, the underlying issue is one of trust.
Alas, I see no theoretical way that distributed systems like Diaspora *can* provide some of the functions that are core to systems like Facebook, *exactly by virtue* (vice?) of the fact that they are distributed; there is no central Trust Broker.
At the end of the day Social Networks just want to make interactions as natural as possible so they can continue to mine and monetize your relationship data as you get more comfortable sharing the 'real you.' Anyone who hasn't and has an interest in privacy, graph and content ownership on social networks should check out the Diaspora project. -Travis On Tue, Oct 4, 2011 at 1:35 PM, Christian de Larrinaga <cdel@firsthand.net>wrote:
You know I don't need Facebook to introduce (broker) me to anyone! I am more than happy managing my own relationships (gradations of trust included!) Oh and my friends are distributed in the real world as well!
This works pretty well even without a "social network" or a "system". When the Diginotar certification authority was badly compromised I got a bunch of information from many sources using those protocols which span the standards sphere of the Internet each bringing information that I value at varying levels of trust and applicability. Between and in combination of all this input I was able to take action and remove Diginotar from my keychain. I could have waited for Apple to stir its stumps but didn't need to.
All those independent distributed "trust brokers" did a fine job!
thanks folks!
Christian
On 4 Oct 2011, at 16:38, Jay Ashworth wrote:
As usual, the underlying issue is one of trust.
Alas, I see no theoretical way that distributed systems like Diaspora *can* provide some of the functions that are core to systems like Facebook, *exactly by virtue* (vice?) of the fact that they are distributed; there is no central Trust Broker.
-- Twitter <https://twitter.com/tbiehn> | LinkedIn<http://www.linkedin.com/in/travisbiehn>| GitHub <http://github.com/tbiehn> | TravisBiehn.com<http://www.travisbiehn.com>
Hey all! I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. I have some experience in networking but nothing like what is mostly talked about on here. I just love the talks you experts have and researching the tools you all mention. I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday! I'm trying to put a baseline policy together for all my network equipment and I have a few questions: 1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere? 2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite. 3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice? 4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane! If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction. Thanks in advance! TG
On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy <Timothy.Green@mantech.com> wrote:
1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere?
Hi Timothy, STIGs are a DoD thing. http://iase.disa.mil/stigs/. They're not particularly relevant to public Internet operations. In a few cases they're not particularly sane. (Manually install the latest bleeding edge version of OpenSSL whose bugs have not yet been found and whose API is incompatible with every linked app in the OS? Really?)
2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite.
Depends on the configuration. If it's one that rarely changes, it's not a bad idea. But don't saturate yourself with alerts or you'll misinterpret or ignore the important ones.
3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice?
It depends. My personal predilection is that IP addresses belong in configurations while explanation and structure belong on network diagrams so I rarely reach the question of whether there's also security value in removing the IP addresses from the pretty pictures.
4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane!
Simplify. Don't overdo it. Do you really need ACLs for 100 popular trojan horse TCP ports? The 500 outbound port whitelist? If your security is so complex you can't understand it then it almost certainly isn't secure. If you have a particular subsystem with special needs, it never hurts to give it its own firewall so you can strip the related complexity from your main firewall. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Hey Tim, We recently bought the NCM tool by SolarWinds as well. We've had it for two months, and I personally am quite happy with it. We had Cisco's CiscoWorks product for the last 5-6 years but ditched it because of it never quite works consistently. The thing to be aware of for config auditing, like with NCM's reports, is that in some environments config is ALWAYS changing. I'm in a small enterprise setup with a very dynamic datacenter and it is not abnormal to have a few hundred changes across a week with the number of server moves/rebuilds/expansions going on in our place. So in our case, we are primarily using NCM for pushing configs, and using the alerting of changes mostly to do spot checks on the fellow team-members. Since there are so many changes, it is nice to have visibility to make sure that appropriate standards are being met. David. On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy <Timothy.Green@mantech.com> wrote:
Hey all!
I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. I have some experience in networking but nothing like what is mostly talked about on here. I just love the talks you experts have and researching the tools you all mention. I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday!
I'm trying to put a baseline policy together for all my network equipment and I have a few questions:
1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere?
2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite.
3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice?
4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane!
If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction.
Thanks in advance!
TG
Hi Tim, How long have you been on that position? IT Security Manager are you self-employed or running your own limited company? what areas of knowledge are you mostly interested in? where about are you based? what do you think the role of an IT Security Manager is about? From: David Swafford <david@davidswafford.com> To: "Green, Timothy" <Timothy.Green@mantech.com> Cc: NANOG <nanog@nanog.org> Sent: Saturday, October 8, 2011 12:56 PM Subject: Re: Config files? Hey Tim, We recently bought the NCM tool by SolarWinds as well. We've had it for two months, and I personally am quite happy with it. We had Cisco's CiscoWorks product for the last 5-6 years but ditched it because of it never quite works consistently. The thing to be aware of for config auditing, like with NCM's reports, is that in some environments config is ALWAYS changing. I'm in a small enterprise setup with a very dynamic datacenter and it is not abnormal to have a few hundred changes across a week with the number of server moves/rebuilds/expansions going on in our place. So in our case, we are primarily using NCM for pushing configs, and using the alerting of changes mostly to do spot checks on the fellow team-members. Since there are so many changes, it is nice to have visibility to make sure that appropriate standards are being met. David. On Wed, Oct 5, 2011 at 3:16 PM, Green, Timothy <Timothy.Green@mantech.com> wrote:
Hey all!
I'm a IT Security Manager (policy creation) that has been lurking on NANOG for about 3 years. I have some experience in networking but nothing like what is mostly talked about on here. I just love the talks you experts have and researching the tools you all mention. I was having a tough time yesterday explaining to one of my nosey co-workers why I had the word Octopussy on my screen yesterday!
I'm trying to put a baseline policy together for all my network equipment and I have a few questions:
1. Should config files be consistent? By this I mean; does the STIG apply its baseline to the config files or elsewhere?
2. Are config file change alerts necessary for the security of network equipment? We have just purchased the SolarWinds suite.
3. Should we obfuscate our Private addresses on our Network Diagram? What is the common practice?
4. How can I get a grip on my ACLs or is it even possible? How do you all maintain them without going insane!
If this isn't the correct forum for this "low level" stuff I understand; just guide me in the right direction.
Thanks in advance!
TG
Going back to the initial security problem identified by Williams, I also experienced something today. I guess he is right about that. I am behind a proxy and I just disabled the proxy for "Secure Web" which means HTTPS. Now guess what I was still able to access facebook while I was not able to access google. That clearly means there is something wrong. What do you guys think? Ghulam On Wed, Oct 5, 2011 at 2:28 AM, Bill.Pilloud <bill.pilloud@gmail.com> wrote:
Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that. ----- Original Message ----- From: "Joel jaeggli" <joelja@bogus.com> To: "Jimmy Hess" <mysidia@gmail.com> Cc: <nanog@nanog.org> Sent: Sunday, October 02, 2011 4:05 PM Subject: Re: Facebook insecure by design
On 10/2/11 15:43 , Joel jaeggli wrote:
On 10/2/11 15:25 , Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise.
Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack.
In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook.
alice sends charlie a message using bob's api, bob can observe and probably monetize the contents.
Yes, if Alice sends Bob an encrypted message that Bob can read, and
Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit.
charlie is probably untrustworthy, bob is probably moreso (mostly
^ trustworthy
because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there.
--
-JH
Just about everything on Google pages is https these days, even search if you enable it. If anybody on this thread uses gmail com a you really ought to take a look at google plus. Compare the way user privacy is the primary objective, versus the share everything by default of facebook. I cannot think of anything that could do something like this in the Gmail or Plus products. On Oct 19, 2011 11:22 PM, "Murtaza" <leothelion.murtaza@gmail.com> wrote:
Going back to the initial security problem identified by Williams, I also experienced something today. I guess he is right about that. I am behind a proxy and I just disabled the proxy for "Secure Web" which means HTTPS. Now guess what I was still able to access facebook while I was not able to access google. That clearly means there is something wrong. What do you guys think? Ghulam
On Wed, Oct 5, 2011 at 2:28 AM, Bill.Pilloud <bill.pilloud@gmail.com> wrote:
Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that. ----- Original Message ----- From: "Joel jaeggli" <joelja@bogus.com> To: "Jimmy Hess" <mysidia@gmail.com> Cc: <nanog@nanog.org> Sent: Sunday, October 02, 2011 4:05 PM Subject: Re: Facebook insecure by design
On 10/2/11 15:43 , Joel jaeggli wrote:
On 10/2/11 15:25 , Jimmy Hess wrote:
On Sun, Oct 2, 2011 at 4:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said:
> I'm not sure why lack of TLS is considered to be problem with > Facebook. > The man in the middle is the other side of the connection, tls or > otherwise. > Ooh.. subtle. :)
Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack.
In this case, I believe the proper term would be just "The man". [Or "Man at the Other End (MATOE)"]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook.
alice sends charlie a message using bob's api, bob can observe and probably monetize the contents.
Yes, if Alice sends Bob an encrypted message that Bob can read, and
Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit.
charlie is probably untrustworthy, bob is probably moreso (mostly
^ trustworthy
because bob has more to lose than charlie), alice isn't cognizant of
the
implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there.
--
-JH
[hmmm this subject is not really ops now is it...] On 2011-10-23 19:43 , steve pirk [egrep] wrote:
Just about everything on Google pages is https these days, even search if you enable it.
(or just use https://encrypted.google.com which is available for quite some time already)
If anybody on this thread uses gmail com a you really ought to take a look at google plus. Compare the way user privacy is the primary objective, versus the share everything by default of facebook.
Since when is encrypting a transport (in this case using TLS/SSL) 'user privacy' ? The only thing it is protecting is intermediate networks sniffing or even modifying the traffic and more importantly for the company who gets all your private information: their revenue stream when they sell that data. And really, giving all your private emails to a company that explicitly reads them (even if it is 'automated') to advertise to you and then mentioning 'user privacy' is just ridiculous ;) Greets, Jeroen
----- Original Message -----
From: "Jeroen Massar" <jeroen@unfix.org>
On 2011-10-23 19:43 , steve pirk [egrep] wrote:
Just about everything on Google pages is https these days, even search if you enable it.
(or just use https://encrypted.google.com which is available for quite some time already)
Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo... http://lauren.vortex.com/archive/000906.html Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
I follow Lauren on plus, and also on buzz, and we have discussed privacy stuff a lot. The way I look at it, unless you want to host everything yourself, you have to choose "someone" to be your Unix like home directory in the cloud. Of all the internet entities out there, Google has had the best track record of protecting your data. You can even download it all and erase yourself if you want out. Apps accounts and pseudonym accounts are coming soon. It was announced by Vic himself at web 2.0. I need to send that post by Lauren to the gmail account. He always finds good issues. It could be that I am off base. On Oct 23, 2011 4:04 PM, "Jay Ashworth" <jra@baylink.com> wrote:
----- Original Message -----
From: "Jeroen Massar" <jeroen@unfix.org>
On 2011-10-23 19:43 , steve pirk [egrep] wrote:
Just about everything on Google pages is https these days, even search if you enable it.
(or just use https://encrypted.google.com which is available for quite some time already)
Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo...
http://lauren.vortex.com/archive/000906.html
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Date: Sun, 23 Oct 2011 21:45:33 -0700 Subject: Re: Facebook insecure by design Cc: nanog@nanog.org
The way I look at it, unless you want to host everything yourself, you have to choose "someone" to be your Unix like home directory in the cloud.
Correct. Either it's 'local', or it's "somewhere else" -- by definition. :)
Of all the internet entities out there, Google has had the best track record of protecting your data.
As far as we know, that is. Remember the old saying about 'undiscovered bugs'. <wry grin>
You can even download it all and erase yourself if you want out.
Don't count on it. You may 'disappear' from public view, but that does not necessarily mean the data is truely 'gone'. Specific example -- if you request a USENET posting to be removed, all they do is make it 'invisible' to the world. It is _not_ removed from the databases, or from inernal access/use.
The real question is why the referrer field was not under user control in the first place. Having to never click on a link, but rather to cut and paste it into the address bar is not a satisfactory work-around. Still, why has it not been put under user control, now that we have a better appreciation of the hazards of that information leakage? -- -=[L]=- Reassembled from random thought waves This is not a signature line.
On Oct 24, 2011 7:55 AM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
You can even download it all and erase yourself
if
you want out.
Don't count on it. You may 'disappear' from public view, but that does not necessarily mean the data is truely 'gone'. Specific example -- if you request a USENET posting to be removed, all they do is make it 'invisible' to the world. It is _not_ removed from the databases, or from inernal access/use.
That is a very good point, and one of the things that is being tested now that Buzz is going into archive mode. Users are given the option of backing up their posts on Buzz, and then deleting their Buzz content. Many like myself will just leave it there. It is a year+ of history, and what I posted publicly can stay public. It is supposed to remove all your Buzz content from the service and I believe it includes the content shared only with certain individuals. It does not completely erase it, because I believe email copies of the posts and comments that people had sent to their Gmail accounts will remain with those users. Deleting a product like your Picasa web albums is permanent as far as I know, but I will definitely ask some people on the Picasa team. Deleting your search history and other Dashboard items is supposed to be permanent, but as you pointed out, we are taking Google's word for it. --steve
That was a most excellent example Jay. I see what the issue is now. This could be related to work Google did to plus shortly after launch. Buzz and now Google+ are https only. Google cooked up a URL processer that took clicks to external content like article links, and massaged the referrer be readable as http to show where the visitor came from. Sanitized of any personal data I assume. The problem they were trying to fix was no one knew any users were coming from Buzz clicks. They fixed that in +. I am thinking something of the same might fix the search issues. It could also be that a Googler saw Lauren's post and the debate has already started. -steve On Oct 23, 2011 4:04 PM, "Jay Ashworth" <jra@baylink.com> wrote:
----- Original Message -----
From: "Jeroen Massar" <jeroen@unfix.org>
On 2011-10-23 19:43 , steve pirk [egrep] wrote:
Just about everything on Google pages is https these days, even search if you enable it.
(or just use https://encrypted.google.com which is available for quite some time already)
Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo...
http://lauren.vortex.com/archive/000906.html
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
participants (21)
-
Ben Carleton -
Bill.Pilloud -
Christian de Larrinaga -
David Swafford -
Green, Timothy -
isabel dias -
Jason Leschnik -
Jay Ashworth -
Jeroen Massar -
Jimmy Hess -
Joel jaeggli -
Lou Katz -
Michael Thomas -
Murtaza -
Patrick Sumby -
Robert Bonomi -
steve pirk [egrep] -
Travis Biehn -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson -
William Herrin