[Vision2020] A quick rant about the term "metadata"

[Paul Rumelhart]

It does bug me.  And it's pointless for them anyway, since I run AdBlock 
Plus and NoScript on Firefox and hence never see the ads anyway.  I also 
mitigate it by popping my email to my home machine.  I'm sure they scan 
it coming in, but I doubt they keep a copy of every email that I delete 
for very long.  It wouldn't make business sense to have to have that 
amount of extra storage on hand.  I've been aware of these kinds of 
things for a long time, and have in the past brought things like this up 
on the list.  I figure it's not gotten so bad that I need to go to the 
trouble of setting up a mail server and changing every account I've 
opened on the net over to it.  Not yet, anyway.  I'm sure it will get 
there someday.

The fact that corporations do sell my data in certain cases doesn't mean 
I approve of it in the slightest.

Paul

On 07/04/2013 03:12 PM, Scott Dredge wrote:
> Companies having been selling data for eons to anyone willing to pay 
> for it.  And lots of times these companies will allow you to pay a 
> premium to keep your data more secure.    For instance, for $5 per 
> month, you can get an unlisted Verizon phone number:
> http://hothardware.com/News/Verizon-Claims-5-Monthly-Fee-Necessary-For-Unlisted-Number/
>
> One question I have for you is that since Yahoo a full month ago 
> started scanning & analyzing emails for ad targeting, why aren't you 
> bugged by that?  Is it because it's a free service and if you were 
> concerned about them rooting through your emails, you'd switch and pay 
> for a premium account that doesn't do that sort of thing?
>
> I'll concede that ad targeting is less disconcerting than the thought 
> of the big, bad, dangerous almighty government tracking you and the 
> lines for limiting their power are (or will be) drawn for them by 
> lawmakers and the Constitution (or whatever tatters are left of it as 
> Sunil points out).
>
> -Scott
>
> ------------------------------------------------------------------------
> Date: Thu, 4 Jul 2013 12:33:20 -0700
> From: godshatter at yahoo.com
> To: scooterd408 at hotmail.com
> CC: vision2020 at moscow.com
> Subject: Re: [Vision2020] A quick rant about the term "metadata"
>
>
> It's OK if they pay for it, but not if they force them to give it 
> over?  Are you OK with all the companies we do business with selling 
> all our data to the government, or do you draw a line somewhere?
>
> Paul
>
> On 07/04/2013 10:08 AM, Scott Dredge wrote:
>
>     The term 'metadata' bugs you.  What bugs me is that this 'valuable data' is being sucked
>     up by the NSA 'wholesale' instead of the telcos charging them a pretty penny for it.
>     The whole mess seems to be creating a lot of bugging.
>
>     -Scott
>
>
>     Paul wrote:
>
>     As a computer science guy, this bugs me.
>       
>     I've seen the term "metadata" abused in the news media and online often
>     in relation to phone data the NSA is sucking up wholesale.
>       
>     "Metadata", as the media is using the term, *is* data.  Things like
>     phone numbers, dates, times, duration of calls, cell phone tower
>     identifiers, etc *is* data.
>       
>     The term "metadata" has a specific meaning, it's data about data. For
>     example, metadata on the data that Verizon was forced to give over would
>     look something like this:
>       
>     Field                     Data Type  Size  Comment
>     Originating Phone Number  NUMBER     10
>     Called Number             NUMBER     10
>     Call Duration             NUMBER     4      Length of call in seconds
>     Date of Call              CHAR       10     Date format: MM/DD/YYYY
>     Time of Call              CHAR       12     Time format: HH24:MI:SS.nnn
>     ...
>       
>     And so on.  I couldn't care less if they grabbed the metadata from all
>     the phone carriers.  It would be a bunch of database table descriptions.
>       
>     Don't kid yourself, what they grabbed from the telcos was actual data,
>     and valuable data at that.
>       
>     Paul
>       
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.fsr.com/pipermail/vision2020/attachments/20130704/333a8340/attachment.html>