Posts by DZ-Jay

@Lou Gosselin

Speaking of forum trolls...

-dZ.

Re: No iphone4 for me

Just buy the damn phone and hold it my way. It's not a big deal.

- Steve.

--

Sent from my iPhone.

(Sorry, couldn't resist! --dZ.)

Not quite

What the parent poster said may not be strictly accurate, but his general point is valid: pure HTML and the DOM can be easily manipulated at the client side, so if that is what your site depends on to display ads, your revenue will be at the mercy of ad-blocking plug-ins and extensions.

Flash, on the other hand, allows the interjection of ads within the content, with no easy way to block it or prevent it, without blocking the entire thing.

-dZ.

Re: location data

>> "Location data could be anything from IP address, which can then be mapped geographically, to GPS data. I suspect it's the former."

Wrong. The problem is that the application requests access to location services for its functions, and the Flurry code uses this to send geo-location information along with the rest of the identifying information.

Like someone else said above, the user has no control on what data is collected, how it is collected, and for what purpose.

-dZ.

Really?

And where did you get this information from? I'm not saying they do not have the ability, I'm just curious to know where it is documented, for I haven't seen anything about it.

-dZ.

@Lou Gosselin

Another hallmark of wit and eloquence; you have shattered my argument to pieces with your pointed retort.

-dZ.

@AC: blah blah

>> "Google have stated that this removal feature will not be used much, and will be reserved for Genuine emergencies like security risks etc."

I don't get it, first Google claim that there was no harm or risk, since the app basically did nothing, yet they went ahead and used the kill switch they claim will only be used for "emergencies". How is this not abuse of the power?

They have control to do something which is controversial and claim to reserve the right in case of an emergency, then go ahead and exercise that power on a self-proclaimed non-emergency situation. And on top of that, they use double-speak to convince us that "no, really, we don't mean to use it, it's only for emergencies. Really. For sure. Trust Us (tm)."

-dZ.

-dZ.

What the fuss is about

The problem is that Google ignored the broadcast bit, and just logged ALL SSIDs and MAC addresses straight from the packet header, regardless of whether they were broadcast or not.

-dZ.

Re: Getting the rants right.

>> "Please don't start in with the battery time."

Wow, what a counter-argument, there!

Let's try that with some other things, shall we?

- Sky-diving is the safest sport ever! And please, don't start with the "you can die" bit.

- Cars never, ever crash, that's a fact. Please, don't start with the national statistics.

- All nerds get laid every night. Please, don't start with the "with a girl" remark.

- I can predict the future. And please, do not start in with accuracy.

You're right, ignoring the actual point of an argument does work!

-dZ.

Speaking of ignorance

Have you considered the myriad application level Internet protocols that for historical reasons do not directly support encryption, such as POP3 log-ins, and even some IM protocols?

Also, telephone communications travel freely and unencrypted through a wire, and it is trivial to intercept them, yet we still make laws to prevent this. Likewise trespassing laws are effective even when the only physical barrier is a short fence and a "do not enter" sign, because physical ability does not necessarily equate permission.

In other words, just because something is possible does not mean you should do it, or be allowed to do it.

-dZ.

Re: Hmm...

There is a difference: *You* use your Android phone for such purpose, and enable geo-location services. What about those of us that do not?

Why should I not have the choice to not have my geo-location and wifi-network indexed and tracked-- especially if I didn't request the service to begin with?

-dZ.

Re: improvement

I'm not talking about the payload data, I'm talking about the headers.

If I *specifically* configured my network to be secure and to *not* broadcast the SSID publicly, doesn't that at least show my intent to maintain some privacy? Why is it then legal for someone to still analyse the packets of the transmission to extract the SSID from the headers?

That's why I made the analogy: the fence is 3-foot high but clearly has a sign stating the privacy intentions. It shouldn't be an excuse to jump it just because it is physically possible, when it is clearly stated that you are not welcome to do so.

-dZ.

Re: I hate spiders too

c) Right after Apple has proven to the world that native, locally run Apps is where the money is.

-dZ.

Fine...

Good luck with that! While you and a few others were bitching rather loudly about Flash been blocked from the iPhone and the iPad, the rest of the world--at least the important parts the people care about--has been submissively re-working their sites to support these devices and their lack of Flash support. Why? Because that's where the users are.

-dZ.

Re: saving for post-processing?

You didn't read the report, did you? Let me help you a bit: The report states that the program in question (gslite) extracts the headers of the *all* packets--encrypted or not--parses them into their respective fields (e.g. MAC Addresses, SSID, etc.), links that information to the current GPS coordinates, and stores it.

It then takes the payload of each packet and, if it is a secure network, discards it; if it is a non-secure network, stores it verbatim without further processing.

So you see, the bit about "saving for post-processing" was *NOT* the MAC Addresses and SSIDs--they already had that. It was the *payload* of each unencrypted packet.

The fact that they configured the software to discard payload data from secure networks but not for non-secure ones shows intent to capture such data.

-dZ.

Re: Ads sent using my bandwidth?

Yes, these iAds will count towards your monthly limit. But so do any other ads from any other ad-supported application you install. Nothing has changed in this regard. The differences are two-fold: Firstly, that instead of serving ads from AdMob and other third-party networks, some of the ads will be served by Apple. Secondly, that no information may be shared for the sake of showing ads and collecting analytics.

-dZ.

Re: I see a problem here

That's only a problem if the Reader engine merely analyses the page source. I believe it does much more than this: I think it works on the generated output of the page render (recall that this is not necessarily an application-level enhancement to Safari, but to the WebKit framework itself).

-dZ.

Re: So very little for end users then...

Actually, there's quite a bit for end users there.

If we accept that developers of free or cheap apps will use ads to support their development, then they will go with the advertising system that offers them the most convenience or money, or both.

Up until now, all they had to chose from has been a series of sleazy companies that collect and hoard as much personal information from users and attempt to make money out of this by selling it around, diluting privacy and control of such data.

This is bad.

Now Apple promises to deliver a purportedly more effective advertising system that will be even more convenient for developers since it is included as part of the SDK and iTunes environments. With this system, iOS developers can get paid directly as part of their app transactions, easily and conveniently.

However, the real news here is that Apple has already said that developers--and advertisers--will get *NOTHING ELSE*. The ads will show, users may click on them or not, and impressions will be marked and in-ad sales will be tallied. The Advertisers will get aggregate data of impressions; the developers get aggregated sales totals. That's it. Just like traditional newspaper or TV ads.

Apple made a point that the end-user's privacy will be respected, inasmuch as the devices try to do today by controlling the user experience and requiring the user's consent for certain transactions. The user will be able to exit from an interactive advert at any time, and none of his personal or device information will be collected nor shared with developers or advertisers, ever. The advertiser nor the developer may impose anything on the user, other than a display of a banner on his app. Attempting to extract additional information from the advert transaction by non-approved means will violate the license agreement, and you know how Apple deals with this in the App Store.

This is--if not good--a much better situation than the status quo. Developers and advertisers will complain about the lack of information and control (and indeed, already have), but will use the system because of its convenience and effectiveness.

I agree that more adverts are never a good thing, but hopefully this will not mean *more* adverts, but actually less sleazy, annoying, and invasive adverts. If the user must be subjected to ads, let he be in control.

-dZ.

Re: Glad they cleared that up

Repeat after me:

World...

Wide...

*ahem* DEVELOPER *ahem*

Conference

Many developers would indeed do good to be interested in the size of their prospective target market.

-dZ.

Re: I don't see why not.

>> "There is no reason why Windows 7 Mobile can't, except that it wont."

There is one good reason: Steve Ballmer and his clueless inability to "get" the market.

-dZ.

Re: Fix the OS. No big deal.

There are legitimate reasons why an application needs to access this information from the device. There is no legitimate reason why the application should send it to a third-party, especially without the user's consent.

The Flurry code is a library which developers include within their App, and as such, even the App developer has little control over what it does. They include it for the sake of what Flurry offers in return (traffic and usage analysis, maybe even payment).

The fact is that device identifying information is being surreptitiously extracted by a third-party library for uses which have absolutely nothing to do with the App's functionality. So, even if the user agreed to the App extracting this information as part of its usage, he still has absolutely no idea--and no way to control--that the data is being collected by a third party.

-dZ.