Hacker News Reader

Comment by maukdaddy | Hacker News Reader

sigh

Source link without the lifehacker bullshit: http://online.wsj.com/article/SB1000142405274870469400457602...

edit: Direct link to awesome visualization tool : http://blogs.wsj.com/wtk-mobile/

What's the HN etiquette on link sources? I read it first on lifehacker, then on WSJ. I thought it was appropriate to give credit to the source I read.

I think it is to link to the best source. In this case the WSJ, both because of lesser sensationalism and their original work.

However, it was considerate of you to think it through like that. :)

The official policy is to go to the original source of the story, not the original source YOU read.

I completely agree with you and everyone else who takes this stance.

However in this case I'm willing to let it slide as in the past two days this story has been submitted three times* with a total of 30 upvotes and one comment between them.

In cases like this I usually upvote the first submission and file under 'Things that I think are interesting, but other people seem not to'.

* http://news.ycombinator.com/item?id=2018906 http://news.ycombinator.com/item?id=2019508 http://news.ycombinator.com/item?id=2018902

Fair enough, but the official guideline is as follows:

"Please submit the original source. If a blog post reports on something they found on another site, submit the latter."

I think PG sacrifices a lot of clarity for some cleverness here, so here's my rewrite, that I believe is identical in spirit, and hopefully at least slightly clearer:

"Please submit the original source. If a blog post reports on something they found on another site, submit the site the blogger found it on."

Personally, I'm not a rules nut, but he DID ask for the official stance.

In some instances it is more appropriate to link to a blog:

Don't abuse the text field in the submission form to add commentary to links. The text field is for starting discussions. If you're submitting a link, put it in the url field. If you want to add initial commentary on the link, write a blog post about it and submit that instead.

Personally, I think a comment explaining the motivation for linking to a blog rather than the original source, as dshankar provided, is sufficient to justify a blog link.

Definitely true, but you need to determine if the blog post is adding value to the discussion, or just sensationalizing it. The world is full of people who can borrow a few lines and blow them out of proportion, but we should (and do) expect HNers' to do better than that.

A lot of blog posts wind up being just extremely wordy retweets.

I'd also submit that a blog post is the way to go if the source material is either too technical or too difficult to follow, and a blog post simply makes more sense to the HN readership. Or, even if the article is just way too long. Linking straight to a Nature article may be too much for the casual reader.

give it a mention if you feel like and that's it. But in the end, it's your submission. Do whatever you please.

Don't expect many up links if you read out in 4 chan though

Worse, even the WSJ article has the whiff of sensationalism. For example, this is what you find very near the top of the article:

These phones don't keep secrets. They are sharing this personal data widely and regularly, a Wall Street Journal investigation has found.

An examination of 101 popular smartphone "apps" -- games and other software applications for iPhone and Android phones -- showed that 56 transmitted the phone's unique device ID to other companies without users' awareness or consent.

Later on, the UDID is called "supercookie" and the article emphasizes the fact that it "can never be changed or turned off".

That would be truly scary if they showed some proof that the user, as a person, could be easily identified by their phone's UDID. Okay, the carrier has that information, but who else has it? Somehow I don't think that the relationship between your phone's UDID and your identity is something easily available to just about anyone.

Are you kidding?

The UDID and the phone owner's name are easily correlated. As soon as you register for an account on a game or app, you will connect UDID to your email or first/last name. As soon as that happens, it could easily end up in Rapleaf or another system for other data brokers to get access to.

The connection just has to happen once, in one app, for all of them to benefit from it.

On the plus side, an app getting this data could auto-register you since it knows you based on your UDID as soon as you install the app, just sending you an email confirmation and a password. :-)

In order to get any online data broker interested in your data, you have to tie it to their browser cookie.

On iOS, this is hard, thanks to sandboxing. You pretty much have to redirect the user to the Safari browser with the UDID in the query string - which is a pretty crap experience for the user, which is why it's rarely done.

Even then you've only gotten the data into the mobile browser, which is not what the data market wants to pay for right now. People still predominantly buy things through their desktop computers.

I don't know if it's vanity or narcissism or what, but everyone assumes their 'data' has a lot of commercial value. It doesn't. Back when I was running an iPhone analytics startup, I looked into all of this stuff. Wasn't even worth the development work to monetize it.

Would you have to actually redirect them to Safari or could you do something like load a hidden webview? (not quite sure of the right terminology here)

I was thinking the iOS equivalent of a webpage with a hidden iFrame.

Cookies are sandboxed, so the cookie you write in your in-app 1x1 pixel webview can't be read by the Safari browser, making it useless.

If we could cookie the user properly it's what I'd use for analytics instead of the UDID.

Launch Safari to have them complete registration online?

Thanks, that makes sense.

Why do you think you need safari or a browser? There are plenty of other (and easier) ways to make HTTP connections in iOS and implement account registration.

Implementing account registration, collecting an e-mail, and then using that e-mail as a unique ID to append data to the data broker's database -- this is possible, but rightly considered PII, so no data broker does this without user opt-in. (In this case the risk exceeds the rewards anyway, but that's another discussion.)

If you're talking about setting a cookie with the data broker's user ID, which then can be read by the data broker on other websites - which is the standard way of shuffling non-PII data around in the absence of an explicit user opt-in - then this doesn't work due to iOS' application sandboxing. You can set a cookie with the data broker's user ID, but the data broker won't be able to retrieve it when the user's off elsewhere surfing the web, when it matters.

Using a cookie doesn't make something non-PII...

Your user-agent and request details are enough for me to tie you to an existing account: https://panopticlick.eff.org/

Nice. According to the panopticlick, I'm the only one with my exact plugin details. None of the other data is even needed to identify me, though being one of the .005% of people using Firefox 3.6.13 on Ubuntu 10.10 probably helps.

I'm not even sure the carrier has the information. At least in countries where the iPhone is sold unlocked.

The UDID has nothing to do with the IMEI/IMSI which are both known by the carriers.

I'd be worried if the carrier has this info. I bought the iPhone 4 from Apple, the micro SIM from vodafone, two separate unconnected transactions.

So what stops the carrier to tie your billing information (which I presume has your name and address on it) to the SIM purchase ?

Every time you switch that phone on that phone ID is tied to the SIM on the network.

Upboated for recognizing LifeHacker is basically Internet regurge.

Reply on news.ycombinator.com