Live data from Hacker News

Microsoft mishandling example.com

tinyapps.org

81–90 of 93 posts

Re: Microsoft mishandling example.com

#81
post #53
post #24

Earlier quoted context omitted.

>>multi-account sync and scheduled sending >I would expect such a feature to use end-to-end encryption for the data How would "end-to-end encryption" when such features by definition require the server to have access to the credentials to perform the required operations? If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".

> If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit". This is what Zoom claimed was e2ee for a little while before getting in trouble for it.

This is what Google also claims as end to end encrypted in their Gmail end to end thing. Many people including me mentioned this in the comments.

https://news.ycombinator.com/item?id=45458482

Its entirely their end to their end encrypted. You don't get any privacy.

Re: Microsoft mishandling example.com

#82

Earlier quoted context omitted.

Haven't they been telling people to do that since before it became reserved? If so, the problem is more that you can't "reserve" something that's already in wide use, and mdns should've used something like .mdns. It's like when .dev became a gTLD, knowingly breaking a bunch of setups for a mix of vanity and a cash grab. Obviously dropped the ball on the engineering side.

Seems more a reason to never use stuff you don't actually control and are reserved for future purposes. Everyone knew who was in charge of DNS TLDs and that while they were being at first conservative in how many they assigned, they reserved the right to assign as many as they wanted. But also, yes Microsoft documentation used .local before mDNS reserved it, and IIRC Microsoft was also involved in suggesting it for m…

> my impression of most of that documentation from that time is that it was incorrectly using .local as a fake TLD

When setting up Active Directory on Windows Server 2003, there was a note in the wizard that explicitly called out .local as a domain suffix that would prevent DNS lookups from hitting the public internet, which many people (myself included) took as an endorsement.

Re: Microsoft mishandling example.com

#83
post #82

Earlier quoted context omitted.

Seems more a reason to never use stuff you don't actually control and are reserved for future purposes. Everyone knew who was in charge of DNS TLDs and that while they were being at first conservative in how many they assigned, they reserved the right to assign as many as they wanted. But also, yes Microsoft documentation used .local before mDNS reserved it, and IIRC Microsoft was also involved in suggesting it for m…

> my impression of most of that documentation from that time is that it was incorrectly using .local as a fake TLD When setting up Active Directory on Windows Server 2003, there was a note in the wizard that explicitly called out .local as a domain suffix that would prevent DNS lookups from hitting the public internet, which many people (myself included) took as an endorsement.

I feel like I remember this in 2008 as well. I could certainly be misremembering.

Re: Microsoft mishandling example.com

#84
post #13

>Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... ": Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy…

See also: Windows 11 telemetry

Re: Microsoft mishandling example.com

#85
post #13

>Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" " https://prod.autodetect.outlook.cloud.microsoft/autodetect/d... ": Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy…

I think outlook is pretty much a saas product these days.

What gave it away, the intrusive ads in your free inbox the last ten years,

or the “See Plans and Pricing” on the homepage?

Christ, my poor grandmother…

Re: Microsoft mishandling example.com

#86
post #6

This is why I never use these IANA-reserved domains like .test, .example, .invalid, .localhost. I always make up some impossible domains like domain.tmptest Otherwise you're one DNS "misconfiguration" away from sending dev logs and auth tokens to some random server. > Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' ma…

The correct one to use is .internal

It is reserved by ICANN since 2024-07-29.

https://en.wikipedia.org/wiki/.internal https://www.ietf.org/archive/id/draft-davies-internal-tld-00...

Re: Microsoft mishandling example.com

#87
post #62

Earlier quoted context omitted.

Not just that, the new outlook app makes Microsoft a complete man-in-the-middle for your email account. https://www.xda-developers.com/privacy-implications-new-micr...

This seems like it would completely break any attempt to track access from unauthorized users or devices — any IT department using a backend other than Microsoft’s would need to pretend that all access from MS’s servers is safe.

In response to discovering this any competent IT department would immediately move to ban the use of any offending apps and blacklist the MS servers from the relevant backends. Also I guess rather than drop the connections ideally you would want to accept the initial request, record the provided credentials, and then lock said account because the credentials have clearly been compromised and the user is now known to be making use of a banned app.

Re: Microsoft mishandling example.com

#88
post #53

Earlier quoted context omitted.

> If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit". This is what Zoom claimed was e2ee for a little while before getting in trouble for it.

This is what Google also claims as end to end encrypted in their Gmail end to end thing. Many people including me mentioned this in the comments. https://news.ycombinator.com/item?id=45458482 Its entirely their end to their end encrypted. You don't get any privacy.

Use our new open source (modification and redistribution not permitted) app to exchange end-to-end encrypted (from your client to our server) messages with your friends! Having all your data on our service protects your data sovereignty (we do not provide for export or interop) by guaranteeing that you always have access to your full history! Usage also protects your privacy (we analyze your data for marketing purposes) by preventing unscrupulous third parties from analyzing your data for marketing purposes.

If we had competent regulators this sort of blatant willful negligence would constitute false advertising.

Re: Microsoft mishandling example.com

#89
post #86
post #6

This is why I never use these IANA-reserved domains like .test, .example, .invalid, .localhost. I always make up some impossible domains like domain.tmptest Otherwise you're one DNS "misconfiguration" away from sending dev logs and auth tokens to some random server. > Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' ma…

The correct one to use is .internal It is reserved by ICANN since 2024-07-29. https://en.wikipedia.org/wiki/.internal https://www.ietf.org/archive/id/draft-davies-internal-tld-00...

You can also safely use .home .corp and .mail as those have been explicitly rejected by ICANN on the basis that they would cause widespread naming conflicts. I have my devices configured to redirect queries against .home to a local nameserver, leaving .local open for avahi.

Re: Microsoft mishandling example.com

#90
post #62

Earlier quoted context omitted.

This seems like it would completely break any attempt to track access from unauthorized users or devices — any IT department using a backend other than Microsoft’s would need to pretend that all access from MS’s servers is safe.

In response to discovering this any competent IT department would immediately move to ban the use of any offending apps and blacklist the MS servers from the relevant backends. Also I guess rather than drop the connections ideally you would want to accept the initial request, record the provided credentials, and then lock said account because the credentials have clearly been compromised and the user is now known to…

It’s also the case that, of the major cloud providers, one of them is quite notably poor at securing its own systems. If I were a company that cared about security, I would not want Microsoft holding credentials to my system.
Post reply on HN