Unfortunatley like many of the other comments have pointed out. This is incorrect. Most of the military currently uses Teams and O365. The military deal for hololens is going through and the shipments are greater thant he initial order. That information is dated.
Um, just think of what you're suggesting. At MS some department (marketing, sales, product managers, devs?) somehow coordinated a bunch of press leaks (not sure how these were even determined to be 'leaks'), made sure that media outlets collectively believed that they were problematic, and then used those leaks to influence sales?
It's a stretch to attribute to malice what can be attributable to other environmental factors. Could it be that Zoom was/is the dominant player in the video conferencing space in 2020/2021, so media outlets were keen to cover stories around Zoom? WebEx and Google Hangouts vulnerabilities have also not received as much coverage as Zoom.
> At MS some department (marketing, sales, product managers, devs?) somehow coordinated a bunch of press leaks (not sure how these were even determined to be 'leaks'), made sure that media outlets collectively believed that they were problematic, and then used those leaks to influence sales?
You’re literally describing a thing that exists which is called public relations. I’ll admit it is unlikely for the call to be coming from inside the house, but this would be the exact kind of thing done by an agency contracted by Microsoft — for among other reasons, plausible deniability should anything become public. “Microsoft would never badmouth Zoom.”
> media outlets were keen to cover stories around Zoom
Hmmm, I wonder if there’s a field of professionals who make media outlets more keen to cover stories around a certain topic?
So we’re suggesting a 3rd-party PR firm likely coordinated public criticism about Zoom, an app that was undergoing hyper growth and entered the public consciousness in 2020 due to WFH and COVID. We don’t think media outlets would likely have wanted to voraciously cover Zoom stories because Zoom became one of the most widely used apps out of nowhere?
The logic appears to be: I saw a lot of news stories about X, therefore X was caused by Y, without recognizing that Z is just as likely a cause for X.
I was more making the point that you seemed unaware of the concept of public relations and instead thought that Microsoft developers would take the initiative to sow the seeds of Zoom discontent themselves.
Reading through these vulnerabilities, it feels like a handful of these are low priority or non-issues. This might be a controversial opinion, but it’s not clear to me why these issues ought to be prioritized and fixed expediently.
For example, it’s not clear to me why an IP address leak is considered problematic. And breaking chat or crashing on reload seems more akin to a bug a la iMessage link bugs like https://www.theverge.com/2018/1/18/16904774/ios-iphone-bug-c.... That type of issue should be fixed, but it’s not a vulnerability that’s meaningfully exploitable for either remote code execution, stealing client credentials, or stealing client data.
The IP leak one is really interesting to me. Considering the quip regarding the fact that centralized servers are performing the link preview operation because it's not using E2E encryption... But if it was, and the client machine was generating the preview, then wouldn't that force exposure of the client's IP to the remote server?
Yes, these are the tradeoffs between client side and server side link previews. (If the sending client does it, they could lie; if the receiving client does it it's a privacy leak and attack surface increase; if the server does it then it sees private data.)
Wrong, Microsoft’s internal incentives are aligned with GitHub remaining independent and building developer mindshare. The, relatively, minuscule business they get from MPA (No Azure, Office subs, Windows subs) is extremely fringe in comparison to losing long term developer mindshare. Even if you thought of representative companies in the MPA,e.g., Netflix, Warner, etc., which are only loosely coupled to the MPA itself, this is still tiny in contrast to overall developer mindshare. This is why they reinstated popcorntime etc etc.
This makes no sense to me. An iPhone without a browser? There are a dozen other random apps and features in O365. Is bundling or building of these features prohibited because Microsoft Access competes with Airtable? I’d argue Teams is half zoom half chat. It’s about as similar to Slack as Access is to Airtable.
Even the selling separately argument seems absurd. How is this any different than adding another Office SKU?
This is called cross-org transfer pricing. It's a common practice in accounting. In fact, imagine a company where this doesn't happen. Retail decides that they can "excessively" use AWS. This contributes to waste and problematic accounting when it comes time to report finances.
Indeed half the point of AWS was to facilitate cost accounting. Probably because Bezos thought they had expertise in online marketplaces that would transfer. Jury's still deliberating on whether AWS' incomprehensible billing is a signal of incompetence or sheer brilliance.
Designing billing for a service can be really challenging. The ideal pricing structure exactly aligns the incentives of the customer with the costs of the service provider.
As a service designer, it is challenging to achieve this and strike the right balance. One naive solution is to account for all of the possible costs that users generate, and surface them with a price in the bill. But this can result in extremely complex pricing structures with many dimensions. If you account for many cost dimensions, then your pricing plan is complex and can be hard to understand, and difficult for users to forecast for.
However, if you over-simplify, and reduce the pricing plan to too few dimensions, then you risk running into other problems, such as failing to charge adequately for user behavior that can cause the service to run at a loss (consider e.g. MoviePass -- which simply charged less for the service than what it cost to operate).
Another common alternative is to charge a fixed price and over-subscribe the underlying infrastructure. This can be a reasonable solution in some situations: it's not very likely for literally every person with a cell phone to make a call at the same time, for example. Many infrastructure providers charge a flat rate and scale for the expected regular (daily or weekly) peak. But if there's a massive natural disaster then a large number of people might make calls, and the network might fail. If you are an e.g. doctor who needs to be called to a hospital, or a first responder who needs to be called to a scene, no matter the situation, then perhaps the right pricing plan and offering for you is something like a guaranteed cell phone line, which comes with the promise that it will not be over-subscribed; but this will come with a cost, since you are paying the infrastructure provider to keep that circuit around and idle. Most retail cell phone users don't want this trade-off, but a few specialized users might. These are the kinds of complications that you encounter when designing business plans and prices.
(I'm making up an example about phones but hopefully it gets the point across.)
I can share a personal anecdote about a challenge in designing the pricing plan for Simple Email Service: we launched the service charging a flat rate of $0.10 per thousand emails (a price substantially lower than other providers at the time). Then one user decided to use us as a data delivery platform, doing nothing but sending maximum-sized emails with attachments. We expected some variation in email size but didn't account for a use-case of constantly sending max-size emails.
What are our options?
1. We could do nothing and potentially take a loss on this customer, subsidizing their usage forever from the revenue from other customers. That's not fair to other customers of the service, and subsidies like this might prevent us from lowering the price of the service in the future.
2. You can tell a customer that you can't support their usage -- essentially kick them off the platform. That's the last resort for all businesses, but it is an option.
3. We could introduce a price per byte of email size, but email size is insignificant for the vast majority of users. Most users want to be charged by the number of emails that they send -- they don't want to have to think about the size of their emails, which are typically not significant. Charging per message is also the industry standard, what users expect, and keeps the pricing plan simple.
Charging per message also has the important property of making it simple for users to forecast what their costs will be for some potential usage, which is an important property of a pricing plan: this is not necessarily true if we charge for the byte-size of emails. Companies can't necessarily forecast the size of all the emails they will send since they can be generated as the result of e.g. personalization or user behavior.
Here's what we actually did:
4. We resolved this particular challenge by introducing a price that only applies if the email has a data attachment. If you send an email with an attachment, then there is an additional price that applies per GB of attachments sent. In this way we kept the price simple for the vast majority of the user base, while accounting for this cost in a way that allowed the user to keep doing what they were doing if they wanted to.
AWS teams invest a lot of thought into getting pricing right. It's a very difficult design challenge, especially when you involve the combination of many services, many potential user behaviors, as well as in what state your infrastructure will be in during yearly peak usage (whenever that might be -- e.g. tax day, Prime Day, Chinese New Year, or whatever is relevant to your service). In designing pricing plans, it is a constant struggle between trying to keep them simple, while trying to allow them to be complex enough to model the important parameters of users behavior.
So why didn't that customer just start sending emails that weren't MIME compatible--and so wouldn't have "attachments"--but still carried a very large amount of base64 encoded data (which is all MIME is doing anyway)?
As I recall, in this customer's use case, they wanted to deliver the data as email attachments that the recipient could download (recipients were regular people). I think they were selling ringtones or MP3s or something of that nature and the email was the method of delivery. It was a pretty cool concept.
> then perhaps the right pricing plan and offering for you is something like a guaranteed cell phone line, which comes with the promise that it will not be over-subscribed
Something like that does exist: https://en.wikipedia.org/wiki/Nationwide_Wireless_Priority_S... Mostly cops only. Fun fact: satellite phones had terrible reliability during Katrina, because so many FEMA people showed up and tried using them at the same time that they saturated the Iridium network.
It can also open up a can of worms as companies as big as Amazon can get into trouble with regulators.
When I worked at BT we could not crosssubsidize say our online services and had to give up the short dial for access 618 used to connect you to PRESTEL on any exchange.
Also at one point they where considering not allowing people working for a joint venture to use the same restaurants
100% this. Mermaid is fantastic for the happy path, but as soon as you run into any issues, the lack of flexibility makes it nearly impossible to use (It tames more time to use mermaid than to go back to traditional diagramming tools).
