Google stelt .app-domein open voor registraties

Google stelt het .app-topleveldomein open voor registraties. Websites die van een .app-domein gebruik willen maken, moeten https gebruiken. Google kreeg het topleveldomein in 2015 in handen door er 25 miljoen dollar voor neer te tellen.

Google wil appontwikkelaars over halen om een .app-domein te registeren. Vanaf dinsdag tot en met 7 mei zijn de domeinen te registeren via een Early Acces-programma, waarbij een meerprijs betaald moet worden. Dat moet kopers de gelegenheid geven om een domeinnaam in handen te krijgen voordat het .app-topleveldomein op 8 mei voor iedereen beschikbaar komt.

De eerste verkoopfase vindt plaats via get.app, een website van Google. Het topleveldomein staat op de HSTS preload list, waardoor https verplicht is voor alle verbindingen naar .app-websites. Google stelt daarmee dat .app-websites veilig zijn voor gebruikers.

In 2015 werd bekend dat Google het .app-topleveldomein in handen kreeg. De zoekgigant betaalde daar 25 miljoen dollar voor, op dit moment omgerekend zo'n 21 miljoen euro. Google heeft tal van andere tld's in handen, zoals .google, .gmail, .docs, .drive en .android. Domeinen hierbinnen zijn niet publiek beschikbaar.

Reacties (63)

[Vinnie2k]

Ik snap dat dit soort tld's door bedrijven en investeerders kan worden gekocht, ik heb begrepen dat hier best veel geld voor word neergelegd. Ik heb ook wel voor dat dit best een return on investment bij intressante tld's een hoop geld oplevert.

Maar worden we met zn alle niet hartstikke URL-moe.. Het is toch bijna niet meer te doen als je een beetje een generieke naam hebt om aan een fatsoenlijke url te komen.. Je hoort/ziet de gekste dingen. De raarste afkortingen en de achterlijkste tld aan elkaar geknoopt tot een niet te onthouden mengelmoes..

Wel vind ik het goed dat https verplicht word, dat zouden ze meer moeten doen. Hier kan in ieder geval van een bepaalde standaard uitgegaan word en ik vind het wel een intressante ontwikkeling.

Is het nou ook zo dat google al het verkeer/statistieken over deze tld kan registreren omdat ze eigenaar zijn? (kan iemand mij dat uitleggen)

[Anoniem: 857639]

Dat niet alleen.. als je een bedrijf hebt dan moet je steeds meer domeinen inkopen zodat oplichters er geen misbruik van maken.

[Vinnie2k]

Dat is ook een beetje waarom ik het schreef.. ik heb wel een aantal projecten waar ik graag sommige tld's aan zou willen hangen.. alleen uitzoeken waar bepaalde aangeboden worden is echt een hel.

[Douweegbertje]

Gewoon bij transip kan je vrijwel alles kopen, er zullen vast meerdere van dat soort aanbieders zijn.
--------------------

Een bedrijf met bijvoorbeeld een merknaam moet zijn merk sowieso beschermen. Het is verder een keuze die je kan maken. Menig bedrijf die een bepaalde bekendheid / omzet heeft zal inderdaad in verhouding wat meer moeten investeren in domeinnamen. Een ZZPer hoeft echt niet alle tld's op te kopen.

Daarbij zijn er gewoon een aantal prominente TLD's; .com, .net en .org. Afhankelijk van waar het bedrijf opereert heb je dan nog de country code TLD's (.nl, .be etc).

Als je gewoon dat stukje hebt zit je eigenlijk veilig en goed. We kunnen nu wel over "de hoeveelheid TLD's" praten maar volgens mij zijn er (en waren er dus al) veel meer country TLD's dan dat er nu generieke TLD's zijn.

Ik heb eerder nog nooit iemand horen zeuren dat ze domein.zw moesten registreren om veilig te zijn. Goh vervelend, dat Zimbabwe zeg.. (ps. tweakers.zw is nog vrij, laten we gaan oplichten! ).

Ik heb zelf meerdere "nieuwe" TLD's met voornamelijk een intern doel. Zo heb ik best leuke naampjes voor onze monitoring tools. Het is makkelijk te onthouden en je hebt een wat ruimere keuze in de naam omdat niet alles gesquat is. Het is een aardige vinger richting bedrijven/mensen die bijvoorbeeld meer dan 10k domeinnamen hebben puur vanwege het feit dat er maar een gelimiteerde keuze was aan TLD's.

Qua chaos; agreed. Je ziet misschien door het bomen het bos niet meer.. echter de tijd dat mensen lukraak "boek.nl" of "tvgids.nl" intypte is ook wel voorbij. Mensen zoeken. Google, whatever. Pas als echt iets bekend is gaan mensen er direct naar toe. Mocht tweakers op tweakers.tech draaien dan weet je dat heus wel na een paar visits

[bertware]

Google kan hier geen statistieken van inzien, behalve wie welke naam koopt. Google bezit de TLD en dus ook de nameservers (servers die onthouden waar de informatie met IP adressen voor website.app, voorbeeld.app, ... staat). Alle informatie moet ooit daar opgehaald worden, maar dit gebeurt via tussenliggende DNS servers (zoals je ISP etc), waar deze data ook nog eens dagenlang gecached kan worden. Google ziet dus niet hoe vaak of door wie een .app domein bezocht wordt.

Zelf ben ik overigens niet 100% voorstander van https verplichting, er zijn goede redenen (caching) om bepaalde API data niet over HTTPS te sturen, dus voor die API heb je dan al zoiezo een andere TLD nodig. Voor websites naar eindgebruikers toe is het dan wel weer een goede zaak, gezien HTTPS ook je privacy vergroot (ISP ziet niet exact welke pagina's je bezoekt)

Edit: nuance: enkel voor specifieke APIs met statische data waarbij absoluut niets afgeleid kan worden uit het verzoek of antwoord, vergelijk het met Wikipedia downloaden van een server die enkel deze ene download aanbiedt. Het server ip verraad al evenveel als het verzoek.

[Reactie gewijzigd door bertware op 23 juli 2024 06:39]

[djiwie]

Google zou via de eigen rootservers voor het .app TLD ook nog informatie kunnen vergaren.

De goede redenen om geen HTTPS te gebruiken worden steeds minder. In een tijd waarin al de helft van het web encrypted is zou ik ook zeker geen nieuw project starten waarbij je API's niet gaat encrypten. De overhead is minimaal. Unencrypted API's in moderne browsers gebruiken levert een mixed content warning op en bijvoorbeeld iOS staat alleen nog maar HTTPS verkeer toe.

Voor welke concrete API's is caching dermate belangrijk dat HTTPS niet zou werken?

[bertware]

Op dit moment onderzoeken we aan de UGent Linked Connections (linkedconnections.org), dit is een lijst van pagina's die voor iedereen identiek zijn, behalve het laden van een bepaalde pagina kan de API niets. Hierbij heeft caching een enorme invloed, en wordt HTTP proxy caching interessant als hiermee data "korter" bij de gebruikers opgeslagen kan worden. Een statisch bestand vertelt praktisch niets over de gebruiker, en al helemaal niet wanneer het gewoon voor analyses gebruikt wordt.

[djiwie]

Interessant project!

Maar als ik je goed begrijp gaat het dus om de HTML pagina die de applicatie host die je niet als HTTPS wilt hosten? Want de API zelf die wordt aangeroepen gaat al over HTTPS (en terecht, want daar zit juist gevoelige data in die je wilt versleutelen).

En dan snap ik dus nog steeds niet helemaal je punt. Waarom is caching daarvoor zo belangrijk (nog even los van het feit dat niemand meer een proxy gebruikt), en maak je je dan niet druk over een MITM? Ik zou me daar wel druk over maken.

Als het server-to-server communicatie is, dan kun je zelf nog kiezen of je SSL verplicht. Maar dan maakt de preloading HTST ook niet echt uit.

[Reactie gewijzigd door djiwie op 23 juli 2024 06:39]

[bertware]

De API zelf kan je zien (in testversie) op https://graph.irail.be/sncb/connections
En dit is net het punt, de data is niet gevoelig: Je krijgt steeds alle vertrekkende treinen voor een bepaalde tijdsperiode, en daar filter je client side een route, station of traject van een voertuig uit. Met andere woorden, niemand weet wat je zoekt.

Maar iedereen kan zien welke pagina's je download? Kan ook met SSL als je gaat fingerprinten op basis van loading times en pagina groottes, gezien het aantal pagina's beperkt is en ze door verschillende inhoud ook licht verschillende groottes hebben.

Het voornaamste gaat erom dat iedereen vrij is om te kiezen hoe hij/zij de data verwerkt en de data zo toegankelijk mogelijk is. Een proxy cache is de eenvoudigste manier om dit systeem te offloaden of versnellen door eender wie wilt, en los van hoe vaak het nog gebruikt wordt, lijkt het me niet zinnig om dit te gaan schrappen en HTTPS te verplichten (waar geen pluspunten tegenover staan in dit geval - er is geen data te beschermen). Cliënts die willen en geen proxy gebruiken gebruiken uiteraard HTTPS (want geen nadeel), zij die een proxy willen gebruiken zouden nadeel ondervinden van HTTPS verplichten en gebruiken dus gewoon HTTP.

Het gaat er vooral om om alles zo open mogelijk te houden, liefst met open standaarden die wijd ondersteund zijn, en niet nodeloos te schrappen "want alles moet over https". Een simpele http proxy is sneller opgezet dan een forward proxy server met self-signed SSL en whatnot. Verder zijn er nog een aantal gevallen waarbij gebruikers automatisch achter een proxy kunnen zitten (bedrijfs- of universiteitsnetwerk). In dit geval heb je automatisch caching, da's gewoon mooi meegenomen.

Ik zie heel goed het privacyprobleem van een bedrijfslogo op een site via HTTP te laden, maar in dit geval is er niets wat HTTPS zou kunnen verbergen (correct me if I'm wrong).

Cliënts kunnen smartphones, browsers, servers, raspberry pi clusters, ... zijn, whatever je kan bedenken.

MITM zie ik in dit geval niet wat er kan misgaan? Foute informatie injecteren oid? dan stuur je de client side algoritmes in de war > geen resultaat > gebruiker zoekt toevlucht tot andere informatiebron. Dan kan je evengoed die SSL verbinding jammen zodat er geen resultaat is. Ik heb zelf eens de hypotetische case uit proberen denken waarbij je iemand op de foute trein probeert te zetten, maar er gebeurt zoveel clientside dat dit niet zou lukken. (client side zal steeds correcte start en eindpunt van route nemen).

HTTPS niet verplichten voor deze API was een bewuste keuze - andere APIs van iRail verplichten HTTPS en dwingen minimum TLS versies af etc, gezien daar gevoelige data verstuurd wordt, maar in dit geval is na een soortgelijke interne discussie besloten dat HTTPS verplichten in dit geval niets toevoegt, en enkel nadelen brengt. Vandaar vind ik ook deze discussies interessant, misschien kan iemand me duidelijk fout tonen (hoe kan jij toch zien wat ik opzoek als je alles inziet, of een attack vector bedenken via MITM). Langs de andere kant hoop ik dat het mensen kan aanzetten om kritisch te blijven denken. HTTPS verplichten is in 99,9% van de gevallen fantastisch, maar in dit geval bijvoorbeeld niet.

[djiwie]

MITM zie ik in dit geval niet wat er kan misgaan? Foute informatie injecteren oid? dan stuur je de client side algoritmes in de war > geen resultaat > gebruiker zoekt toevlucht tot andere informatiebron.

Dat zou niet zo'n ramp zijn, maar het is triviaal om op een HTTP page een script te injecteren wat de events afluistert en die naar een API wegschrijft. En dan kun je redelijk eenvoudig achterhalen welke reis iemand plant.

HTTPS niet verplichten voor deze API was een bewuste keuze - andere APIs van iRail verplichten HTTPS en dwingen minimum TLS versies af etc, gezien daar gevoelige data verstuurd wordt, maar in dit geval is na een soortgelijke interne discussie besloten dat HTTPS verplichten in dit geval niets toevoegt, en enkel nadelen brengt.

Nou ja, via een MITM attack zoals hierboven beschreven, maar ook in een scenario waarbij deze API de informatie op een bepaald gebied gaat filteren (zeg, alle treinen en bussen in de hele Benelux ipv alleen de treinen in België). Gezien de hoeveelheid data wil je dan waarschijnlijk gaan filteren, en dan zie je toch deels welke route iemand aflegt.

Ander scenario, vermoedelijk nu al toe te passen: ik zie dat de API steeds de vervolgconnecties opvraagt aan de hand van de aankomsttijd op een tussenstop. Als je deze tussentijden uitleest en correleert aan mogelijke routes zul je toch redelijk snel een route moeten kunnen reconstrueren die exact matcht met de mogelijke tijden uit de client requests.

Overigens denk ik wel dat je het belang van een proxyserver overschat. Proxies hebben vooral nut in situaties waarbij een grote groep gebruikers achter een langzame uplink zit (traditioneel voorbeeld: Australië, waarbij de proxies bij de ISP stond). De bottleneck zit inmiddels al lang niet meer bij de backbone, en een website die zelf invloed wil hebben op de performance begint zelf met een CDN. Diensten als Cloudflare maken dat erg toegankelijk (zowel qua kosten als qua techniek).

En eens dat kritisch nadenken goed is.

[bertware]

De pagina's liggen vast en voor routeplanning wordt dus over een tijdsbereik alle pagina's opgehaald, dus hier lekt geen info. Html pagina's en dergelijke moeten idd via HTTPS (alles wat mogelijk uitgevoerd wordt). Als de API data in regio's gaat opdelen wordt het inderdaad een ander verhaal. De impact is inderdaad verwaarloosbaar voor eindgebruikers, bij gebruik van veel digital signage binnen een bedrijf zou dit datagebruik ietswat kunnen beperken. Thanks voor de feedback allesinds, cloudflare zou inderdaad nog geen slecht idee zijn hiervoor!

[Ventieldopje]

Caching? Dat wordt gewoon ondersteund over HTTPS hoor

[bertware]

Http proxy caching is niet beschikbaar bij HTTPS, omdat de proxy server de cache headers niet kan inzien en ook geen cliënt kan antwoorden zonder de "echte" server te contacteren gezien de proxy server niet over het certificaat beschikt

[Douweegbertje]

SSL offloading.

Ik vind het echt jammer te lezen dat iemand geen https wilt omdat caching niet werkt. Echt van alles, is dat de meest slechte reden. Ongeacht een website, doel of wat dan ook; ssl zou een default standaard moeten zijn.

[bertware]

HTTPS is uiteraard beschikbaar, maar forceren moet de keus zijn van de gebruiker voor deze API.

Vergelijk t met Wikipedia downloaden van een server die enkel dit aanbiedt: wat verberg je met HTTPS, gezien je server ip toch al zegt dat je Wikipedia wilt downloaden?

Ongeacht een website, doel of wat dan ook; ssl zou een default standaard moeten zijn.

enkel als HTTPS meerwaarde biedt. Waarom zou je een techniek verplichten als deze voor je eigen applicatie enkel minpunten meebrengt?

Ik heb HTTPS aanstaan als default en verplicht voor al mijn APIs, maar bij deze is er gewoon geen enkele meerwaarde.

[Douweegbertje]

De enige minpunten zijn vanuit jouw eigen gebrekkige kennis voortgekomen. Er is misschien een marginaal minpuntje en dat is dat SSL enige vorm van extra load + laad tijd geeft.

Waarom je het aan moet zetten;
- Zelfs een statische pagina of in jouw geval je API kan domweg geïnjecteerd worden. Met ssl is de chain dan verbroken.
- Een API heeft diverse requests, waarom zou bijv een POST request niet over https mogen gaan om mijn gegevens te waarborgen (en privacy).

Enige reden om geen https te nemen is als het een intern afgeschermd netwerk betreft met bijv. servers die onderling met elkaar praten. En zelfs dan doen veel mensen nog een cert, al dan niet self-signed. Just to be safe.

[bertware]

Deze specifieke API heeft geen enkele post request, uiteraard zouden dergelijke requests over een beveiligde verbinding verlopen. 1 get request en that's it.

Injectie heb je misschien een punt. Niets van het API resultaat wordt "uitgevoerd" (jsonp etc), dus je zou een out of memory kunnen genereren op bvb android clients door een extreem lange response te injecteren, of een Bufferoverflow, kan je me praktische voorbeelden geven van hoe bvb de Json parser in android op dergelijke manier aangevallen kan worden? Verder kunnen clients steeds zelf kiezen voor HTTPS (het is beschikbaar, niet verplicht). Zo gebruikt mijn eigen cliënt implementatie HTTPS, maar hoeven anderen dat niet perse

[Douweegbertje]

- Een public access point
- Malware op de pc / telefoon
- Gehackte router
- Een overheidsorganisatie (niet perse die van NL).
- Een tap op een accesspoint

Zolang iemand maar "ergens" tussen kan komen en met het netwerk kan meeluisteren. Vanaf dat moment heeft iemand al je data.

[bertware]

Maar die data is helemaal waardeloos. Die data kunnen ze zelf gewoon ophalen bij de server en hun de moeite sparen. Zelfs met SSL is fingerprinting van de resource mogelijk om daarna te achterhalen exact welke paginas uit de lijst opgehaald zijn. Het concept van de nieuwe API is net om helemaal geen gevoelige data van het toestel af te laten, maar generieke data op te halen waaruit een eigen antwoord gereconstrueerd kan worden. Vergelijk het met heel de google index te downloaden en lokaal te zoeken, er is helemaal niemand, zelfs niet de server, die weet wat je zoekt. Ook al weet je exact wat gedownload is.

Malware heeft de gebruiker een groter probleem, die kan de gevoelige data zelfs met SSL uitlezen (gewoon screenshot zodra deze gevisualiseerd is).

Injectie om vulnerabilities te exploiten lijkt me nog het grootste risico, maar dat loop je met lekke network libraries zoiezo, SSL of nie. Je loopt hoogstens het risico dat een exploit in je JSON library geexploiteerd wordt, en gezien de hoeveelheid JSON die andere apps parsen uit HTTPS APIs waarbij die andere apps de server niet onder controle hebben, lijkt me dat je dan ook weer een veel groter risico hebt bij die andere apps waarbij door een server binnen te dringen onmiddelijk alle gebruikers beïnvloed kunnen worden.

[Douweegbertje]

Je kan er wel over door blijven praten maar je hebt geen goed argument om het niet te doen.

Je hebt een Server X en een Server Y (of client X en server Y, whatever).
De enige garantie dat deze veilig met elkaar kunnen praten is via TLS/SSL.

Al jouw argumenten zijn per definitie niet van toepassing omdat die niet over het kern van het verhaal gaan. Of de data publiekelijk is of zelfs bekend heeft er namelijk helemaal niets mee te maken. Ja, dat er geen gevoelige data "gestolen" kan worden. Dat doet er niets aan toe dat er ergens in het verhaal van een client een zwakheid zit die uitgebuit kan worden.

Anders gezegd, doe jij je huisdeur op slot of niet? Ik kan mij niet anders voorstellen dat jij je auto, je huis en whatever allemaal niet op slot doet. DAT is namelijk precies dezelfde redenatie om geen SSL te nemen.

[holoduke51]

Niet de enige. Oude telefoons met android 4 of eerder hebben in sommige gevallen een SSL handshake bug met native apps. https werkt dan in het geheel niet. Er is omheen te werken met aangepaste libraries (in de android app) maar kost veel tijd en bypassed aantal belangrijke beveiligingsmaatregelen. Wij hebben in een aantal van onze apps daarom voor specifieke android telefoons http geforceerd ipv van https. Erg vervelend, maar niks aan te doen.
Jou argumenten gaan wellicht over de browser http(s) implementaties, maar er is meer dan dat.

[KingFox]

Jawel, het alternatief is heel simpel: geen support meer geven. Soms moet je dwingende keuzes maken om de veiligheid van de gebruikers te waarborgen. Je API laat ergens HTTP toe...

Wij kiezen momenteel nog Android 4.4.2 als basisversie om support te leveren, maar vanaf het moment dat we zulke fratsen ontdekken is het ook gelijk gedaan. Eigenaars van zulke smartphones hebben een tijdbom in handen. Dan is het maar hun eigen verantwoordelijkheid om te upgraden naar een nieuw (veiliger) device ofwel geen gebruik meer maken van de app. Er zit niets anders op.

[SijmenSchoon]

Maar als je de cache-server bezit, kan je hem toch wel van een certificaat voorzien?

[bertware]

De cache server hoeft helemaal niet in ons beheer te zijn, die kan
- in ons beheer zijn voor 3rd parties
- in 3rd party beheer zijn voor die 3rd party
- in 3rd party beheer zijn voor andere 3rd parties.

De eerste 2 gevallen zijn duidelijk, het 3e vormt een probleem. Het IP adres van de server, wat zichtbaar is ondanks HTTPS, verraad evenveel als een API verzoek, gezien die API een lijst van statische data is die elke 30 seconden wordt bijgewerkt, en er helemaal niets uit af te leiden is.

[SijmenSchoon]

Als je een third-party cacher bent van de oorspronkelijke API, heb je neem ik aan ook je eigen (sub)domein, waarvoor je dan je eigen certificaat kan aanvragen.

Ik zie het probleem niet helemaal.

[Ventieldopje]

Dan kan je in de meeste gevallen gewoon de SSL verzorgen op de proxy/load balancer. Het verkeer tussen proxy en backend kun je dan zonder encryptie laten verlopen als dit een veilig (intern) netwerk is of ook gewoon weer opnieuw met SSL doen, desnoods zelfs met self-signed certificaten.

[batjes]

Ik kom ze nooit tegen

Vrijwel alles zit nog achter de gebruikelijke tld's. Al die onzin TLD's zijn net zo'n hypetrain als cryptocoins. Iedereen roept dat het belangrijk is, maar als het er op aan komt, niemand die het daadwerkelijk gebruikt.

Ik zie hier in NL ook vrijwel nooit bedrijven te koop lopen met tld's die niet eindigen op nl, nu, eu, com of net.

De meeste mensen begrijpen het internet enkel als website.com/nl/whatever. In het verleden gewoon veel terugkomende bezoekers gemist of mensen die me niet konden mail, omdat ik op een .org domein zat, uiteindelijk maar naar .eu gegaan, dat volgen mensen nog.

Het security aspect daar gelaten. Door de enorme hoeveelheid van die TLDs ondertussen, zie je door de bomen het bos niet meer en wordt het een onoverzichtelijke puinhoop.

Maar wel dikke cash cow voor de bedrijven achter die TLDs. Want nu worden bedrijven of banken verplicht de .law, .bank en andere onzin op te kopen om eventueel misbruik te voorkomen.

[stane]

Ik ben ook zeker geen fan van meer tld's. Maar Google (en andere zoekmachines op het internet) lachen zich wel kapot. Meer tld's betekent meer onzekerheid en dus moeten consumenten steeds vaker zoeken op zoekmachines naar de juiste website. Hierdoor krijgt Google meer traffic, en dus ook meer inkomsten. Winnaars? De zoekmachines.

Tegelijkertijd is het steeds lastiger om een domeinnaam te vinden als bedrijf (of als consument natuurlijk). [achternaam].nl kun je bijna niet meer vinden. Laat staan .com. Voor nieuwe bedrijven is het wel gunstig. Als je een app ontwikkelt die 'water' heet, dan kun je nu water.app kopen, terwijl water.com gewoon geen optie zou zijn.

[the_stickie]

Is het nou ook zo dat google al het verkeer/statistieken over deze tld kan registreren omdat ze eigenaar zijn? (kan iemand mij dat uitleggen)

Nee dat is niet zo. De tld (top level domain) bevat weliswaar dns records voor de onderliggende domain names (bv voorbeelddomain.app zit op ip 123.123.123.123), maar in de praktijk worden die niet voor elke request geconsulteerd. De dns server(s) waar gebruikers hun verzoeken naartoe sturen zullen het antwoord dat ze respectievelijk van . (het root domain), van app, en van voorbeelddomain krijgen cachen (tijdelijk opslaan). Natuurlijk verloopt die cache wel (de admin van elke dns server kan de maximum cache duur van z'n records instellen: time to live). Maar zelfs met een heel korte ttl (time to live) missen ze sowieso een hoop requests. Daarnaast is de downstream cache juist zeer voordelig om de belasting van de servers onder controle te houden.

Edit: fyi de ttl voor de records op app is blijkbaar 300s voor A/AAAA records en 150s voor hun NS records. Je kan dit zelf verifiëren met nslookup

[Reactie gewijzigd door the_stickie op 23 juli 2024 06:39]

[Rex]

Ik zou echt niet weten waarom iemand 20 EUR/jaar zou neertellen voor zo´n domein.
PayPal.app? Dumpert.app? Nu.app? McDonalds.app? Pathe.app? Yelp.app? Clashofclans.app?

De meeste apps gebruiken al een goedkopere .com/nl extensie, dus waarom zou je uberhaupt zo´n lelijke .app extensie willen hebben? Is er iemand die wel een goed voorbeeld weet (behalve dat een bedrijf het registreert zodat typosquatters het niet afpakken)?

[Reactie gewijzigd door Rex op 23 juli 2024 06:39]

[Vinnie2k]

Het zou wel een goeie zijn om daarmee door te linken naar je app in de playstore.. whats.app bijvoorbeeld.. maar die zal er vast niet meer zijn.. haha

[Rex]

Maar als we typosquatters even vergeten, dan zie ik niet waarom bijv. WhatsApp het domein whats.app als hoofddomein zou willen gebruiken terwijl ze al whatsapp.com hebben. whats.app is misschien wel cool, maar ik denk dat velen non-tweakers juist geen reet zullen begrijpen van al die nieuwe domein extensies. Ik denk juist dat ze zullen denken dat die domeinen fake zijn.

Ik heb zelf een paar .technology, .ltd en .io domeinen en heb nu al heel vaak dat mijn emailadressen nergens geaccepteerd worden omdat de IT'ers geen rekening hebben gehouden met de nieuwe extensies of dat ik meerdere keren moet uitleggen dat er geen .com of .nl achter hoeft, maar dat het eindigt op .technology.

[Vinnie2k]

Waarom zou een .*somethingelse* niet geaccepteerd worden.. voor validatie dat het een emailadres is ofzo.. maar ik denk dat de meeste toch wel een .com ernaast hebben.

Wij hebben er ook een paar lopen van oudere tld's. Ik gebruik expres niet het .com achter mijn mailadres omdat .nl duidelijker is.. maar mail ernaartoe word wel afgevangen.

Maar de wirwar is niet goed voor de OCD'ers onder ons

[Rex]

Ik maak al jarenlang mee dat rare extensies voor problemen zorgen. Zelfs bij grote bedrijven als PayPal: Ik kan bijv. niet bij PayPal's iOS app inloggen met mijn .tech-email. Bij vele sites en diensten (gas/water/licht) kan ik vaak ook niet mijn .tech email gebruiken. Volgens mij luktte het bij mijn ANWB account ook niet.

edit: typo

[Reactie gewijzigd door Rex op 23 juli 2024 06:39]

[iAR]

Omdat ze enkel checken op algemene 2 of 3 letter tld's?
Net zoals je bij enkele sites ook geen gmail + mag gebruiken.

[djiwie]

Ik heb een .ninja domein en geniet iedere keer van de blik van hotelreceptionistes etc. die het willen noteren

[FvdM]

Ik zie het wel voor me dat .app een shortcut wordt om snel de officiële app in een Play of App Store te vinden, zonder dat je helemaal moet gaan zoeken. Je gaat in je browser naar PayPal.app en op basis van je OS krijg je gelijk de juiste intro en installatie button te zien. Vendors kunnen daar ook andere app diensten aan koppelen. Zoals een publieke deeplink `paypal.app/send/naamontvanger/10eur` en de app opent gelijk met een betaalscherm waarop de ontvanger en het bedrag van €10 al zijn ingevuld. Heb je de app nog niet dan krijg je een intro met voorbeelden op basis van de info uit de url. Lijkt mij erg handig.

[holoduke51]

puur SEO/ASO technisch kan het interessant zijn. Zeker als google je daarmee hoger rankt.
Voor mijn voetbal app, is goal.app best leuk om te hebben.

[enver63]

Weet iemand hoeveel een registratie kost? Ik kan dat niet vinden op https://get.app/

Edit: Antwoord gevonden: https://www.101domain.com/app.htm

[Reactie gewijzigd door enver63 op 23 juli 2024 06:39]

[Rex]

Nog niet alle prijzen zijn bekend, maar op dit moment is het tussen de 12-29 USD voor het 1^ste jaar, en daarna 13-29 USD de renewals.
De standaardprijs wordt 19.99 USD/jaar

EDIT: Absurd trouwens om 12000 USD neer te tellen voor een domein met een .app-extensie die niemand kent. Als ik een groot bedrijf was, zou ik gewoon heel die landrush overslaan, en daarna pas registreren. Als het domein dan al weg is, dan kan je altijd nog een "domain dispute case" openen die vele duizenden euros minder kost dan het domein zelf.

[Reactie gewijzigd door Rex op 23 juli 2024 06:39]

[enver63]

Thanks. In de 'landrush' periode is het wat duurder, zie de edit bij mijn vraag.

[faim]

Een drie-letterige .app is 10k als pre-order en 600 euro per jaar.

[P1nGu1n]

Weet iemand toevallig wat een betrouwbare partij is die .app domeinen verkoopt? Bij voorkeur Europees, heb mijn email e.d. liever niet op een server in de VS staan. De meeste namen zeggen me niks, namelijk. Ik zou het voornamelijk willen gebruiken voor email (hosted) en een simpele website.

Volledige lijst: https://www.registry.google/about/register.html

[Reactie gewijzigd door P1nGu1n op 23 juli 2024 06:39]

[jp]

Wat heeft de plek waar je je domeinnaam koopt in vredesnaam te maken met de plek waar je mails uiteindelijk opgeslagen worden?

[PDZ]

Je kunt gewoon je domein bij X kopen en je zooi bij Y hosten.

[angelina]

"Google stelt daarmee dat .app-websites veilig zijn voor gebruikers."

Beetje rare veronderstelling. Https betekent toch dat de verbinding veilig is en niet de content?

[djiwie]

Dat klopt, maar HTTPS is natuurlijk wel een vereiste voor een veilige website. En veel moderne webtechnieken werken bijvoorbeeld ook alleen met HTTPS, denk aan geolocation of notifications.

[FvdM]

HTTPS is natuurlijk wel een vereiste voor een veilige website

Dat hoeft niet per se. Met goede (end to end) encryption kan je hetzelfde bereiken. Kijk bijvoorbeeld naar de webmail van ProtonMail dat PGP crypto in de browser doet. De berichten gaan als encrypted tekst over het net en worden pas ge(de)codeerd in de browser zelf. In wezen is dat hetzelfde principe als HTTPS. Ze doen ook https als extra afscherming, echter zou de pgp versleuteling al voldoende kunnen zijn. Tot het wordt gekraakt natuurlijk maar dat geldt voor elke beveiliging.

[djiwie]

Maar daar loop je (als je geen HTTPS zou gebruiken) enorm risico op een MITM attack.

[FvdM]

Is dat erg? Met end to end encryption is de inhoud alleen toegankelijk voor degenen die de sleutels hebben. Een mitm kan de data opvangen maar niet lezen, of de data bewerken maar dan is het niet meer te decrypten, waardoor de ontvanger gelijk weet dat er onderweg geknoeid is. De mitm kan dus hooguit de ontvangst van het bericht beïnvloeden maar dat kan je ook bij https doen.

[djiwie]

De MITM zou ook een script kunnen injecteren in de webmail van Proton die de private key afvangt en doorstuurt, of een script dat gewoon de mail plain-text doorstuurt nadat-ie door jou gedecrypt is. Een MITM hoeft zich niet te beperken tot sec het afluisteren en daar zit juist het risico in.

[FvdM]

Daar heb je gelijk in, had ik inderdaad geen rekening mee gehouden!

Echter is HTTPS op zichzelf dan niet genoeg, iedereen kan een certificaat maken, zelfs selfsigned of ongeldig als je kijkt naar hoeveel mensen de waarschuwingen gewoon wegklikken. Er moet naast de revocation check ook gecontroleerd worden of dat het echte certificaat is. Alleen wordt DANE/TLSA nog niet echt native ondersteund.

[InjecTioN]

Klopt!

Het enige dat je moet doen om een certificaat te kunnen bemachtigen, is dat je feitelijk moet bewijzen dat de domeinnaam in jouw beheer is door middel van file validatie (een file op de website kunnen zetten), email validatie (validatie link in de email) of dns validatie (cname record aanmaken).

Met bovenstaande is de aangeboden service achter een domeinnaam nog niet veilig. Men kan er namelijk iedere service op deployen die men wilt.

[faim]

Moet zeggen dat dit wel een klein beetje klinkt als het wiel opnieuw uitvinden, om dit in de browser te gebruiken. HTTPS is hier al voor uitgevonden als standaard, dus waarom op een 'omslachtige' manier hetzelfde principe gebruiken. Voor andere doeleinden zou het overigens best prima zijn.

[FvdM]

Voor het geval poort TCP/443 niet mogelijk is. Sommige netwerken vereisen HTTP verkeer om de inhoud te kunnen scannen.

[Luchtbakker]

Je zou zeggen dat mensen .app gaan registreren omdat ze een bedrijf hebben die daarin iets ontwikkeld. Maar bijvoorbeeld picnic.app bestaat ook. Beetje wildgroei van extensies die gebruikt worden waar het niet voor bedoeld is.

[bertware]

Lijkt me net exact waar het voor bedoeld is, zo is "picnic.app" de beste naam (SEO gezien) voor zoekopdrachten naar "picnic app". Zie het zelf ook wel zitten als extra alias bovenop een normale TLD, of als alternatief wanneer geen normale TLD beschikbaar is.

[jpsch]

France.app?

[sugarlee89]

+1

[WORPspeed]

wou net ook dit posten, blij dat jij t al gedaan hebt

[badflower]

Net gechecked en google domains zelf verkoopt ze nog niet / kent de extensie niet.

Namecheap ook niet
Godaddy wel maar alleen presale

[Devaqto]

De helft van die aangegeven registrars ondersteunen die TLD niet eens, lekkere lancering

[Daivy]

Beetje vreemd dat de voorverkoop niet via Google Domains beschikbaar is..? Ik krijg het niet gevonden op hun website en als ik de domain checker probeer dan staat er dat ze de .app extensie niet aanbieden.