Google reveals fistful of flaws in Apple's iMessage app - <AUTHOR> https://www.bbc.co.uk/news/technology-49165946 <comment><USER3> I'm honestly appalled at the number of comments in this thread trying to lambast Project Zero for the good work they do in improving software security. Even if Google specifically started and ran Project Zero to target competitor's products (which they didn't, and they don't, there's over 100 bugs found by P0 in Google products), it wouldn't matter because the effect would still be that the online world is a safer place with more secure software.

Of all places, I thought Hacker News would have a community which understands the critical importance of security research and the fact that fixing software security bugs is a net benefit to everyone, every time, all the time.

<comment><USER4> Hacker News has become tribal and politicized, much like many other parts of the internet.

<comment><USER5> Very true. And both Apple- and Google-related discussions brings out both sides in force. In this case we have a story that involves both, so I am not at all surpised to see it get contentious.

Personally, I've observed (via the voting mechanism and commentary) several different cohorts of people visit HN throughout the day. You get a real sense that opinions are regional and tribal. Europeans in the early morning, then east coast and flyover states, and then brace for impact when SV (in particular Googlers and/or pro-Googlers) pile on. It's fascinating.

<comment><USER6> I think the trends you are seeing, are most likely due to bias and not objective analysis. Try as we might, humans are subjective beings and truth is difficult for us discern, especially with so many variables.

<comment><USER5> Well, yes, of course I have not done a rigorous scientific analysis. But I can tell you from repeated experiences that if I say anything a bit critical of Europe or Europeans then I will get downvoted heavily in the wee hours of the day, and almost always will make that up and then some about midday (Pacific time). On the other hand, if I say something critical of Google then in the wee hours it'll usually get a bunch of upvotes, and then lose them all about midday.

No science here, absolutely, but I have had great success so far predicting in advance what the voting pattern is going to be on a comment I make. I treat it a bit like a sport.

</comment></comment></comment></comment></comment><comment><USER7> It seems like peoples hatred for Google is leaking over to how they think vulnerability disclosures should happen.

Reading through the comments is disorientating - people are angry that researchers are.. _gasp_... researching vulnerabilities. It's not some faceless Google Incarnate monstrosity, they are paid researchers (humans, too!). If it was Cure53 that did this, for free, and made the exact same announcement no one would bat an eye.

Good on _whatever_ company does vulnerability research, follows established protocols in disclosure, and makes the world a safer place.

<comment><USER8> When I read these comments I also feel like people must believe P0 is some kind of new thing that Google came up with. In fact, vulnerability research labs have been A Thing in the security field since the mid-1990s (I worked at what I believe to be the first commercial vulnerability lab, at Secure Networks, from '96-'98, along with much smarter people like Tim Newsham and Ivan Arce). And they've always been taking this kind of (dumb) flak regardless of which company they're attached to.

If companies like Apple or Microsoft are alarmed by the optics of Project Zero, they are free to stand up their own vulnerability research labs; they have the resources and they would immediately find takers in the research community.

End-users, meanwhile, should have nothing but gratitude for P0, since that project essentially represents Google donating fairly expensive and scarce specialized resources to public interest work. Vulnerabilities that P0 finds are vulnerabilities that aren't being sold through brokers to the global intelligence community. Message board talk about the "black market" alternative to bug bounties is almost always overblown, but P0 traffics in _exactly_ the small subset of vulnerabilities that do have substantial, liquid markets.

<comment><USER9> > End-users, meanwhile, should have nothing but gratitude for P0, since that > project essentially represents Google donating fairly expensive and scarce > specialized resources to public interest work.

Why should end-users "have nothing but gratitude" when vulnerabilities are disclosed and they are immediately placed at risk until they get a chance to update, _even when the vendor has promptly provided a correct patch_? I know I certainly don't appreciate that and can't reasonably expect any normal person to appreciate it either.

<comment><USER10> First: everyone is already at risk for everything that P0 finds. The difference is no one if publicly talking about the flaws or the risk in the open.

Second: P0 never "immediately places people at risk" because they always follow responsible disclosure.

P0 has a well documented and frankly fairly conservative policy before anything is publicly disclosed. Do vendors want more time to fix things? Sure, they always will. Do P0 disclosures sometimes happen publicly before the vendor has things fixed? Yes, Occasionally. However, looking at the net, P0 has provided far more value than they detract with public disclosure of flaws

<comment><USER9> > First: everyone is already at risk for everything that P0 finds. The > difference is no one if publicly talking about the flaws or the risk in the > open.

You don't see how the risk might increase when more people learn about the vulnerability?

> Second: P0 never "immediately places people at risk" because they always > follow responsible disclosure.

What? They provided proof-of-concept exploits _just one week after the patch was provided_. That's apparently not "immediate" in the eyes of security researchers, but try asking the average user if that's enough time to expect them to update.

> P0 has a well documented and frankly fairly conservative policy before > anything is publicly disclosed.

Yes, and it could be worse, but it's also not great and could also be better.

> Do vendors want more time to fix things? Sure, they always will.

That was never my argument. I never said they should get more time to fix things.

> Do P0 disclosures sometimes happen publicly before the vendor has things > fixed? Yes, Occasionally.

Again, I was specifically NOT arguing about disclosing _before_ the patch is provided.

> However, looking at the net, P0 has provided far more value than they > detract with public disclosure of flaws

And I never singled out P0 or claimed otherwise. I'm disputing the entire practice by whomever is practicing it.

<comment><USER11> > You don't see how the risk might increase when more people learn about the > vulnerability?

Do you see the risk of having a vuln that is completely unknown still exploitable in your stack?

> What? They provided proof-of-concept exploits just one week after the patch > was provided. That's apparently not "immediate" in the eyes of security > researchers, but try asking the average user if that's enough time to expect > them to update.

Why are critical issues not being patched within 48 hours? The disclosure of the issue can only mitigate so many things, and patch schedules by vendors is not one of them. If your vendor takes 3 months to patch the system, is that the requisite amount of time the researcher should be expected to wait before disclosure? That seems preposterous.

> > Do vendors want more time to fix things? Sure, they always will.

> That was never my argument. I never said they should get more time to fix > things.

So then that is your argument. What is a reasonable amount of time, and why is your arbitrary value not arbitrary? A day, a week, a month, a year; when can you ever be sure you've reached the critical threshold of patched systems using a rule of thumb?

</comment></comment></comment></comment></comment></comment><comment><USER8> I believe Natalie Silvanovich is giving a talk at Black Hat about some of these next week. Silvanovich is a machine.

<comment><USER12> Indeed: [https://www.blackhat.com/us-19/briefings/schedule/#look- no-h...](https://www.blackhat.com/us-19/briefings/schedule/#look-no-hands---- the-remote-interaction-less-attack-surface-of-the-iphone-15203)

<comment><USER13> While being a Project Zero member is cool and all, Natalie is also a well- known Tamagotchi hacker [https://natashenka.ca/about/](https://natashenka.ca/about/)

</comment></comment></comment><comment><USER14> >We are withholding CVE-2019-8641 until its deadline because the fix in the advisory did not resolve the vulnerability

Wonder how this happened? rushed patch or perhaps they only tested against a submitted PoC? Only a week left until the defcon talk. Still listed as "fixed" in Apple's release here: [https://support.apple.com/en- us/HT210346](https://support.apple.com/en-us/HT210346)

<comment><USER15> Other security updates released on the same day last week caused Macs to kernel panic every time they went to sleep [0]. Apple software quality is not what it should be, and hasn't been for quite some time.

[0]: [https://eclecticlight.co/2019/07/24/dont-apply-high- sierra-s...](https://eclecticlight.co/2019/07/24/dont-apply-high-sierra- security-update-2019-004-apple-has-pulled-it/)

<comment><USER16> > Apple software quality is not what it should be, and hasn't been for quite > some time.

Quality is a moving target: I know something about the quality of Safari, and the quality has been getting better over the years (that said, I admit the recent Mobile Safari Betas have been really shit, hopefully the release will be good).

Maybe it is comparitive: for example Safari's quality it is nowhere near as good as the Chrome team's quality (which is unbelievably good: regular updates across thousands of different Android device types, across thousands of versions of Android, with immensely complex software).

Also social media now means that we hear about quality issues - we raise the bar on what we think is acceptable.

Do you think Apple's software quality has not improved over the years?

<comment><USER15> _> Do you think Apple's software quality has not improved over the years?_

I think quality has actively declined.

As you know something of the quality of Safari, I'll limit myself to that. Safari over the past several years has made myriad design changes that I heavily disagree with (killing extensions, removing user control over website data, baffling UI decisions), but even though those changes have made my browsing experience worse they may not be objectively considered "software quality." Instead, I'll focus on stability and bugs.

When macOS Sierra launched, I had to deal with weekly lockups and reboots of the OS that I mentioned here: [https://news.ycombinator.com/item?id=13159008](https://news.ycombinator.com/item?id=13159008). I tracked the issue down to Safari 10, which introduced new resource leaks that eventually brought the entire system down after being left open. Even after major releases of the browser eventually stopped forcing restarts, leaving Safari open for extended lengths of time will still cause not just instability and misbehavior in itself (e.g., popover arrows eventually disappearing), but also knock-on problems in completely separate applications, including greyed-out standard menu actions that return immediately once Safari is quit. This resource exhaustion is independent of the number of tabs, but handling of large numbers of tabs has also regressed: tabs now crash or unload regularly, and there is no easy built-in way to see which; this causes data loss and erroneous cookie manipulation when the tabs are reloaded when navigating back to them. Pages often do not add correctly to History, particularly from clicked or OpenSearch search results, with mismatched titles/URLs or entirely missing entries: to this day, searching Wikipedia with Quick Website Search gives a tab title that does not match the page or the history item, and interaction with the back/forward cache is likely to exacerbate this. Worse, pages often disappear entirely from autocompletion, causing mistaken page loads and spurious searches when expected results are missing. A couple of years ago, Safari stopped preventing the Mac from sleeping while a download was in progress, forcing me to copy URLs into Terminal to download with a caffeinated curl command instead to avoid truncated files. A recent release of Safari marked random unvisited links as visited, likely due to some newly introduced hash collision, and was not fixed for many months.

This is just what I can recall off the top of my head, in one limited aspect of a single application. All of these were newly introduced errors; some major, many persistent. I sometimes have call to use older versions of Safari, and while definitely slower and less compliant, in many respects they are remarkably better in terms of feature stability and experience.

</comment></comment></comment></comment><comment><USER17> This type of thread always goes alot differently when the flaws revealed aren't in Apple products

<comment><USER18> Choice supportive bias is real, and it seems to scale with price

</comment></comment><comment><USER19> Apparently iOS 12.4 came out last week but I have automatic updates on and the update is not installed. I just triggered it manually a moment ago.

<comment><USER20> Can anyone explain iOS "automatic" updates? They never seem to work for me.

<comment><USER21> You have to have the phone charging overnight, usually. But sometimes I wake up in the morning to a message that it had an issue and couldn't update.

<comment><USER22> I _always_ wake up to this message, and have to do it manually. I don't know why.

</comment></comment></comment></comment><comment><USER23> Project Zero continues to be a Good Thing

</comment><comment><USER24> Is this why Apple also quietly released updates for older devices as iOS 9.3.6 and 10.3.4? IIRC Apple has only patched EOL'd iOS releases once before - <USER2> 6.1.6 for the ssl gotofail?

<comment><USER25> That was for the GPS 10-bit bug. [https://www.theregister.co.uk/2019/02/12/current_gps_epoch_e...](https://www.theregister.co.uk/2019/02/12/current_gps_epoch_ends/)

Apple's runs out in November 2019 instead of April.

<comment><USER24> Apple's changelogs are often incomplete at time of release and updated with additional CVEs later. A gps fix sounds like a convenient cover story for an emergency 0day patch for imessage, for example.

</comment></comment></comment><comment><USER26> Interesting that there isn't a post on Project Zero's blog. That's typically how they do public notification.

<comment><USER27> I definitely would've preferred that to the BBC article.

ZDNet seems to be the better / primary source on most other articles: [https://www.zdnet.com/article/google-researchers-disclose- vu...](https://www.zdnet.com/article/google-researchers-disclose- vulnerabilities-for-interactionless-ios-attacks/)

</comment></comment><comment><USER28> I wonder what kind of infrastructure they had set up to find these vulnerabilities and extract names of classes and methods. Do they jailbreak iPhones and run fuzzers directly on the device? Do they analyze IPSWs directly?

Edit: _and explains how to set up tooling to test these components._ I'll wait for the BlackHat slides.

<comment><USER29> > extract names of classes and methods

This is very easy to do using tools such as class-dump if you can get access to the binary (either from the IPSW, or sometimes directly from the shared cache).

</comment></comment><comment><USER30> Glad to see tech companies holding each other accountable. I hope the white hat hacking between these folks continues. The more vulnerabilities found, the safer our data will be.

</comment><comment><USER31> TBH, while I think the iMessage service is invaluable, the app itself is often buggy for me. On OS X, it often hangs w/ the spinning beach ball when attempting text input, the iCloud sync can be spotty, and the cardinal sin, on my iPhone X, there are inexcusable screen draw bugs w/ orientation rotation, or w/ the keyboard popping up to type....so I am not entirely surprised. It is an app in need of a good overall bug hunt.

<comment><USER32> One bug I've noticed on iOS is the bar with the message text field and the send button sometimes being displayed at the bottom even if you're on the message list view.

</comment></comment><comment><USER33> TL;DR Apple happily fixes what Google's hackers uncover and responsibly disclose but the beeb desperately spices things up because clickbait ;)

<comment><USER34> Wish I had a bunch of people testing my code for free and giving me 30 days to fix things before anyone else found out.

<comment><USER35> Even better when your competitors do it!

Think if Google instead of disclosing these responsibly would leak one bug to hackers every month or so. How many would stay on iMessage efter getting owned for the tenth time??

</comment></comment></comment><comment><USER36> Meanwhile google keyboard collects everything you type and android collects everything you say. Who needs bugs..

</comment><comment><USER37> Does anyone know how to file a bug report for iMessages? I have a slew of bugs I'd like to report from my day to day usage.

<comment><USER38> [https://feedbackassistant.apple.com/](https://feedbackassistant.apple.com/)

</comment></comment><comment><USER39> On the surface it appears Google is spending millions of dollars to expose flaws in competitor's products.

<comment><USER7> Words are wonderful. Try saying it this way:

Google is spending millions of their own dollars to freely help other companies (and themselves!) enhance their security and close holes malicious actors can exploit.

Now replace "Google" with any other company or independent researcher of your choice. If you're no longer angry, you're being biased solely because its Google and not someone you like.

<comment> ctrl-j My biggest question would be how many security vulnerabilities Google uncovered and disclosed on their own platform. If they are being good and helping other companies - great! But if they're also profiting by FUD'ing them - then we should call them something _other_ than white hats.. grey hats maybe?

<comment><USER40> Google fixes its shit before the 90 day deadline. Apple could hire the talent it needs to do the same.

<comment><USER41> Well, Apple released a patch for all phones back to the 4s released in 2011. What are the chances that security patches for Android phones make it to phones released even two years ago?

Even Microsoft released a patch recently to a security vulnerability found in Windows XP.

<comment><USER42> Android doesn't need a system update to update the messaging app.

<comment><USER41> But it does need system updates to update parts of the system....

<comment><USER42> The point is that this is a pretty small portion of all security updates. Compare to iOS, where updating the browser or iMessage (both with very large vulnerability surfaces) requires a system update.

<comment><USER41> You act as if there is a difference. It's not like Apple pushes the entire OS down for a minor update. Either way it's a delta.

But that "pretty small portion" doesn't matter if you can't patch it.

<comment><USER42> > You act as if there is a difference.

There is a large difference. One is an automatic app update while the user continues working. The other requires the user to stop everything they're doing and reboot their device.

<comment><USER41> Or the user can just tell it to update later on when they aren't using it.

With the benefit that all necessary components are updated together and that Apple can push out any updates world wide without waiting on the carriers....,

<comment><USER42> > Or the user can just tell it to update later on when they aren't using it.

This is how devices stay vulnerable.

> With the benefit that all necessary components are updated together

The whole app is already updated atomically. There is no benefit here.

> and that Apple can push out any updates world wide without waiting on the > carriers

The same as a Pixel or Android One device. The only difference is that app security updates are artificially slower on iOS due to poor design, and for apps like browsers, this is a fatal flaw.

<comment><USER41> _This is how devices stay vulnerable._

As opposed to most Android phones that never get system updates? As opposed to Apple releasing an update two weeks ago for all iOS devices back to 2011?

 _The whole app is already updated atomically. There is no benefit here._

The Safari app is also used as an out of process web view for other apps as is the messenger app...

 _The same as a Pixel or Android One device. The only difference is that app security updates are artificially slower on iOS due to poor design, and for apps like browsers, this is a fatal flaw._

It's estimated that Google may sell 1-2 million phones a year and Android One phones are not much more ubiquitous. Even then Google only promises updates for two years.

<comment><USER42> > As opposed to most Android phones that never get system updates?

Don't buy them. Problem solved. Do you avoid Linux entirely because there exist Linux-based routers that are never updated? No, you buy Linux-based routers that _are_ updated.

In this case, the choice is between properly updated Android phones, poorly updated userspace iOS phones, and poorly updated base system Android phones. The obvious choice is a phone from the first group.

> The Safari app is also used as an out of process web view for other apps as > is the messenger app...

As is Chrome on Android. Since Android is designed in a way that apps can gracefully recover from arbitrary processes being killed, this does not matter. Chrome gets updated, the process restarts, and the page the user was viewing in the web view reappears. If the app wasn't in the foreground, the user won't even notice.

<comment><USER41> So their are approximately 2.5 billion Android devices in the world and less than 2% are sold by Google and they are the only ones getting updated and you don't think that's a problem?

But yet every single Windows PC sold by any vendor can still get updates directly from Microsoft.

 _In this case, the choice is between properly updated Android phones, poorly updated userspace iOS phones, and poorly updated base system Android phones. The obvious choice is a phone from the first group._

You are really claiming that Android has a better update strategy than iOS and is more secure? Which Android phones from 2011 are still getting updates? 2013? 2015? Heck 2017?

<comment><USER42> > you don't think that's a problem?

It's a problem, just like the routers that aren't getting updated. It's not my problem.

> You are really claiming that Android has a better update strategy than iOS > and is more secure?

Yes. I've already explained why, and you haven't refuted it.

> Which Android phones from 2011 are still getting updates?

I don't use eight year old phones, so this doesn't matter to me. If you use old phones, you could argue that iOS is marginally more secure than the Android options; but that argument is irrelevant to the purchase decisions of 99% of the people here who do upgrade devices regularly for whom there are Android options that are much more secure than iOS phones.

<comment><USER41> _If you use old phones, you could argue that iOS is marginally more secure than the Android options; but that argument is irrelevant to the purchase decisions of 99% of the people here who do upgrade devices regularly for whom there are Android options that are much more secure than iOS phones._

The average replacement time for cell phones in the US is 32 months.

[https://www.npd.com/wps/portal/npd/us/news/press- releases/20...](https://www.npd.com/wps/portal/npd/us/news/press- releases/2018/the-average-upgrade-cycle-of-a-smartphone-in-the-u-s-- is-32-months---according-to-npd-connected-intelligence/)

8 months longer than Google has promised updates.

[https://www.digitaltrends.com/mobile/what-is-android- one/](https://www.digitaltrends.com/mobile/what-is-android-one/)

And that's only with Android One phones. Most Android phones never get updates or are rolled out slowly waiting on the OEM and carrier.

<comment><USER42> > The average replacement time for cell phones in the US is 32 months.

That is not my replacement cycle nor the replacement cycle for most of the readers of this forum. It has no bearing on my purchase decisions nor the purchase decisions of most of the readers of this forum. For people who upgrade regularly, which is a group that includes me and most of the people on this forum, Android One and Pixel devices are more secure than iOS devices, and you appear to agree.

> 8 months longer than Google has promised updates.

Android One phones get security updates at least three years after release.

<comment><USER41> _That is not my replacement cycle nor the replacement cycle for most of the readers of this forum._

Well as long as it caters to you and the rest of the people on HN (have you done a survey?), I guess that's all that matters - not the other 2 billion people in the world....

 _Android One and Pixel devices are more secure than iOS devices, and you appear to agree._

Android One phones still have to wait on the manufacturer to update their phones. Yes, but they pinky promise they will. From the article I posted.

I've never had to wait on a manufacturer to get updates from my Windows PCs. Heck I still get updates for my Mac Mini running Windows 7 and Apple definitely had nothing to do with it. Why is the Android architecture so piss poor that they can't figure this out? This- an OS vendor licensing to OEMs and providing update - has been a solved problem for PCs for well over 30 years.

From the earlier article I posted.

 _While updates do still have to go through each phone's manufacturer, there's much less to check and update, so updates will generally arrive much faster. It won't be a day one patch like you'd expect on the Google Pixel range_

 _Each Android One phone is guaranteed to get at least three years worth of security updates from its release date, and up to two years of major Android releases, too._

 _Android One phones get security updates at least three years after release._

The iPhone 5s (2013) received 5 years worth of OS updates.

The 4s (2011) just received a bug fix earlier this month.

The 6s (2015) is still a more performant phone than any midrange Android phone released this year and can hold its own against high end Android phones that are two years newer. It would be a pity to replace it if it were an Android phone just because Google couldn't figure out how to update third party devices. My son is still using it.

<comment><USER42> > I guess that's all that matters - not the other 2 billion people in the > world....

I already explained the choices. For us, the obvious choice is a properly updating Android device. Any user who chose an iPhone or non-updating Android phone made a poor security choice. Any user who has a longer than three year upgrade cycle has no good options unless they use a community-maintained Android build.

> Android One phones still have to wait on the manufacturer to update their > phones. Yes, but they pinky promise they will.

They are guaranteed monthly security updates. If you have an example of one that hasn't had monthly security updates, that would be a breach of contract with at least the user and possibly with Google who certified the device as Android One.

Windows updates aren't guaranteed to work with arbitrary device manufacturers' custom drivers.

> [Irrelevant stuff about how long iOS devices are updated]

The comment you replied to was a correction to your claim about how long Android One devices are updated. That is the maximum period a user can get a secure device for because we have already established that all alternatives have non-working security update systems.

>The 6s (2015) is still a more performant phone than any midrange Android phone released this year and can hold its own against high end Android phones that are two years newer.

You have conceded that iOS is worse for security, so now you want to argue about performance. Android has iOS beat there, too. Here is a midrange Android phone one generation older than the iPhone 6 beating it at the most common task for phone users — opening apps: [https://youtu.be/hPhkPXVxISY](https://youtu.be/hPhkPXVxISY)

Here is a midrange Android phone of the same generation as the iPhone 6s beating it in the same test: [https://youtu.be/B5ZT9z9Bt4M](https://youtu.be/B5ZT9z9Bt4M)

Of course if you want to get off topic, a more interesting discussion than performance is usability, and Android is multiple generations ahead of iOS for what you can do with it and has been since at least the Verizon Droid, which came with driving navigation and voice control.

<comment><USER41> _You have conceded that iOS is worse for security, so now you want to argue about performance. Android has iOS beat there, too. Here is a midrange Android phone one generation older than the iPhone 6 beating it at the most common task for phone users — opening apps:[https://youtu.be/hPhkPXVxI*](https://youtu.be/hPhkPXVxI*)

I'm not arguing performance for performance sake. I'm arguing that a four year phone is still performant compared to many newer Android phones and it is getting _both* security updates and os upgrades 24 months and 12 months longer than the tiny percentage of Android phones that get either. It also doesn't have to wait for a third party OEM to decide to push updates.

I'm also criticizing Google for not knowing how to push updates to phones running its operating system without OEM intervention - something Microsoft figured out 30 years ago with PCs.

But you don't need to speculate how fast iOS users update their phones.

There are plenty of sites showing how many iOS users have updated operating systems compared to Android users:

[https://www.forbes.com/sites/ianmorris/2018/04/13/android- is...](https://www.forbes.com/sites/ianmorris/2018/04/13/android-is-still- failing-where-apples-ios-is-winning/)

So do have a cite showing that a larger percentage of Android users are running an up to date OS?

<comment><USER42> > So do have a cite showing that a larger percentage of Android users are > running an up to date OS?

You keep coming back to this irrelevant point. Many Android phones are insecure, just as all iPhones are. Don't buy them.

> I'm also criticizing Google for not knowing how to push updates to phones > running its operating system without OEM intervention - something Microsoft > figured out 30 years ago with PCs.

Who cares? Don't buy them. Besides, I already pointed out in my previous post that Microsoft didn't solve this problem. Do you blame Linus for all the routers that don't get updated, or do you just not buy them?

> I'm arguing that a four year phone is still performant compared to many > newer Android phones and it is getting both*

So is a five year old midrange Android phone, which is also as insecure as any iPhone. Don't buy them.

<comment><USER41> _You keep coming back to this irrelevant point. Many Android phones are insecure, just as all iPhones are. Don 't buy them._

Seeing that the latest iPhones you can get that hasn't received a recent patch is the iPhone 4 from 2010, where are "all of the insecure iPhones" - especially seeing that both Google and Apple routinely publish the percentage of devices running older OS's, there is no conjecture needed on which one is running a greater percentage of OS's with unpatched vulnerabilities - we have numbers straight from the source.

 _Who cares? Don 't buy them. Besides, I already pointed out in my previous post that Microsoft didn't solve this problem._

Seeing that I have a _Mac Mini_ from 2006 running Windows 7 that is still getting security updates and a Dell from 2009 running Windows 10, I think Microsoft solved the problem a lot better than Google. The other 2.7 billion Android users probably would care if they knew any better.

 _you blame Linus for all the routers that don 't get updated, or do you just not buy them?_

Linux is free open source software that anyone can use, no one pays Linus for using it, and Linus doesn't have much of any criteria about how it's used. None of that is true about Android. What makes Android Android is Google Play Services that is licensed by a commercial entity.

 _So is a five year old midrange Android phone, which is also as insecure as any iPhone. Don 't buy them_

There is no five year old iPhone that isn't supported and receiving security patches. Right now, there isn't any 8 year iPhone that hasn't received a security patch recently.

<comment><USER42> > Seeing that the latest iPhones you can get that hasn't received a recent > patch is the iPhone 4 from 2010

We already discussed this. iOS has a huge attack surface that can only be patched via system updates, which is horribly bad design and terrible for security.

> The other 2.7 billion Android users probably would care if they knew any > better.

If those billions knew better, they would get an Android One or Pixel instead of an instead of an iOS or other Android device. We already established that there is only one set of devices that is good for security, and the vast majority of people, including you it seems, do not have them. It's not my problem to fix their security. I don't buy them myself.

> I have a Mac Mini from 2006 running Windows 7 that is still getting security > updates and a Dell

In exactly the same way, updates work fine for those of us on properly updated Android devices, and Windows updates don't work for people with hardware that has poorly supported drivers. You didn't address my point. Also, you still haven't addressed why this matters.

> Linux is free open source software that anyone can use, no one pays Linus > for using it, and Linus doesn't have much of any criteria about how it's > used.

So exactly the same as Android.

> There is no five year old iPhone that isn't supported and receiving security > patches.

And all of them have poorly updated userspace. There is no five year old Android phone that has poorly updated userspace. All of those are insecure except for the subset of Android devices that have properly updated base system.

<comment><USER41> _We already discussed this. iOS has a huge attack surface that can only be patched via system updates, which is horribly bad design and terrible for security._

And your theory isn't supported by facts on the ground - we have statistics about the percentage of iOS devices running the latest version of iOS versus the number of Android devices.

Since iOS annoying asks you to upgrade when there is one available and you are given a choice to automatically update when you're not using, do you have a reliable citation showing the number of iOS devices without the latest version compared to the number of Android devices? Or do you just have a hunch?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Would be nice if Google finally came out with their own iMessage-like service that texted over the Internet instead of 30 year old SMS

</comment><comment><USER44> The recent barrage of security bugs in iOS makes me wonder if Apple has been more lenient on their security posture in recent times.

It also shows that Google Project Zero is very successful in marketing their work. There are several other players reporting security bugs in iOS regularly, I see Tencent KeenLab, Pangu, Checkpoint, GaTech SSLab in the last two releases to name a few, but very few have achieved similar recognition as GPZ.

<comment><USER45> I think it's clear that Apple security hasn't been as good as everyone would like. Remember the disastrous Mac OS login bug?

</comment></comment><comment><USER46> A fish, a barrel, and a smoking gun.

<comment><USER19> You are getting downvoted because the kids don't get the reference.

<comment><USER47> No. You're both being downvoted because it didn't really add anything to the conversation. It was just filler.

</comment></comment></comment><comment><USER48> Hard to tell what's really going on here from this article. Although it seems like five vulnerabilities were fixed and one remains (and google is being unusually patient about the sixth issue)

One thing I've always struggled with is the strategy of these white hat teams. I'm sure Google Zero spends a lot of time on Apple because Apple is an enormous company, large partner, and competitor in some spaces.

So now I wonder: does the release of vulnerabilities ever get effected by business agenda?

I assume it has to, although I'm not sure of the agenda here. In this case, iMessage is in direct competition with a Google sms protocol (although googles hasn't gained much traction). Maybe the vuln is less impressive than saying, "there's one more"?

<comment><USER49> Project Zero, as evident from their bug tracker¹, is a Chrome security effort. It looks at everything in the browsing stack — Chrome, libraries, plugins, OS, processors, proxies — presumably because security can be broken anywhere in the chain.

¹ [https://bugs.chromium.org/p/project- zero/issues/list?can=1](https://bugs.chromium.org/p/project- zero/issues/list?can=1)

<comment><USER50> How did you make the little '1' ?

^1

<comment><USER51> The wonders of Unicode: "Superscript One" has codepoint U+00B9.

<comment><USER50> But in the hn reply box, how do you type it?

</comment></comment></comment></comment></comment><comment><USER52> Project Zero Works for the manufacturer of the largest data exfiltration vector in human history and don't seem to be making meaningful progress on fixing that.

All their bug reports come with a bad taste in my mouth.

<comment><USER53> I'm a citizen of a country that is likely responsible for more preventable deaths than any other.

Guilt by association is in fact not completely unjustifiable. But either it attenuates quickly, or every human you know must be shunned for ethical reasons.

<comment><USER52> I'm not judging the people that like finding exploits for a living, I'm judging google employing them while the rest of googles business model is directly opposed to user security.

<comment><USER54> You're upset that a deep-pocketed company is funding security research?

I have no love for Google but I'm extremely happy they found vulnerabilities that could be patched on my phone before someone else did.

</comment></comment></comment></comment><comment><USER55> Project Zero has always been disguised marketing, and IMHO an extremely nasty form of it. I have no doubt they plan coordinated releases like this on a regular basis

(these downvotes are confusing. Do you disagree that it is marketing? That their approach is brutal? That they plan this regularly?)

<comment><USER56> Giving a company 90 days to fix a problem that may be currently exploited, harming end users, seems nasty to you?

We should all be so lucky as to have Project Zero handing us free bug reports like that. Responsible companies PAY for bug reports on their products. Google is handing them over for free.

<comment><USER57> Sure, but at the same time, when Google announced that Google+ had a huge security breach of 52M accounts, they didn't publicly disclose it until well after the fact because they didn't think it was serious enough. I wish Google would follow their own principles.

<comment><USER8> By that standard, literally no company in the industry is following these principles, because internal findings are not routinely disclosed. Internal vulnerability researchers have access to information outsiders don't, so you can imagine, the bugs you're not hearing about are pretty lurid. Every major tech company in North America spends millions annually on third-party software security tests; did you think these just weren't turning things up? What did you think was happening to the reports?

<comment><USER58> For what it's worth, Mozilla routinely discloses internal findings, subject to the same policy as external findings: the bug report is opened up once the fix has shipped to a sufficient fraction of users.

So it's not "literally no company". ;)

Disclosure: I work for Mozilla and I have reported a number of security bugs on our code, the vast majority of which are now public.

<comment><USER8> Mozilla certainly discloses _more_ than other vendors do, but I'm talking to Mozilla security team members about this now, and maybe one of them can jump in here and correct me, but I don't think they can claim that _all_ their internal findings are reliably (and meaningfully, in advisory form) disclosed.

Regardless: that's a good point. I should have said, public disclosure of internal findings is not _an industry norm_. Mozilla is a good counterexample to the argument that _everyone_ close-holds internal findings.

<comment><USER58> That's a good point about advisories. All the findings are public eventually in the form of non-hidden bug reports, but not all may have advisories issued. Doubly so if the finding happens before the affected code had first shipped in a release (so buggy code gets checked in, then internal testing finds a security bug in it before it ships, and that bug is fixed).</comment></comment></comment></comment></comment></comment></comment>


Show HN: Mapflare – Map-based news aggregator - <AUTHOR> https://mapflare.com <comment><AUTHOR> The goal is to show news headlines at their respective location on the map. At the beginning only the most important headlines are shown. You can zoom in to a specific region of your interest to show additional news concerning that region.

Click on a location name to open a list with additional news from that location.

The geotagging of news articles is done with a software developed by myself, the language models still have a lot room for optimization. Therefore errors can sometimes occur and are never the fault of the source.

I appreciate any feedback, wether on design, usability or feature suggestions</comment>


Microsoft doesn't trust us? - <AUTHOR>

This is not a trolling/vote post, just really annoyed at Microsoft! Do we really need a credit card for the trial sign up?
It says proof of identity, why do websites like Heroku offer email id checks instead?
https://www.windowsazure.com/en-us/pricing/calculator/ <comment><AUTHOR> They also take the phone number from a user to register on azure.</comment>


Ask HN: Python vs. JavaScript - <AUTHOR>

What are your thoughts about both the languages and which would you prefer to work in. Please refer to only the language and not the frameworks that make it viable option. <comment><USER2> It depends on what you want to do.

I work with Nodejs everyday, JavaScript is a very cool language but I still prefer Python which is easier to read from my point of view.

</comment><comment><USER3> Python on the back, JavaScript on the front.

<comment><AUTHOR> But if u could program the front and the back in a single language which would u prefer

<comment><USER2> Python is not supported for front-end (yet??). So the choice is quite easy. If you want to stick a single language for both front and backend, using JS is the best solution.

<comment><AUTHOR> I am just asking a hypothetical question, what if you could do everything in python and every thing in js. Would you still use js cause you like the language or use python.

</comment></comment></comment></comment><comment><USER4> Always JAVASCRIPT!

</comment><comment><USER5> Always PYTHON!

<comment><USER6> FTW!</comment></comment>


Search leakage is not FUD. Google et al., please fix it. - <AUTHOR> http://www.gabrielweinberg.com/blog/2011/01/search-leakage-is-not-fud-google-et-al-please-fix-it.html <comment><USER2> (I'm in all-day training today, so I can't participate on this thread much. Also, this is all my personal opinion.)

While Gabe's most recent post was a well-worded statement of his position, my guess is that Google's response was based on the billboard, which says "Google tracks you. We don't." On the website the billboard points to, Google employees are portrayed wearing ski masks and trying to spy on you. That does strike me as trying to a encourage a bit of fear?

This is a browser issue that's not specific to Google or even to search engines, but Google is the only company mentioned on donttrack.us until you get to the "more tools" section at the very bottom. Meanwhile, Google is the first (and only) large search engine to offer https to the best of my knowledge. It's a one-character addition to <http://www.google.com> for anyone that feels strongly about this topic.

<comment><USER3> Keep fighting the good fight. I've been annoyed by this DDG campaign since they debuted donttrack.us. Google never took the low road in order to gain market share and I don't see why DDG feels the need to spread FUD. Gabriel is incredibly fortunate to have received a warm welcoming and avid following from the developer community, but he is squandering that good fortune by engaging in what is essentially a smear campaign that many of us see right through. He should stick to what makes people want to use a search engine in the first place: Outstanding search results.

<comment><USER4> Uh, Gabriel made a point by point analysis of the issue, and your response is "fud" and "many of us see right through"? Can you please stick to responding to the issue and not engaging in your own contentless smear?

<comment><USER5> Gabriel has been avoiding the 2 most important points though.

1\. Most of this is theoretical

2\. Theoretically advertisers can build profiles of you based on the web pages you visit anyway. Referer leakage or not

<comment><USER6> The only part that's theoretical is the extent we're being tracked online but there's plenty to suggest it's "as much as possible".

\- Google's targets ads based on your browsing history - that could include Search, Analytics, AdSense, DoubleClick, and a whole ton of other data they have and collect. [1]

Rapleaf tracks so much that it's actually "a challenge" not to identify people. [2]

QuantCast settled for $2.4 million for making sure their precious tracking cookies were recreated if you delete them. [3]

Facebook just tried to give apps your fricking phone number and address. [4]

Google and their referral leaking is not really "the bad guy" in all of this - there's no bad guy, just a bunch of companies consuming and analyzing as much data as they can get their hands on.

It's not evil, but is it _necessary_?

[1] [http://googleblog.blogspot.com/2009/03/making-ads-more- inter...](http://googleblog.blogspot.com/2009/03/making-ads-more- interesting.html)

[2] <http://blog.rapleaf.com/dev/2010/07/20/anonymouse/>

[3] [http://www.wired.com/epicenter/2010/12/zombie-cookie- settlem...](http://www.wired.com/epicenter/2010/12/zombie-cookie-settlement/)

[4] [http://technolog.msnbc.msn.com/_news/2011/01/18/5868697-face...](http://technolog.msnbc.msn.com/_news/2011/01/18/5868697-facebook- wont-share-phone-numbers-addresses-for-now)

<comment><USER7> _It's not evil, but is it necessary?_

Gathering all this data is necessary and essential for any company who's primary product is their users personal information. (see: Google, Facebook, et al..)

And, corporations being what they are, people within that corporation will optimize to try and make as much money as possible off of that information, because it is in the corporations best interest.

<comment><USER6> "More money" for _them_ doesn't make it necessary for any of _us_.

<comment><USER3> It does if you feel like using their services for _free_. Otherwise, feel free to opt-out entirely by not using their resources.

<comment><USER6> You don't need to use Google services to be profiled - their ads and analytics are virtually everywhere.

<comment><USER3> If you don't use any of Google's services which tie an account to you then they aren't tracking you. They are tracking a browser session and once that cookie expires the trail stops. Even if the cookie never expires, Google doesn't know who you are.

<comment><USER6> You don't need an account to be tracked efficiently - if that was the case Google would be screwed since most people don't use them beyond search.

<comment><USER3> I'm starting to think we're arguing over something entirely different. Maybe some over-stuffing of phrases. I'm talking about Google knowing that I, James Simmons, uniquely identified individual, am searching for [something undesirable to have others know about]. I don't personally care either way really, because I've given them this information. Are we talking about the same thing or are you just talking about Google knowing from site A to site B that your browser's owner likes Korean pop music and chocolate cake mix?

<comment><USER6> My argument or question is why does Google (and not specifically Google, plenty of others) _need_ to know all of that stuff?

You or the other guy mentioned "to make money" which is imo a really weak defense - we wouldn't accept that from anyone who kills, prostitutes, sells drugs, smuggles immigrants, or even legal-but-tasteless stuff like RIAA lawyer.

The data they gather is probably almost always "I like x music" or other innocuous stuff. But it's not always. What if you're searching about a rash on your junk (Google Search), or clocking up lots of views on bondage stuff on RedTube (Google Analytics), or you were browsing a forum for suicidal people and clicked a link to a site that had AdSense? Or pirating a ton of stuff?

Google and god knows who else has a lot of deeply personal information that "making money" doesn't justify - we say, search and browse _very_ intimate stuff on the web, and we don't even know who it's being shared with.

My stance is most of it is just none of their business, even if they've chosen to _build_ a business around it. Although I'm singling out Google they're just the easiest example.

<comment><USER3> >My argument or question is why does Google (and not specifically Google, plenty of others) need to know all of that stuff?

Alright, but do you assume that they know it is _you_? By name, by your identity? If not then why do you care if they know your user-agent likes bondage? Are you worried about seeing ads for bondage movies while you're not searching for bondage, while perhaps someone is looking over your shoulder?

>we wouldn't accept that from anyone who kills, prostitutes, sells drugs, smuggles immigrants, or even legal-but-tasteless stuff like RIAA lawyer.

I've noticed something about people arguing on your side of the fence. They keep dragging in ridiculous extremes to try and prove their point; Comparing those extremes to Google (or whoever) knowing information about you. Another guy in here was comparing this to being watched in your home with video cameras against your own will.

>Google and god knows who else has a lot of deeply personal information that "making money" doesn't justify

So stop giving it to them. They won't know who is searching this information unless you link your identity to an account and therefore enable them to link it to your human identity. As for whether or not it's justified I think is subjective. It's a moral issue and it's entirely subjective.

>we say, search and browse _very_ intimate stuff on the web, and we don't even know who it's being shared with.

There was a time when you could search and browse anything on the Web without the repercussion of someone else finding out about it. But that era is over. No amount of arguing this fact will bring it back. In the Web of 2011 and beyond if you search for bondage videos and you are logged into your Google account then Google will have a way to map it to you. If you don't log in, don't create an account, then they won't. It's that simple.

In the Web of today, if you search for it, you just have to be aware that people have the technological means to know about it and there is no good reason for them to not want to know about this information. It helps them make the decisions they need to make to generate more money -- the entire purpose of a business. No altruistic causes here.

<comment><USER8> >In the Web of 2011 and beyond if you search for bondage videos and you are logged into your Google account then Google will have a way to map it to you. If you don't log in, don't create an account, then they won't. It's that simple.

No it's not. They're likely going to track IP addresses and make assumptions there. And even if limited IPv4 addresses give some protection for a while, browsers can be fingerprinted.

I'm sorry, but people like you are way too complacent. People like us know a little history. Things can get nasty.

<comment><USER3> >No it's not. They're likely going to track IP addresses and make assumptions there.

So? Unless Google is getting direct data from ISPs and requesting personal information about your identity from them then your IP address is just as useless to them as it is to me for linking your tastes to your human identity. Browser fingerprinting, in the Panopticlick sense, is just as useless to that end. At Google's scale the Panopticlick method doesn't even work because of how many people they come across. Once the number of browsers that match your "fingerprint" is > 1 it becomes useless to them.

>I'm sorry, but people like you are way too complacent.

I'm not complacent, I just know what I'm talking about. Take the tin-foil hat off.

>People like us know a little history. Things can get nasty.

You are so full yourself. You have no idea what you're talking about.

<comment><USER6> [http://online.wsj.com/article/SB1000142405270230441050457556...](http://online.wsj.com/article/SB10001424052702304410504575560243259416072.html)

<comment><USER3> You could at least add some commentary to your comment. I've read that article and I don't see the implications to our discussion here. They linked together all the information that women (and everyone else) put out there for others to scrape. That is not the same as the keyword/referrers/logged into Google argument that we are having.

<comment><USER6> Just thought I'd show you how identifiable you really are, without your knowledge or consent or even knowing who the companies tracking you are.

And it's exactly the same as what we're discussing - Rapleaf was even one of the companies I specifically mentioned earlier. These companies don't look at any single piece of data individually, they collate as much as they can and the result is ... what I linked to.

Referrers and search terms are just two _easily ended_ streams of data.

<comment><USER3> Yes, you are correct. It is very easy to link all this data together to create a profile about a person. They probably have more data about each of us than any of us realizes. I think even I might be surprised by how much a company like Rapleaf has put together about me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> "The only reason I've heard to not prevent search leakage is that marketers use Referrer info to do better search engine optimization (SEO). But the information doesn't have to disappear, just the current mechanism of transferring the information in a personally identifiable way."

I struggle to see how this could work in a way that's a fraction as useful to webmasters as the current system. Sites that sell things like to tie keywords to conversions. They can learn, for example, that keyword X drives sales, but keyword Y doesn't, and assign resources accordingly. Online businesses become more efficient, and searchers get more of what they want. I think it's largely a good thing all round.

My respect goes to DuckDuckGo for coming up with a clever way to differentiate themselves from their competition. However, if the problem is that sites are inadvertently sharing keywords with third-party ad networks, then point the finger at those ad networks, not at Google. Blaming Google makes about as much sense as blaming Firefox, Safari, Internet Explorer and the web in general for sending referrers in the first place.

<comment><USER10> Thank you for pointing this out bromley. I've been reading Gabriel's responses and in no place does he mention that keyword level data is needed for understanding differences in user behavior based on entry keyword. This might not make a difference if you run a content site, but for any type of commerce site, I don't want to know how "Google" does, I want to break it down to the keyword level and better understand where efforts should be focused.

I also don't think that the keywords are shared with 3rd party networks explicitly. I think what's happening instead is that you search for something, you land on a page relevant to that something, and the ad network code is reading the content on the page and assigning a keyword target or theme to your search. For example, you might search for a Ford F-150 and you get to Edmunds and the ads are sold on a "by make/model" basis using ad segmentation so the ad network now can assign your cookie a "Pickup trucks" behavioral tag but it never had to read the referrer header, it was implied.

</comment></comment><comment><USER11> Referrers aren't passed on to all the elements loading on the page. If you click to nytimes.com from a Google search, the referrer is sent once in the HTTP request to nytimes.com and then your browser makes all the other required requests separately once it gets back the HTML page. When the ads are loaded they don't get your Google referrer, they'll either get nothing or a nytimes.com referrer. You can work around this with JS (which is how Google Analytics works), but it's completely unnecessary for the problems Gabe's talking about...

Referrers aren't needed for targeting. On that Gout example, Google knows you researched gout so they can target you with gout ads on sites that run AdSense or DoubleClick (which is a lot of ads). If you visited another site about gout that ran ads from a different network, then they too could target you. The referrer has nothing to do with it, it's what you're requesting.

If you don't want targeted advertisements, it's far more effective to use adblock or modify your /etc/hosts file than it is to use DDG.

<comment><USER12> While it is true that the requests that load the ads don't include the referrer, any Javascript loaded directly into the page _can_ access the referrer (window.location.orgin). A lot of ad networks work this way, meaning they do have access to those search terms.

<comment><USER13> In many cases, ads are loaded in iframes, which hide the referrer from the ad network. It's not in all cases, but most big publishers don't want malformed ad network JavaScript to destroy their entire page, so they wrap ad calls in iframes to protect against that.

</comment></comment></comment><comment><USER6> "It's unfortunate that DuckDuckGo is preying on people's fears and offering incomplete information in order to garner attention," a company spokeswoman said in an e-mailed statement.

It really is impressive that you're on their radar enough to warrant a reaction like that.

<comment><USER5> I fear he's losing his goodwill and credibility by taking this angle of attack though. His whole argument really boils down to the fact that advertisers are retarded, not that privacy is being exposed.

<comment><USER13> Agreed. Especially since most cases similar to his argument are retargeting, not query leakage.

In his example, if the user actually clicked directly from Google to Wikipedia, Google would be the only one who knew about the user's interest in gout. Google isn't in the business of sharing this information (believe me, it wish they were ;).

In most cases that people might assume to be related to this, you search for Timbuk2 bags, click through to their site, then are bombarded with ads all over the internet for Timbuk2 bags. This has nothing to do with search leakage, this is retargeting. Timbuk2 drops advertiser pixels on their site so they can later target those users with advertising.

Most advertisers are stupid. They don't have the fancy tech to handle and parse search terms, target users, and display ads. They're probably using RMX or DoubleClick, where you only have the ability to retarget users that have seen certain pixels. They may be using AdSense or AdWords to target queries, but those are using Google's own data, which has nothing to do with search leakage.

I think DuckDuckGo rocks, but as someone working in the online advertising industry today, this issue seems manufactured for publicity. This information is useful in theory (and I'm sure a small number of companies are using it) but there are much bigger issues that are getting exploited by everyone.

</comment></comment></comment><comment><USER14> Constantly attacking Google over something the vast majority of users don't care about seems like a bad idea.

I was ready to try duckduckgo if it could give me the results I wanted (Despite the hugely irritating UI and infinite scroll).

But the constant attacking Google seems bad business to me. It _IS_ FUD. Google doesn't track you. Your browser sends a referer header, which it has done since the dawn of time. Who cares?

flagged.

I think you're going to lose a lot of goodwill Gabriel.

<comment><USER15> This is my last post on the subject. I felt that my position was being read unfairly, and I wanted to set the record straight. I apologize if it did not come off that way as it was _clearly_ not the intention.

I truly believe this is an unnecessary leaking of personal information. And I address the browser argument directly in the post, as well as the argument that no one cares.

<comment><USER16> Gabriel, there seems to be some confusion here in the thread about "breaking HTTP_REFERRER" or in some way changing the current referrer behavior, which was not how i understood your post.

can you confirm quickly that you are proposing that search engines sanitize/anonymize referrer data, and not that they somehow change the referrer behavior?

<comment><USER15> I guess it depends what you mean by "break." I meant what you just said, i.e. just drop the search terms.

</comment></comment></comment></comment><comment><USER17> If you don't want to wait for other people to fix this, there is a handy Firefox addon called No Referrer. It can block referers selectively, either when you click a link on a certain URL, or when you click a link that points to a certain URL. It uses regular expressions so it should be flexible enough.

It also blocks referers being sent from localhost/local URLs. I would be interested in trying out an option that only allows referers to be send to the same domain or its subdomains. The interesting part is seeing how many things that option would break.

EDIT: Forgot the link.

[https://addons.mozilla.org/en-US/firefox/addon/no- referrer-m...](https://addons.mozilla.org/en-US/firefox/addon/no-referrer- misspelled-referer/)

</comment><comment><USER18> If you care about search leakage, turn the Referer header off in your browser. Problem solved. Why is it any website's job to change the way HTTP is designed to work?

<comment><USER19> Ok. Now how do I turn off the data mining?

<comment><USER11> Don't send requests to domains you believe are mining your data.

<comment><USER20> Or to domains that might log your requests and later be bought out by a company that mines your data.

Or to domains that might log your requests and turn around and sell the info to others.

Or to domains that might log your requests and then be cracked.

Oh wait. That describes half the fucking sites on the web.

</comment></comment></comment></comment><comment><USER21> <https://encrypted.google.com>

SSL pages prevent referer headers from being sent.

Easy.

The country specific pages dont have equivalents, so no encrypted.google.co.uk, but you can get the same effect using the gl parameter in the URL, so the url for a UK search would be:

[https://encrypted.google.com/search?gl=uk&q=foo](https://encrypted.google.com/search?gl=uk&q=foo)

Get your list of valid country codes here: <http://www.google.com/cse/docs/resultsxml.html#countryCodes>

<comment><USER21> Too late to edit but I should point out that this also handily prevents governments or ISPs from viewing your queries, or anyone else for that matter. Except in cases of MITM attacks obviously.

</comment></comment><comment><USER22> Perhaps I'm not thinking malevolently enough, but in what situation would the search terms that I used be enough to invade my privacy? Presumably, the content of the site is related to whatever you searched for (otherwise you wouldn't click on the link).

If you are willing to click the link and go to the site, the site will most likely have some idea of why you are there, and what you are interested in, regardless of the referrer headers (because, you know, the site is hosting the content that you are reading).

It seems that if I am willing to visit the site at all, I should also be willing to disclose trivial information like this. So I'm not sure why I should care.

Saying that this is not disclosed also seems a little disingenuous. Referrer headers are pretty standard. If you have a problem with Google doing this, you also have a problem with pretty much every other site that uses hyper-links. It seems that there is a lot of useful semantic information that could be gathered by being able to identify which documents reference your document. Eliminating referrer headers seems like it would be a net loss (pun not intended).

<comment><USER16> yep, you're not being malicious enough :)

the issue is not whether the destination site receives the search terms (and indeed, Gabriel suggests that they should continue to do so, either through the GWT, or some other method).

the issues is that currently, any advertising networks in use by the destination site also receive the search terms, via the same mechanism: the referrer. that's the crux of the issue.

while the destination site can't follow your traffic once you leave it, the ad networks, because of their large user base, frequently can. they can begin to build a much more thorough profile of who you are and what you are searching for than anyone single destination site could. whether that's an invasion of privacy is your call, but to many people it is. currently, they're simply unaware that it's happening.

<comment><USER22> Thanks for explaining, I can now see how this might be a problem.

Through this same mechanism wouldn't the advertising networks be privy to the content of the sites that I am visiting? It seems that even if we eliminate this, we still have issues with advertisers being able to track and create a profile based on the content of the websites you are visiting.

The headers do seem to create a direct link between a given search and a set of visited sites, but can't things like cookies and tracking pixels be used to the same effect? Possibly then using NLP to figure out the most important words on the page? Or the SEO terms that the website uses to get picked up by the search engine?

If you are going to let an advertiser post content on your site, it seems to me that it would be very difficult to keep said advertiser from tracking your users.

If the user uses Adblocking software or otherwise blocks the advertisers' sub- domains, does the advertiser still receive the referral headers?

<comment><USER16> yes, that's right: this is just one arrow out of the quiver. sanitizing the search terms out of the referrer does not fix the full problem.

whether the advertisers are receiving the headers are not depends on how the ads are served. to my knowledge, most of the time, they're not receiving the header directly, they're using JS to access the referrer indirectly (it is exposed via the document object). some adblockers merely hide the ads, which would still allow the advertiser to access the referrer. others prevent the ads from loading which i _believe_ would prevent any access.

</comment></comment></comment></comment><comment><USER23> In Gabriel's defense, I'd say there's something very antithetical between FUD and a detailed description on how to fix the (alleged) problem. I don't know of any other FUD campaign in which a simple solution was provided -- one which won't directly benefit the entity raising the objection. It's Google, et al.'s decision which way they want to go -- whether they take his advice or ignore it.

But one could excuse the billboard potentially to a person trying to highlight that this is a big issue. But again, this seems quite different from an incumbent that is trying to cast doubt via obfuscation, which has usually been the case in FUD...

<comment><USER24> I see the billboard as nothing more than a prank that is now pulled out to beat down the discussion about the actual subject matter.

</comment></comment><comment><USER25> Also posted on site:

I agree that the amount of information a well-tagged website can collect on users is frightening, but I don't think that stripping search keyword data from the referrer is the solution. I think Gabriel is going after the wrong thing.

Here's why: A good Search Engine will never send a user to a page that isn't textually relevant to the search they entered. In 99.9% of cases, the text they entered is ON the page they hit. So if a user searches for: [SOMETHING CREEPY] they will be hitting a page that already has [SOMETHING CREEPY] published.

To put it another way: "Your Keyword data is never going to give a website something it didn't already have. It's just going to reveal what pieces of its content are of interest to you."

<comment><USER26> It's more complicated than that. See the part of the article about ad networks.

On the other hand, I think the gout example was google ads, not an ad network on wikipedia, so hiding referrer info wouldn't have helped.

<comment><USER25> agreed. I guess I left out my suggestion for what the problem really is:

If you are concerned about Ad Networks having so much data on you, clear your cookies and block cookies from them. Then they will never be able to string together more than one piece of data.

<comment><USER27> You're only bumping the problem from a per-browser (cookie) aggregation to per a machine or household (IP address) aggregation.

</comment></comment></comment></comment><comment><USER28> The author is singling out out one company and saying they should be doing things differently than the rest of the web, because of what 3rd parties can do as a result. Why not go after the advertisers if they are the real miscreants? FUD!

There is absolutely no reason that Google should break the web to pacify this guy.

<comment><USER20> Taking his suggestions would no more "break the web" than Craigslist broke paper. It would harm a common business model, sure, but I have yet to see a good reason for me to care about the business models of web companies any more than I care about the business models of newspapers or record companies.

</comment></comment><comment><USER29> While I appreciate that DDG would want to differentiate itself from its competition, if the actual goal is improving user privacy on the internet I don't understand why this is being treated as a Google issue rather than a browser one. Google is an important site, but just one site of many. Wouldn't it make more sense to try to convince browser makers to have HTTP_REFERER turned off by default, either in entirety or for cross-site purposes?

It also seems worth noting that if for some reason you wish to continue using Google instead of DDG, and if you are concerned about the potential privacy issues, you can already change your browser not to send the referer header:

<http://kb.mozillazine.org/Network.http.sendRefererHeader>

[https://chrome.google.com/extensions/detail/dkpkjedlegmelkog...](https://chrome.google.com/extensions/detail/dkpkjedlegmelkogpgamcaemgbanohip)

<comment><USER30> Not sending the Referer header at all can break some sites, probably more than is acceptable to do by default. But stripping the query part of the Referer header might be reasonable. Probably the main side effect of that would be to make Google mad. (P.S. the header is called "Referer", not "HTTP_REFERER").

<comment><USER29> Which sites would break, and why? (genuine question, not contrariness) I've always assumed that cross-site Referer is sufficiently brittle that one cannot depend on it, since it's isn't there if one enters a URL by hand or arrives via a redirect. And while I like it for use within a site, it seems that Cookies have taken over for most uses.

Sorry about the sloppiness with HTTP_REFERER vs Referer. You are correct --- I tend to think of it from the CGI point of view rather than browser. Browser sends Referer as an HTTP header, which web servers commonly set in the environment as HTTP_REFERER. Thus the question should be "Why not have browsers default to not sending the HTTP Referer header?"

</comment></comment></comment><comment><USER31> Even if search engines stop sending keywords in referral data, the ad networks and webmasters will still be able to piece together your browsing history. Every day there is less and less anonymity on the web, and for the most part people are ok with it. Ten years ago very few people would willingly use their real name online. Facebook changed that.

The web as we know it has been built on the assumption that search engines pass along keywords in referrer data. Changing this would have a significant negative impact on a lot of businesses. Considering that most users don't really seem to care about privacy, at least if you judge by actions and not what they say, I don't see why a company like Google would ever stop sending along keyword data to webmasters. They'll piss off webmasters who buy ads from them, and it won't help them increase their share of the search market.

</comment><comment><USER32> I use DDG as my primary search engine and plan to continue, but I am really getting tired of this aggresive/attacking marketing approach of gaberial.

</comment><comment><USER33> There aren't enough people at the FTC to read the complaints that would flood in if Google changed this and Google Analytics became the only tracking platform that could do SEO keyword analysis.

<comment><USER24> I don't see any reason why analytics should have access to that information when other tracking platforms would not.

Chinese walls should take care of that.

And if those are not in place then google has bigger problems.

</comment></comment><comment><USER34> I don't feel qualified to say whether this is FUD or not, but it certainly imposed some fear on me. I don't know what a Gout is and now I'm afraid to search for it.

<comment><USER33> The gout example in the article strikes me as very odd, since the only site that should've received the referrer with the search terms was wikipedia. Therefore we've left to conclude that either Google is targeting ads in their AdSense network based on search terms (which is outside the scope of Gabriel's argument) or Wikipedia is passing search terms to ad networks that for some reason it doesn't display ads from.

Equally likely is that this concerned user clicked on a different health- related site with an ad network that classified him according to that site's content or stated category -- there's simply no evidence that the aggregation of search terms happened.

Note: I'm not saying the story couldn't be true, just pointing out that no technical evidence has been presented to rule out the other possibilities.

</comment></comment><comment><USER35> I'm using Firefox add-on RefControl, which can remove referrer for 3rd party requests

</comment><comment><USER36> Anybody paying attention to <http://www.techmeme.com/110124/p25#a110124p25> ?</comment>


GoDaddy CSRF Vulnerability Allows Domain Takeover - <AUTHOR> http://breakingbits.net/2015/01/18/taking-over-godaddy-accounts-using-csrf/

<comment><USER2> Good find and nice writeup, but this disclosure timeline is pretty harsh!

 _> 01/17/15 [Saturday] Initial discovery and attempt to reach GoDaddy security.

> 01/18/15 [Sunday] Further attempts to reach GoDaddy security, finally > received word there was no timeline for a fix._

That GoDaddy acknowledged the issue after only a day (over a weekend, no less) is impressive. Surely they deserve another few days to figure out a timeline for a fix.

<comment><USER3> > 1/19/15 [Monday] GoDaddy implemented CSRF protection for sensitive account > actions.

</comment></comment><comment><USER4> Reddit discussion: [https://www.reddit.com/r/netsec/comments/2sz6n0/godaddy_csrf...](https://www.reddit.com/r/netsec/comments/2sz6n0/godaddy_csrf_vulnerability_allows_domain_takeover/)

</comment><comment><USER5> I wonder if this vulnerability is in some way related to the Gigya.com domain takeover by the SEA happened in November.</comment>


The good, the bad and the ugly of machine translation for customer service - <AUTHOR> https://unbabel.com/blog/machine-translation-customer-service/ <comment><USER2> How long until this article is outdated and Machine Translation can get the meaning, context, peculiarities, tone of voice, irony, etc.. ?

5 years? 10 years? Never?

<comment><USER3> Never say never.</comment></comment>


Iconic photo of MSFT founders.. recreated 30 years later - <AUTHOR> http://www.microsoft.com/presspass/features/2008/jun08/06-25iconic.mspx?rss_fdn=Top%20Stories

<comment><USER2> Dang, I knew I should have take up Bob Greenberg (old college buddy) on his invitation to join MS back then... ;-)</comment>


Ask HN: Mobile dev - Bypass apps and go straight to HTML5? - <AUTHOR>

Assuming a mobile service needs to be launched in 6 months time, does it make sense to go straight to HTML5? Will the market be ready?
The recent release of the first version of JQuery mobile looks promising, for example.
There is a huge temptation to bypass native apps altogether (even with tools like PhoneGap). Not only does one avoid the app approval process, but, just like having to download plugins causes friction for desktop websites, giving users the opportunity  to directly interact with a mobile-specific site as if it were a native app sounds like a big win all round. <comment><USER3> The App Store / Marketplace is a very important distribution channel, which I wouldn't be so quick to dismiss.

Downloading an app in today's modern phone is almost as frictionless as entering a website.

<comment><USER4> For the average developer, using the App Store as a distribution channel is like playing Russian Roulette with your resources. If you don't have considerable marketing money to ensure your app makes it to the top of the iTunes category, your app will simply be buried beneath the horrible user interface of the App Store. It's a little better as far as Android is concerned but not much.

An app store is great for consumers, it sucks for developers. Especially the iOS AppStore where people spend huge amounts of time and money for an app that has a good chance of being rejected for any number of arbitrary reasons. And vendors like Apple go to great lengths to make extra sure your app code is not portable to other platforms, so it's not like you can share significant amounts of code between, say, Android, Windows, and iOS apps.

Enter HTML (5) mobile apps, which work basically the same across all platforms. Sure, you have to make adjustments for different capabilities, but that will even out over the next few years. Basically HTML 5 finally fulfills the promise of Java after all these years. Of course, there are a lot of apps that simply cannot be built with HTML yet, especially games...

<comment><USER5> App store is a great _distribution_ , not _marketing_ mechanism. You still have to do your own marketing. It's just very easy for people to buy an app by tapping a button. And it's the default. Many people would be suspicious of apps trying to charge them in Safari.

Of course, if you have a non-mobile web app and are offering a mobile companion, web version it's fine, but if you're building a standalone iDevice app that you want to charge for, AppStore is the only viable option.

</comment></comment></comment><comment><USER6> Here is an example of where exactly what you are asking has been done to good effect.

By inserting a line of code in your normal website, we detect which device you are on and redirect you to a HTML5 + Jqtouch version of the site which acts and looks a lot like a native app (especially on the iphone)

See <http://www.pocketdiner.co.uk>

We've had no problems so far so the answer to your question is yes - HTML5 is mature enough for mobile devices from our experience.

<comment><USER7> This is a perfect example why web apps are still nowhere near native apps. For example (testing with a HTC Desire):

\- The transitions are very slow and response times are too big.

\- Pinch zooming a picture results in corrupting the design - <USER2> buttons and labels and so on...

\- You cannot use the Menu button

\- You need a constant Internet connection to be able to work with the application

\- The address bar shows all the time and takes a lot of place on the screen

<comment><USER8> HTML5 has offline cache.

WebKit has CSS has transitions, which are hardware-accelerated (at least on iPhone).

WebKit has <meta name=viewport> hack (hopefully standardized as @viewport) and touch events can be used to control zooming.

In iOS pages bookmarked on home screen are allowed to hide addressbar completely.

</comment></comment></comment><comment><USER9> I guess it depends on the app, but be warned that performance of HTML5 on mobile devices such as the iPad is orders of magnitude worse than in native apps.

So even something straightforward like, say, smoothly animating a pinch zoom on an image, is just shy of impossible on a mobile browser. Add any complexity to your scene, then try to animate it and you'll quickly start reconsidering building a native app.

Sound is another non-starter in an HTML5 app. iPhone (& iPod touch) will only play audio fullscreen. iPad's Safari will play one audio clip at a time, but only as a direct result of a user action. Video is also out, since Apple devices will only play it fullscreen.

Depending on what you're building, you might not need any form of animation or sound. But if you do, now is not the time to make the move to HTML5 if you want your thing to work on mobile devices.

<comment><USER10> It's not that slow. I know this because I've done it. You just need to use the HW accelerated transforms/animations. They're pretty easy to use, and documented. There are some undocumented css things which cause slow downs though.

Animation is as fast as lightning, with expert timing. In fact it's a little bit frighting what you can do with it. If you use js setTimer based animation it's not that great though. You need to use the css animation stuff really.

Audio can be played with no user action - again I know this from direct experience.

Only the small devices play video full screen (currently... I can't comment on upcoming IOS releases ;). The ipad can play them without going fullscreen.

You can't just use links, with click events. Understanding how touch input works with multiple fingers moving on the screen, not waiting for releases is different than understanding interfaces with a big screen and one accurate mouse pointer.

Expect to pay top £/$ for good iOS html5/css/js/svg/canvas developers that also have experience on iOS/android/nokia/palm... if you can find them.

<comment><USER11> Any idea where the market is for such developers? I intent to go the HTML app route, but I worry a little that I won't be able to get contracts for creating apps because I lack experience with the native side.

</comment></comment></comment><comment><USER12> For my upcoming game/app (threewiki.com) I actually built all three versions : )

First the complete, native iPhone version, then realizing that parsing HTML and storing with Cocoa is a pain. (Core Data is pretty good but too bureaucratic for simple things).

So in my second version, I moved all the data logics to an App Engine server, and just leave the app with a thin UIWebView layer in most cases, and only stores the user token on the phone. Mobile Webkit is pretty accurate but I didn't like how the animation turns out, just doesn't "feel" right. Besides, scrolling is much slower in UIWebView than the native UITableView, and you cannot change the tap-link style in UIWebView except a simple color overlay.

Then comes my final version, in which I use UIWebView for static content, and use UITableView & custom views/animation when there's interaction, and all model logics and data processing done on the server.

The app feels super smooth now. And it would be super easy to update because pretty much all the logics in on the server, so app is essentially a pretty "portal". Take a look of the video if you are interested threewiki.com

</comment><comment><USER13> Why not both? I'm sure it's similarly easy in PhoneGap, but here's how easy it is to package a 1 page HTML5 app in Appcelerator Titanium for submission to App Store or Android Market:

wv = Ti.UI.createWebView({url:index.html}); win = Ti.UI.createWindow(); win.add(wv); win.open();

</comment><comment><USER14> I'd say - build an HTML5 app, but add native wrappers (just Webkit) so you can push it to App Store or Android Store. That's what I'm doing now (after a couple of native apps).

on iPhone webapps are still not as good as native ones - you can't put them on App Store (a large audience) and they don't handle multitasking well.

Assuming your app can be done in HTML5.. if it's a game or it requires a lot of integration with platform then native is the way to go (duh)

<comment><AUTHOR> Sure, cycle intensive use cases will probably use native code for a long time to come.

The idea of adding native wrappers around a pure HTML/JS implementation sounds very interesting - like having your cake and eating it....

</comment></comment><comment><USER15> Mobile Web Applications require an extra bit of awareness and effort from users on the platforms that have browsers good enough to utilize them. I haven't personally seen great adoption rates for them, but they do afford benefits development wise, especially if your goal is to create and launch a cross-platform application quickly. It's certainly a possibility that mobile web applications may get more user awareness with better discovery tools, but the general momentum of user interest has really centered on native applications. Mostly because users, that I have experience with, find using native applications a better experience to web applications, but also because the ecosystem around them has matured quite a bit to make finding and acquiring them so much easier.

There are a number of native applications that simply serve up mobile web applications and that grants them several of the advantages of native applications, though not all, from a discovery, capability and usability perspective. Users typically notice that their experience is sub-par compared to truly native applications, but good ones can get close enough that it doesn't make a huge impact compared to the benefits. You will of course still have to deal with app store/market place submission, but you could always launch the application as a web app until the native version is available, allowing you to even provide the native versions after your intended launch date. Generally speaking it affords you a lot of flexibility for your effort, but I would caution that HTML5 based applications really only work for focused tasks that do not need to rely on native features the varying phones provide.

The questions you really need to ask to make a solid decision on which path to take are, how many platforms are you really targeting and do they all need to be supported immediately? Are there any native features of the phones you're targeting that need/should to be leveraged to make your application useful and successful in accomplishing its primary task? How much effort are you willing to put into supporting and maintaining the application(s)? If all your answers lead to having to support a lot for a little and your application is simple enough to not need native features then an HTML5 implementation would probably make the most sense.

<comment><AUTHOR> Excellent comment, thanks. We would require location and touch functionality. The core use case is really quite simple: users provide both text and numerical feedback based on their location - that's basically it. Nothing fancy. It needs to quick and easy to use, work on as many platforms as possible, and - given the nature of the application - is unlikely to be downloaded prior to when it's needed. People are more likely to use it "on impulse" and that's another reason we like the idea of accessing the service as you would a web site.

</comment></comment><comment><USER16> It depends a lot on the use case of your application. The size of the task, the amount of return use, etc. For one-off, low usage apps a web app can be the better choice.

Also, it depends on how good you want the app to look and behave. With HTML you don't have as much control over how content is loaded, animated, etc. Be prepared to deal with really hard to debug crashes if you're making a heavy app.

Last, but not least, the frameworks: the amount of effort that has been put into the native frameworks makes up for a lot of the (perceived?) ease of using HTML, but having to invent a lot of wheels. But again, it really really really depends on what your app will be doing.

</comment><comment><USER17> Is it possible to wrap a HTML5 site into an application? I mean, to make it appear as an app on the phone, even in the app store, but it's just using the browser to connect to the HTML5 site?

<comment><USER11> Yes - that is for example what tools like PhoneGap are helping with.

</comment></comment><comment><USER18> What about monetization? If it's ad-based, alright; however, in many cases the simple payment process offered by iTunes, for instance, is essential.

<comment><AUTHOR> Good point. I should have mentioned monetization is not an issue. In other words, if what we aim to build were in an app store it would be free anyway.

Basically I'm asking whether HTML5 will be mature enough both in terms of functionality and browser market share in around 6 months time.

<comment><USER19> Never mind six months from now - if you're thinking native app, then you've got a particular set of phones in mind. Take a look at the state of the browser on them now.

</comment></comment></comment><comment><USER20> From my tests on the iPhone, Mobile Safari-based web apps do not have responsive interfaces as compared to native ones. Safari adds a delay when you do things like tap link or button - I'm not sure why, it's probably to disambiguate tapping the link with some other action, since Safari can expect the user to be scrolling and zooming as well on top of any interface element.

Because of this, I find UI that mimics native apps in Safari to be a frustrating experience. Everything looks perfectly native, but all the behavior and touch feedback is slightly off.

Until Apple changes Safari or JQuery Mobile figures out how to get more responsive interaction out of it, I think this mimicking the native iPhone UI is missing the point - UI is about much more than visual theme. Stick to non- platform-specific web app design in the meantime (see Google's Mobile Safari- based apps, for instance).

<comment><USER8> Delay can be avoided by using touch events instead of emulated mouse events.

<comment><USER20> Ah nice: onTouchStart, onTouchEnd.

</comment></comment></comment><comment><USER21> I've never, ever seen an HTML5 app that comes even close to being as smooth as a native app. HTML5 is not a comparable option for the foreseeable future.

It's best to build a simple native app for iOS that covers the core of your service, and then an Android app if your audience is particularly likely to have Android phones.

EDIT: Also, the approval process is a non-issue now, it takes a week at most to be approved, and 2-3 days if you email ask them to expedite. The problems with long delays are long over, starting early last year things started improving exponentially.

</comment><comment><USER22> That of course depends on the target audience of the application but in general I would say not quite yet. We have a mobile app we launched recently and we have the benefit of being on-hand when customers use it (at trade shows). There are still a very high percentage of old WinMo and BB phones out there that we had to code for. Now we did make a version of our app in HTML but it is very basic to support the old browsers. I really look forward to the day when we can just do a one for all (or one for 99%) application.

</comment><comment><USER23> Even though the technology behind HTML5 mobile app seems solid, there's still a big hole in the business aspect - no effective way to generate revenue. There's nothing near the App Store in terms of audience reach in the web space.

Put it in more perspective: Look how much iOS developers vs. general web developers are making. And I've also heard an iPhone app has more paid users than a web app (with the similar functionality)'s free users.

</comment><comment><USER24> It depends how technically interesting your app is. If it's just an RSS reader, then HTML5 is probably the way to go.

But you've got the factor in the audience that the App Store gives you. AFAIK there's currently no decent way of discovering mobile web apps (unless you count Google?)

Perhaps PhoneGap is a good compromise, but I've not seen how well it works in practice...

</comment><comment><USER25> From a marketing perspective - I know lots of people and blogs who monitor the app store for new apps and try them out. An HTML5 app means that you will not have access to this crowd.

<comment><USER26> One thing I constantly see in the mobile deployment conversation is a focus on only end-user. There is a huge corporate enterprise market there as well. Since this is where I make my money, my decision tree is a bit different. Corporate clients generally target a more limited number of devices. Also, the app store would not be a likely repository for MIS to deploy from. There is a much bigger market than the end-user only apps that most of these points reference. HTML5 and webkit make good sense on the enterprise Intranet.

</comment></comment><comment><USER27> making web apps as polished as web apps is very hard, however you get a lot of the way there and its 10% of the effort.

You can still do distribution through the appstore with a uiwebview, I am not sure exactly how stringent apple are in this regard.

However its fairly obvious that html(5) is the future of these things, and the turnaround on html applications is far far faster, so yeh I would recommend going html5 until you have strong signals that a native app is needed.

</comment><comment><USER28> Amen.

</comment><comment><USER29> Depends upon what the device market breakdown among your potential customers..

Symbian-everything before ^3 devices not fully html5 WM-everything before WM7 not fully html5 BB-everything past 4.4 is almost full html5 Android- 2.1 and beyond is full html5 iPhone iOS 4 is full html5

I would start examining frameworks such as PhoneGap, QuickConnect, etc to see which covers the best as far as html5.

Of course this depends upon whether you need to access native device features as at the moment the un-spec HTML5 through webkit only has camera, audio, geolocation, sms.

<comment><USER30> How do you call WM7 fully html5?

</comment></comment><comment><USER31> I say build it in HTML5 then ship it with PhoneGap. You'll have the best of both worlds.</comment>