Why does "his.app" cost $499.99 for pre-registration, but "her.app" only costs $249.99? :) Is this some built-in gender bias?
Christ!
Introducing .app, a more secure home for apps on the web
311–320 of 378 posts
Re: Introducing .app, a more secure home for apps on the web
#312Re: Introducing .app, a more secure home for apps on the web
#313Why does "his.app" cost $499.99 for pre-registration, but "her.app" only costs $249.99? :) Is this some built-in gender bias?
It's a bidding war. Someone already bid 249.99 for "his.app". Next step up is 499.99. If you buy her.app for 249.99, then both will cost 499.99.
Re: Introducing .app, a more secure home for apps on the web
#314Earlier quoted context omitted.
Google Reader does not fit the pattern of EEE; if anything, it shows their failure to pursue it. EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system. What they actually did was lose a bunch of people for alternative readers, for Twitter and for Facebook. AMP for email does seem a good example. RCS is not developed by or supported exclusively by Google. They weren't eve…
> EEE with Reader would be to add proprietary extension to feeds and transform it into a closed system Like Google+?
No. The intent might have been to move Reader users to G+, but they did not perform an EEE to accomplish it.
Re: Introducing .app, a more secure home for apps on the web
#315Yeah, the play store of websites. Where we need to get permissions and approvals and can get banned. No thanks, Google is trying to bring their walled garden idea for websites. Don't trust Google on this. They just turned off their service rather than support signal, what if signal was signal.app would they block em? Don't trust Google on this. It's a decent idea but no.
> No thanks, Google is trying to bring their walled garden idea for websites.
It might affect your app's search rank if you don't comply ...
Re: Introducing .app, a more secure home for apps on the web
#316Earlier quoted context omitted.
> Now imagine that that ad had instead said "Go to curb.app to get our app", and that said site had prominent links to mobile app stores. Now imagine it's a year or two from now and you have the exact same problems that you had with curb.com. What's the strategy for when .app gets mined out? Are we just going to keep creating new tlds over and over for eternity? Bear in mind that the only way .app won't get mined out…
> Are we just going to keep creating new tlds over and over for eternity? Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes. In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squa…
Wouldn't it be easier to just raise domain registration /renewal prices, making squatting a poor return on investment?
Re: Introducing .app, a more secure home for apps on the web
#317Earlier quoted context omitted.
And we have the first person to confound not having a .app with not encrypting the connection here. The comment you replied to did not imply that HTTP is not necessarily insecure, it said that you can (quite obviously) use HTTPS with any TLD.
The comment referred to Google flagging other content as insecure; Google does that for HTTP content, not non-.app content. The problem is either the “not necessarily” part is wrong (in regard to flagging HTTP) or the criticism is directed at a fantasy that isn't actually occurring (in regard to flagging things that aren't .app). Either way, the criticism is defective.
Nope:
> Google throws down a few hundred grand to get the .app domain,
> in concert with modifying their web browser
> to deliberately mark others' traffic as "Insecure"
> (it is not necessarily!),
> and reaps the fees now
This is what patrickg_zill's comment said, just with some newlines and emphasis to make it more understandable. The not necessarily does not refer to HTTP, it refers to non-.app domains. And there is no "criticism is directed at a fantasy", there is a cynical prediction which is completely possible in all respects. You---or I---may think that that'll never be the reality, but regardless, that's what the comment said, and the other commenter misunderstood. I don't get why I get downvotes and criticism for this.
Re: Introducing .app, a more secure home for apps on the web
#318Earlier quoted context omitted.
> Are we just going to keep creating new tlds over and over for eternity? Yes. The "easily memorable global namespace" is a limited natural resource, there is no definitive fix and there can't be - unless you accept the totalitarian single gatekeeper scheme Cyde describes. In an open system, you always need to deal with the Sybil attack and the only solution is proof of work, resources - money. This means domain squa…
Wouldn't it be easier to just raise domain registration /renewal prices, making squatting a poor return on investment?
I think that would hurt small businesses more than it would dissuade squatters of truly valuable domains. The trick is to move money from the squatters to the public and domain owners, not to the registry itself, that is basically just another big squatter.
Maybe a TLD like .app could increase the annual renewal fee to something like $100 while bundling premium features like business Gmail, Adwords credits or Google Cloud services, all usable only on that domain name. This way, low level owners get their money back, big corporations don't care and squatters are hurt since they can't make use of the services.
Re: Introducing .app, a more secure home for apps on the web
#319Yeah, the play store of websites. Where we need to get permissions and approvals and can get banned. No thanks, Google is trying to bring their walled garden idea for websites. Don't trust Google on this. They just turned off their service rather than support signal, what if signal was signal.app would they block em? Don't trust Google on this. It's a decent idea but no.
> No thanks, Google is trying to bring their walled garden idea for websites. It might affect your app's search rank if you don't comply ...
I've used DuckDuckGo for months. Only the very most esoteric of terms brings me back to Google, and I can count those times in the past months on one hand.
Re: Introducing .app, a more secure home for apps on the web
#320Earlier quoted context omitted.
> No thanks, Google is trying to bring their walled garden idea for websites. It might affect your app's search rank if you don't comply ...
I've used DuckDuckGo for months. Only the very most esoteric of terms brings me back to Google, and I can count those times in the past months on one hand.
Yes, but good luck convincing the (potential) users of your app :)