It looks like you're using an Ad Blocker.

Please white-list or disable AboveTopSecret.com in your ad-blocking tool.

Thank you.

 

Some features of ATS will be disabled while you continue to use an ad-blocker.

 

ATS Is On Facebook

page: 16
67
<< 13  14  15    17  18  19 >>

log in

join
share:

posted on Aug, 25 2010 @ 11:08 AM
link   

Originally posted by maskfan
There is no reason why anyone active on this site needs to give up their anonymity

we are NOT anonymous here at ATS.
Admins have our IP adresses and our
ISP.

Now all one has to do is cross reference
those IP adresses with the same data
at FB, and every poster here will have
a name associated with a seemingly
anonymous ATS existence.

cross site scripting can do just that.
However, SO will NOT post cookie
or java script coding to verify that
isn't happening.

So you may think u r anonymous here,
but u really are not for positive when you
use BOTH ATS and FB.

Might I also remind you that ATS has certain threads
posted which collect data from it's users.
Like just this week. "What kind of guns do you have?"
Was posted. Last week thread "Will there be a Revolution?
What do you intend to do?". These are baiting threads.
Now add on top of that, the loss of anonymity and
now they can associate what guns you have, what your
intentions are to overthrow the gov, AND your real name.

Doesn't anyone besides me find that very disturbing ???

And linking or sending posters from ATS to FB helps
facilitate that process.

Call me paranoid if u wish
but there's good reasons




posted on Aug, 25 2010 @ 11:11 AM
link   

Originally posted by Sky watcher
Your still ignoring the fact that all it takes, for ATS members info to be compromised is to open Facebook while ATS is open or just even still be in the members PC history.

That's incorrect.

Can you specify how one site may learn of another site because they're open in two different browser windows?



posted on Aug, 25 2010 @ 11:13 AM
link   

Originally posted by SkepticOverlord
Can you specify how one site may learn of another site because they're open in two different browser windows?

I have already explained that one
with my variables speech.



posted on Aug, 25 2010 @ 11:13 AM
link   

Originally posted by boondock-saint
cross site scripting can do just that.
However, SO will NOT post cookie
or java script coding to verify that
isn't happening.

Simply select "view source" on your browser to see the Javascript, or review the content of the cookies we write.



And linking or sending posters from ATS to FB helps
facilitate that process.

No linking exists, and links from ATS to FB will not carry referral data that could be used to determine the topic one was reading before hitting FB.



posted on Aug, 25 2010 @ 11:14 AM
link   
reply to post by boondock-saint
 


Do you have any corroborating details as I couldn't fathom how such a process would function in the real world?



posted on Aug, 25 2010 @ 11:17 AM
link   
reply to post by boondock-saint
 

Yeah I had the exact same thoughts when I saw those threads.
and you are correct about this,.
some guy announces he has a 50 cal. in his garage for target shooting Ha ha
and the next thing he knows ,. he is a terrorist.. and
ahhh,... have to stop writing this for a moment,... someone is at the door.



[edit on 25-8-2010 by Lil Drummerboy]



posted on Aug, 25 2010 @ 11:18 AM
link   
reply to post by boondock-saint
 


Echelon

You really think the government cares if you have an ATS and a Facebook account when they can intercept everything you do online anyway?




posted on Aug, 25 2010 @ 11:23 AM
link   

Originally posted by SkepticOverlord
Simply select "view source" on your browser to see the Javascript, or review the content of the cookies we write.


this is not possible. I am a programmer, I should know.
Java scripting cannot be seen with the ''view source"
in any browser. View source only shows html scripting.



Originally posted by SkepticOverlord
No linking exists, and links from ATS to FB will not carry referral data that could be used to determine the topic one was reading before hitting FB.

once again you cannot determine this to be fact
unless you are familiar with the FB coding.
Have you seen the FB coding ???
especially the referring url variables or userdata
variables. A string query from FB can give them
the value of a variable in memory. If that variable
is "topic" and has a value of "278451". Then that can tell FB what topic
you are reading from the referrer cuz it has NOT been
zeroed out or erased before going to FB.



posted on Aug, 25 2010 @ 11:27 AM
link   
reply to post by boondock-saint
 


Yes I've seen the coding from FB, O but wait!!! no FB code exists on this site.


Again, have you used an RSS reader? We've aimed the facebook page to be a type of RSS reader for those that on are Facebook.



posted on Aug, 25 2010 @ 11:29 AM
link   

Originally posted by boondock-saint
I should know.
Java scripting cannot be seen with the ''view source"
in any browser.

Are you referring to Java or JavaScript. The two are different and we do not use Java.



Originally posted by SkepticOverlord
Have you seen the FB coding ???
especially the referring url variables or userdata
variables.

I've reviewed what their PHP and API calls do, and will not be using them.

Referrer data will be stripped (as mentioned in this thread) by an intermediary redirect hosted on our servers that does not include the "abovetopsecret.com" domain name.

Edit to add...

This is our referrer-stripping link that ensures "abovetopsecret.com" is never seen in links from ATS to FB: www.atsnews.com/gotofacebook.php

You can test what header data is passed along via that type of link here: test





edit on by SkepticOverlord because: (no reason given)



posted on Aug, 25 2010 @ 11:52 AM
link   

Originally posted by ATSmediaPRO
Yes I've seen the coding from FB, O but wait!!! no FB code exists on this site.


it doesn't HAVE to exist on this site.
And SO wants a real world break down
of how this works, so I'll share.

OK, I'll try to explain in a simple process
how this works in reality so you can see
what I'm talking about.

Let's say for instance in the ATS cookie coding or java script
that the programmer creates several variables
in java scripting including:

userdat$
username$
profiledata$
loginTime$

etc... etc...

and the script for the cookie
runs it's course and it stores
the values for those variables
in the user's RAM memory.

Once you click a link in your browser
without logging out at ATS, those variables
created by scripting remain in memory.

Now when you hit the FB site, let's say
the FB cookie coding java script seeks
the value of a specific variable and assigns it
a new name so as not to overwrite the previous
value.

userdata1$ = userdat$
usernameP$ = username$

write usernameP$ to FB database profile subfield

now FB has in it's database your real name of

usernameP$

in a database field called

username$

open up a spreadsheet program and export
the data and it will read

Skeptic Overlord | Bill

so you see the problem. You cannot avoid this
having both ATS and FB open at the same time
and logged into both vuz the copied variables
are still in use by ATS.

Now to compound the problem even further

if scripting from ATS creates a variable
from posting entitled "forumPostRecent$"
and it has a value of:

"Oh I have a .30-06 hidden under my bed
with a snub nose 38 in the dresser drawer"

now the FB script assigns the value of

forumRecentPost1$ = forumRecentPost$

now that very same database at FB will read:

Skeptic Overlord | Bill | Oh I have a .30-06 hidden under my bed
with a snub nose 38 in the dresser drawer

Now couple all of the above with the fact that
FB is a CIA Gov Data Mining Agency. And just by
referring or linking to the site, the FB scripting
can Data Mine ATS by reading stored variables
in your PC memory.

I hope this has been enlightening.



posted on Aug, 25 2010 @ 12:00 PM
link   

Originally posted by boondock-saint
Let's say for instance in the ATS cookie coding or java script
that the programmer creates several variables
in java scripting including:

As I've mentioned before, no client-side JavaScript reads the content of ATS cookies that contain user information.



posted on Aug, 25 2010 @ 12:09 PM
link   

Originally posted by SkepticOverlord
As I've mentioned before, no client-side JavaScript reads the content of ATS cookies that contain user information.


They don't have to read your cookies.
They will be reading the VARIABLES and their
values stored in the user's PC.

It's got nothing to do with the content of the cookies.
It has EVERYTHING to do with WHAT variables
the ATS cookies create or the variables the ATS
java scripting create. Every variable a cookie or
java script creates is NOT stored in the cookie
itself, but it IS STORED on the clients machine.
All FB has to do on their end is to write a cookie code
or a java script to query the value of variables
in your RAM memory. And your security breach
has been compromised.



posted on Aug, 25 2010 @ 12:12 PM
link   

Originally posted by boondock-saint
It's got nothing to do with the content of the cookies.
It has EVERYTHING to do with WHAT variables
the ATS cookies create or the variables the ATS
java scripting create. Every variable a cookie or
java script creates is NOT stored in the cookie
itself, but it IS STORED on the clients machine.
All FB has to do on their end is to write a cookie code
or a java script to query the value of variables
in your RAM memory. And your security breach
has been compromised.


Isn't all that true regardless of the recent integration efforts by ATS ? Not because of them.

If people choose to use Facebook they are vunerable in all kinds of different ways. Ways that are not intrinsicly anything to do with ATS. People really shouldn't be discussing illegal or questionable activities on a public discussion forum anyway. Especially if they have not taken personal steps to protect themselves.

[edit on 25-8-2010 by maskfan]



posted on Aug, 25 2010 @ 12:16 PM
link   

Originally posted by boondock-saint
I hope this has been enlightening.

To some degree. I'm unclear as to your claim of being a programmer as you seem to be confused about a few things.

JavaScript is indeed viewable by selecting "view source" of any web page... and you are referencing the typical functions of inline client-executed JavaScript as opposed to Java running on a web server. And I'm not aware of any methodology for one JavaScript on page "A" to access the variables used by a JavaScript on page "B." similar question

Is there a proof of concept you've seen?



posted on Aug, 25 2010 @ 12:19 PM
link   

Originally posted by boondock-saint
Every variable a cookie or
java script creates is NOT stored in the cookie
itself, but it IS STORED on the clients machine.

Cookie data is indeed stored in the cookie, passed to the web server via the HTTP header, and not accessed until code somewhere in a web page (JavaScript, PHP, JSP, ASP, CGI, etc.) initiates a call to read a cookie. If the call is initiated via server-side code (PHP, ASP, JSP, CGI, etc.) the cookie data is not present in user RAM. Additionally, "Site A" cannot read the cookie data written by "Site B."


edit on by SkepticOverlord because: typo correction.



posted on Aug, 25 2010 @ 12:21 PM
link   

Originally posted by maskfan
Isn't all that true regardless of the recent integration efforts by ATS ? Not because of them.

correct
ATS admin may not even be aware of
the Data Mining efforts by FB coding.

This can happen from ANY site that is referred
to FB, not just ATS.

However, if ATS starts sending mass quantities
of people to FB, all FB has to do is add a few
lines of script to their java scripting to data mine
the variables used by ATS.

This is the very reason why I asked Bill
to expose the cookie coding to find out
exactly what variables were being created
at ATS and to see if FB alters their coding
to query the new variable strings. If it matches,
then we have a conspiracy of epic proportions
and proof that FB is data mining ATS.



posted on Aug, 25 2010 @ 12:26 PM
link   

Originally posted by boondock-saint
However, if ATS starts sending mass quantities
of people to FB, all FB has to do is add a few
lines of script to their java scripting to data mine
the variables used by ATS.

You are just plain wrong. And I've shown you how you are wrong.



posted on Aug, 25 2010 @ 12:33 PM
link   

Originally posted by SkepticOverlord
Cookie data is indeed stored in the cookie, passed to the web server via the HTTP header, and not accessed until code somewhere in a web page (JavaScript, PHP, JSP, ASP, CGI, etc.) initiates a call to read a cookie. If the call is initiated via server-side code (PHP, ASP, JSP, CGI, etc.) the cookie data is not present in user RAM. Additionally, "Site A" cannot read the cookie data written by "Site B."

I can tell just by reading this statement
that you have never programmed in
your life else you would not be this naive.
I am NOT trying to belittle you in any way.
Please understand this


Bill, let me ask you a question.

If a script at ATS creates a variable called
megaData$ and assigns it a value of "1".
And DOES NOT write that variable or it's
value to a cookie.

Just where do you think that data is stored
for future use by ATS scripting???

It's NOT in the cookie !!!!
It's on the user's PC RAM Memory.

Now along comes another script
from FB who then queries the value of
megaData$ and then writes it to a database
field at FB. The value of megaData$
never passes through the cookie
OR is written to the cookie.
It's called a direct write.

But the data is still in memory.

The only way the cookie code facilitates
this process is through WHAT variables
are created at ATS. REGARDLESS of what
is written to the cookie.

And there is no way that you can say that
FB cannot get data from ATS unless you have
seen or written the source code at FB.

lol, I think you folks should have hired
me to do some consulting, hahahahaha



posted on Aug, 25 2010 @ 12:38 PM
link   

Originally posted by boondock-saint
Just where do you think that data is stored
for future use by ATS scripting???

In server RAM, not on the user's machine.

You're continually attempting to push information that is just plan wrong, despite repeated attempts to show you that you're wrong... as well as an apparent refusal to simply look at our page's source code to confirm what JavaScript is running.

If you can provide a functioning proof of concept, I'll consider it... but until then, please stop perpetuating false information.



new topics

top topics



 
67
<< 13  14  15    17  18  19 >>

log in

join