This week I've been dealing with an IE11 related problem from a C# app.
The C# app is built using WebBrowser Control[1] which is tightly integrated with the app itself.
WebBrowser only supports IE11 but the webapps that it connects to are increasingly dropping support.
The vendor is reluctant to upgrade their app because the replacement options apparently (?) require extensive refactoring to get the same integration.
IE11 seems to be in a weird limbo. But the fact that it's still technically supported by Microsoft means that conservative software vendors aren't forced to migrate.
They seem to think it's not a drop-in replacement and don't want to rework their code to deal with the changes.
I'm not sure to what extent this is Microsoft making compatibility hard or just a lazy vendor.
It is a completely different API compared to WebBrowser/MSHTL. It is akin to using CEF (Chromium Embedded Framework) for the most part. This can require rewriting pretty much everything that interacts with the browser currently as well as dealing with a completely different threading and event model in the new APIs (both WebView2 and WebKit/CEF/etc)
>And now Slack are going to sell for $24 billion or more.
I still can't quite grasp these acquisition numbers. At that price you expect Slack to generate 1.5-2 billion in profit per year. That's 4 times their current revenue. When you factor in risk and time value of money it becomes more like 3+ billion per year. I just can't imagine a chat app driving that level of profit.
It's a chat app that integrates to most other services you use and ends up being the most extensive repository to all of the information shared inside your company.
As someone who pays for Slack, it would be VERY hard to make a switch. The impact of this in retention and opportunity to monetize the 'integrate workflows' increases the multiplier. Salesforce has probably calculated how this opens up revenue to their existing product line and Slack itself is growing.
I'm not saying this is science but is part of the rationale that goes into the price.
I think it is a _little bit_ off to just consider Slack to be a chat app. Sure chat is the core function...One thing I find super valuable about Slack is that it is a searchable archive. When a new person joins a company, they have literally years and years worth of searchable content. This helps get up to speed, cuts down on time spent asking questions etc. I find myself searching Slack many times a day pretty much every day at work. Not to mention automated workflows, calendar, drive integration etc.
> When a new person joins a company, they have literally years and years worth of searchable content.
IF your company is paying to preserve it. At my not-very-tiny employer we only pay for something like 1 year of retention. I have no idea if that's a legal or financial decision, but either way it seems like a dumb one.
This is the exact reason we use Discord at my day job. Unlimited history for free. We still also get plenty of other integrations, webhooks, and bot-building for other automated things.
User account retention you mean? This is why I try to shy away from work-related conversations in private messages (only casual chat) and encourage everything to happen in channels, which in turn are preserved.
Definitely legal. In Teams our messages are only retained for 90 days. You have to create a team for messages to be stored permanently. Similar for surveillance footage. Fortune 50
If you are only required to keep data for one year and you keep it for 2 years, you can still be subpoenaed for that 2 year old data if you keep it. Thus, keeping data for longer than you are required is an increased business risk.
I've seen Slack, HipChat, Slack (round 2), Flock, and now Teams in as many years, at the same employer. I can't even say anything snarky about the people making these decisions because they're so far up and removed from us developers, I don't know anything about them. The whole thing is just comical now.
>"I'm not sure that puts Slack in too bad a light."
For another perspective, from a WSJ article on Friday:
>"Zoom has grown to more than 300 million daily active participants—a broader measure than daily active users—from around 10 million before the pandemic. Microsoft’s Teams, which offers Zoom and Slack-like features and comes at no extra cost for users of its Office 365 suite, grew from 32 million daily active users at the beginning of the pandemic in March to more than 115 million last month. Slack stopped updating its daily active user number late last year when it reached 12 million." [1]
The Zoom metric is totally incomparable (they’re definitely killing it, but that metric counts each user many times over), and Teams is included for free with O365 and the product boundaries are getting blurry - so who knows how much how much actual engagement those users have with the chat or video features.
300 million for zoom is actually kind of believable. Here in Mexico private schools were using Zoom for virtual classes. I know of many other countries who took the same route.
Obviously public education couldn't use it because of a lack of hardware or internet connection on both sides so it was broadcast over TV.
When you report Daily/Weekly/Monthly Active Users, you report distinct daily users. So unless each one of these users are using a different device with no identifying features to connect them under a same identifier, the numbers are more or less accurate. Users who do not use the application during the period are not counted.
Sure, it could be that they are lying, but considering how Zooming has become a synonym for video chat, I don't think it is that farfetched.
Sure, but the Zoom metric is not "Daily Active Users" it is "Daily Active Meeting Participants". They've been very clear that this counts each time a user joins a meeting.
(Of course this was all back in April, and especially with their adoption in education maybe they _do_ have 300m DAUs by now - I'm just responding to the metric in the original article.)
Teams is completely failing to replace Slack in my experience. I think it's must closer to replacing Zoom. I use all 3 daily.
Teams is strong in file storage, direct messages and video calling.
Slack is strong in channel messaging.
I would argue they barely compete, the Slack file storage and video are not great, and the Teams channel messaging is unusable and appears unfixable.
But in a non-technical organisation, who should those messages go to?
Often the initial LetsEncrypt setup will be handled, correctly, by some IT staff.
Then it might break several months or years later for some odd reason.
The organisational challenge is to get the message through to someone who understands it and will act on it.
Yes, and: fix bugs so the setup doesn’t break. I’m constantly babysitting LetsEncrypt. It’s always failing in some stupid way, and all it can go is Email me with: “Ive been silently failing for the last couple of months and now your certificate is going to expire if you don’t drop everything and comb through my logs now LOL!”
This time the problem was LE all of a sudden decided to start storing my certificate in a directory called mydomain.com-0001 instead of mydomain.com, breaking the rest of the setup that relies on things being in the right directory. Automation is only useful when the software behaves predictably and consistently.
Google have made many attempts to sell Google services, and Chrome in particular[1], as professional software that businesses can rely on.
I've been at conferences where senior Google staff went to great lengths to present the benefits of switching to Chrome.
> The experiments are not exactly a secret program and have existed for a while
I've been responsible for managing Chrome in a professional environment for several years and looked in detail at many Chrome management settings. I was not aware of the experiments. They don't seem to be mentioned in the Chrome Enterprise documentation or policies.
> Both can be disabled
How can we disable them? This is on my to-do list for today, so would genuinely appreciate your help!
Whoa, I just set out to find the way to disable them. I thought it was possible, but I seem to have confused that with Firefox. Firefox calls it "studies", and you can easily opt out of them in the browser's options.
Chrome (and chromium) calls the feature "field trials" and there doesn't really seem to be a way to opt out. I'm seriously baffled by the audacity of Google here.
Seems as if the only way to actually get rid of them is to modify the Chromium codebase and compile it yourself.
It might be worth to investigate whether there is some kind of host name that could be nullified on the network, of the server that the trials are loaded from.
Sorry for that misinformation, I clearly have to update my original rant.
No no no. This is an isolated incident. Developers at Google are absolute Wunderkinds that know everything better than the stupid users out there, and never make any mistakes. Except this one time. So don't worry, just leave those field trials enabled, it won't happen again.
Reminds me - they still don’t allow developers to disable chrome auto-fill which renders typeahead/autocomplete functionality useless since the chrome auto fill covers up the typeahead dropdowns. https://news.ycombinator.com/item?id=21238375
The reliability of Chrome is completely astonishing - why do you want to rip the team a new one for making one honest mistake?
Any enterprise that didn't have mitigations in place cannot legitimately complain about what is probably the most reliable piece software they use (adjusted for some complexity metric).
Chrome is a generally great piece of software and I admire many of the things that Google are doing with it.
The frustration here is that Google are operating outside the way we're all used to for software updates.
If we update the software, we know to expect problems. So we can test it and (crucially) roll back.
If Google make changes outside of that then it becomes far more difficult to manage.
Yeah, the fact that Google rolled up a fix in less than two days really shows how good they software engineering is.
I am sure that those multi million dollar enterprises affected by this issue have other softwares so reliable that this was the only time they lost millions on software issue /s.
> I'm seriously baffled by the audacity of Google here
Join the club!
> It might be worth to investigate whether there is some kind of host name that could be nullified on the network, of the server that the trials are loaded from.
Blocking the entire hostname would cause problems with other features of Chrome. But I think blocking the particular URL would need SSL interception which isn't very appealing.
Digging in the code also brought up that URL, and it appears as if the entire feature was disabled if Chromium is built without the "Google Chrome branding" flag (and can then be reenabled by specifying a seed URL yourself via command line). Hence one might get by with building from unmodified Chromium source.
But the options to disable it on official prebuilt Chrome appear to be grim indeed. SSL interception might not even work at all, as I guess Google uses certificate pinning.
> But I think blocking the particular URL would need SSL interception which isn't very appealing.
SSL interception is very appealing in a corporate environment. Thanks for sharing this, I've raised it with the guys who run the proxies here to investigate if we can / should drop this.
It is well worth a read! There are lots of complaints from what seems to be business users of the free version, but also a few by customers of the Chrome Enterprise subscription with managed installations, and they also appear to be affected by this issue and are demanding an option to disable the trials. From that I conclude that it can be considered safe that the trials also affect paying customers, and it does indeed seem as if they also have no option to disable them, at least currently (my personal guess is this is going to change, for sure at least for the paying customers, hopefully for everyone).
Paying customers should have an option to disable it, however unpaid customers should either rollout their own solution or deal with the consequences of running business with free, uncontrolled software.
The bug affected Citrix-style environments, where perhaps 10-20 users are running Chrome on the same machine.
If 1% of users are running the experiment the chance of two of those 10 users running the experiment is tiny, and when they experience the bug it's unlikely to get reported back to Google.
We were affected and our version hadn't changed (in fact we weren't quite on the latest version - we were still testing it). We have updates disabled and are very much aware of how to manage this.
Google changed a feature flag that was automatically picked up by existing copies of Chrome and changed their behaviour.
If Chrome is critical to your company, shouldn't you be testing on Beta before it goes stable? In this case, the feature was enabled on Beta for 5 months, yet not a single impacted company caught it. Even with 1% enabled, no one caught and reported it.
This is explicit. Binary changes and flag flips are very strongly split. This is almost always a good thing, as it means you don't need to roll back binaries to revert problems.
I can see the benefits when thinking about consumers.
I think the difference here is to do with who's responsible for keeping things "working".
In a business environment there is a whole IT department who go to a lot of trouble to guarantee that their colleagues can continue working. But when Google take that control there's a clash, and it hinders the IT team's capabilities.
In the bug thread, multiple orgs stated they tried to downgrade to the last version and encountered the exact same problem. This alone is going to leave orgs circumspect about their security and Chrome’s reliability, at the very least.
I've been dealing with this bug for the last couple of days and it's been hugely frustrating.
This was not a new version of Chrome or a software update. None of our software was updated at all (and we spent a long time checking!).
But apparently Google have an ability to change a setting and globally affect the behaviour of all Chrome browsers by enabling experimental features.
We carefully manage our software updates and patching so that we can test it and roll back if it impacts the business. Google had been good at understanding "enterprise" requirements - disabling automatic updates, setting policies etc.
But this shows that they're really focused on consumers and business users will always be an afterthought.
As an admin why would you not also run the beta version of the browser in a limited setting? That would have helped you find out about this issue sooner, since the experiment was enabled there for a while.
I'm sure plenty of admins do, that doesn't mean you will test with the same flags chosen in an experiment it only means you will see changes going into stable permanently enabled a bit early.
My own experience with ChromeOs is that I switch to beta, report bugs via interfaces provided (by Google) and then the chromium team acts surprised when the regression hits stable.
This looks like a case study of what is wrong with the US healthcare system.
There isn't much discussion of why it's expensive in the US specifically. In other countries insulin prices haven't risen in the same way and are still affordable. So why is the price gouging only happening in the US?
As a T1 diabetic in the UK, where the wonderful NHS covers all of my insulin costs, this is one reason why I'd never be able to move to or work in the US.
> As a T1 diabetic in the UK, where the wonderful NHS covers all of my insulin costs, this is one reason why I'd never be able to move to or work in the US.
I'm a T1 Diabetic in the US and I consider myself very lucky to work in software. I have good insurance, so my medication only costs me about $200 per month. That's just an additional cost I have to pay to be alive, on top of all the other stuff everyone else has to pay for, too. If I had a lower paying job, or a job with less good health insurance, I can see how I'd be priced out of living.
I'm in Australia, my brothers recently diagnosed as a T1 diabetic, he's currently taking a career break to spend time with his family and get his health and medication all sorted out. Thats all fine here because the costs are reasonable, I see these reports form the US and can't help but wonder when it will get here, most 'innovations' do, fortunately the US health system doesn't seem to be getting a foot hold here.
It seems to me, as an observer, that the health system along with the cost of education have been set up to produce a slave class, I could be wrong but its definitely something that I fight to keep out of here. Five years or so ago I was regarded as a socialist, but with how things are going, most people I speak to no longer argue about it, so it seems the battle is being won here. I find it hard to understand how there aren't marches in the street over there about this.
It's bad, but it's not all that bad. Most jobs, such as mine, provide health insurance that makes costs at least manageable, if not reasonable. I live a happy and comfortable life, despite the $200 monthly tithe to the CEOs of the insurance and pharmaceutical companies.
And there is progress being made. The ACA passed under Obama was a very significant step forward, and public perception is shifting in favor of more government involvement in healthcare[1]. As with most things, the problem is money in politics and media. Republicans resist any attempt to slow the accumulation of money into the hands of the ultra-wealthy, and also own the most popular news channels, so they've convinced a significant chunk of the population that making the wealthy wealthier will somehow help them. A good chunk of Democrats are also paid to oppose changes to the current healthcare regime. But there's a growing number of Democrats actively campaigning for single-payer and other sane systems, and support among voters for single-payer is also growing[2].
There's hope. The situation isn't so bad that violence is the answer, yet.
It was touched on - there's the "official list price" (which has gone up) and the "price actually paid by large providers" (which has gone down).
My best guess is that the price rises were to bring in some immediate profits in the short term ("this quarter isn't looking good") and them these were shortly followed by the compensating discount you have to give to your pissed off customer.
Problem was that nobody gave a toss about the profit margin on the lone guy paying $1000 a month (or $1300 a month) at retail.
The reason is that there is demand for the newest drugs and insurance will pay for it. In the US, doctors quickly switched patients from vials to pens, from Lantus to Tresiba, etc. The price goes up because insurance/PBMs negotiate large discounts. Most full-blown diabetics have two insulin prescriptions and after insurance pay $50-100/mo in out-of-pocket costs, so the increases are hidden from them—hence the need for articles like this one.
>In other countries insulin prices haven't risen in the same way and are still affordable. So why is the price gouging only happening in the US?
The price hasn't really risen in the US either. Or at least not as much as the article implies. The list price has gone up but the corresponding discount given to insurance companies via PBM has gone up about the same. For most people it doesn't make a difference because they buy through insurance. For people like in TFA they get screwed because they have to pay list price. Theoretically, the number of people in that situation should be 0 post Obama care but obviously there are cracks.
Unfortunately, the guy in the the articld fell through a crack. Mostly because he didn't realiZe that buying through insurance would save him a bunch of money. Or maybe he was at the wrong pharmacy to get a huge manufacturer discount.
And this is a good illustration of how the system is completely fucked up. No part of what you wrote is sane (I'm not implying anything about you, just the system). The corporations have gamed the system where it's now normal to suggest that you are responsible for determining and getting discounts, in this instance that it was on the subject of the article to figure out the system, the system that was supposed to be helping him.
Being in an employee-owned company, I'm very aware of how much the company pays for insurance. It never goes down, it always goes up. The company has to switch to plans where employees pay larger and larger deductibles, just to keep the insurance cost increases down in the 10% per year range. Usually the reason costs go up is because we "use it too much", people need to use generic drugs, etc. Of course, it's hard to determine actual costs in such a convoluted system, but orders of magnitude cost increases for medicines obviously plays a significant role.
> The corporations have gamed the system where it's now normal to suggest that you are responsible for determining and getting discounts
It's not really that difficult. You just buy insurance or get on Medicare/Medicaid and you get the discounts. That's not to say that the system hasn't been grossly perverted. Just that the hoops aren't difficult to jump through for pretty much everyone.
> Just that the hoops aren't difficult to jump through for pretty much everyone.
The hoops are incredibly difficult, just at random.
My son was just diagnosed with T1 diabetes as a juvenile. The insurance company denied coverage for the ER visit and in-patient overnight stay after being admitted. They stated since he was not yet hyperglycemic and in acute stress that it should have been an outpatient procedure.
So what sounded like a $50 co-pay because he has good insurance, turned into a $20,000 bill out of the blue that must be fought.
It's worth noting that this isn't about the type of insulin either - the NHS generally prescribes the new, fancy insulin analogues to type 1 diabetics as their first choice because they provide actual clinical benefits, despite this article's claim that they're a giant con that only exists to line the pharmaceutical industry's pockets. In particular, Lantus used to be the recommened long-acting insulin of choice for new patients until they switched to something even newer a few years back.
It's because the US healthcare system is a nightmare combination of extreme government control & regulation, and corporatism. They socialize the cost and privatize the profit, to the benefit of a small percentage of the population that works in those fields or invests into them. It's a very large, regressive wealth transfer. You can only do that with the intentional, direct assistance of the governments (federal + state governments) as enablers that protect the healthcare cartels and worker guilds.
Unfortunately we still have to have similar authentication methods for other password resets. Users have an alarming tendency to forget their passwords after a week or two of holiday.
Also not helped by the fact that passwords have to include every symbol and their mother, cannot include sequential digits, cannot include sequential letters, cannot include any letter of your name, and a bunch of other inane rules that could be changed to simply having a minimum length of 12 instead of 8...
Always a joy when your generated password is refused:
694*C73&4:Ekp>fy>SE&o![RC
(This is an example of what password-store generates.)
Not good enough, because it's too long. Nothing throws you back ten years in time like having to handcraft a password to comply with all the silly rules.
Not so long ago I had to register to a website allowing a comma (or was it a semicolon?) in a password during registration but refusing to login using said password. Fun times.
I once spent 15 minutes trying to register in a local Domino's website which kept bugging me about lack of a special character - even though I had one in it. Turned out to be that the app truncates the entered password after the first 20 characters and only considers the first part. Thankfully the special character was after the 20th position so I noticed the error and fixed it, but if it wasn't I'd be wondering the next time I'm logging in why it's not letting me login with a valid password.
I've had the same problem with Verizon, in the past the password would only store the first 20 characters. Took me an hour or two to figure it out and fix the problem. I'm not sure if that's still the case, hopefully not.
My issue with Verizon is they lock an account after 3 bad attempts, and the "username" is the cell phone number for the account. Which seems to be slurped into some automated brute force engine.
Every single time I want to login, I have to do a password reset first. Makes me which I had the phone number to every manager in the company, so I could lock them all out every day.
Also, since having the phone is the only second factor for authentication, that's all you need to access an account.
You might not even have noticed if the login form truncated the input as well before hashing it. (You probably would have noticed after some update to their website removes the truncation though.)
I've had that with work passwords - using my password generator I give them a 64-character gibberish mess, but it turns out that they only accept 16 characters, and I rendered my account useless until they could reset it for me. How frustrating.
You will usually get far better entropy by simply stitching together a random array of everyday words. Example: stitching better everyday words array entropy level. Anyway, as for the too-long problem, then I guess we're back to square one. :)
Strings of everyday words are better than the passwords most people choose, they're memorable, and they're often good enough from a practical perspective. But if you're using a password manager and don't have to remember passwords, you might as well use truly random passwords, which have more entropy.
I disagree. I use a 1Password, and I used to do the "totally random string of letters, symbols and digits", but I've dropped it for the "four or five random english words" alternative for all new passwords.
There are a couple of situations where having these symbol strings is really inconvenient. For instance, reading a password out loud to another person, or when logging in on a device where you can't (or don't want to) install your password manager on (e.g. a PS4 or an Apple TV). In those cases, "puncture-foible-irish-ducat-rejoice" is a lot easier to handle than "jh&6dQ#F]9.Z>u^t]6u+".
The "symbol" password has more entropy for sure, but the actual security benefit is essentially non-existent. No one's going to guess either password, and I'm never using the same password in two different places anyway. The extra convenience is totally worth it.
EDIT: as other people have pointed out in the thread, another example would be badly behaving sites that prevent "paste" or use other techniques to block password managers. Much easier to type in those words then.
... for the same length. But length doesn't really matter unless you're manually typing it in, in which case many people will be faster at typing words than random characters.
The primary benefit of Diceware over a "random" string of characters is that it is easy to remember and truly random. With a password manager you don't need to remember the password and it will be generated truly randomly. A string of 11 random alphanumeric charatcers has more entropy than a 5 word diceware passphrase with the added benefit that it is less to type if you need to do so manually. But diceware can be a good idea for creating the master password for your password manager and if you do that you should probably use a 10 word passphrase rather than 5.
Good try, but that doesn't apply to password managers. Several everyday words contain more bits than a garbled single word, but a string of dozens of truly random characters beat both.
A couple of years ago one of my banks "upgraded" its web site, forcing me to change my password to comply with its revised password guidelines since my old password was no longer permitted.
The result was a password that was shorter, less varied, and less secure than the previous one.
I had a similar problem with Lloyds - every time I wanted to transfer money using the mobile app, I had to type in the password manually as they had disabled the "paste" option. Given my password was auto-generated and 16 characters long - and the password field wiped every time I did an app-switch, I just gave up.
It's very disturbing to see that your worst passwords are for your bank accounts. Each bank I've worked with has some weird limitation like this. Not to forget that the only form of MFA that most banks allow is SMS - assuming they even offer MFA.
Banks are probably still running on the old mainframe (old as in upgraded in 1998 when y2k forced it), with password storage that was state of the art in 1960 (plain text, but the file is actually protected well so hackers can't get it). That isn't to say better password cannot be used, just that they have never enabled it.
I don't understand that - I get that the system that holds the data is old, but when creating an online banking system shouldn't the piece that holds the data be a good half dozen steps removed from the website and authentication?
If they implemented it properly they could have checked the current password against the revised guidelines on the next login. No need to store it in plain text
The login form usually sends the password in cleartext and it's then hashed on the server-side prior to comparing it to the hash stored in the database.
So they can just determine the password's strength at the time when the user is logging in
FirstDirect's "digital secure key" Android app, which allows me (or someone else who happens to get hold of my phone while it is unlocked) to transfer a few grand out pretty easily, limits passwords to "between 6 and 9 characters". And offers fingerprint based auth as an alternative, because we all know how infallibly secure that method is.
Slack does this exceptionally well. If you forget which accounts you have, you can put in an email address and it will email you a list of your Slack accounts. If you forget your password, you can get a magic link that automatically signs in through a deep link into the app, no password needed.
It's such a cool idea. If you can reset your password using only your email, there's no security reason you can't just log in with it. It might even be better, since you can then add more annoying steps to the password reset strategy.
Indeed. On sites I have to register but know I won't go frequently I enter a random password I don't even write down, relying on the Forgot password feature if I ever need to come back later.
I have wondered if some web pages effectively have this as the main log in method. If you have a hurricane tracking page, everyone is going to forget their passwords in between hurricane seasons.
Oh, it has a password. But if I remember my password I have to check my email and copy and paste a code from there. And if I forget my password I have to... check my email and copy and paste a code from there... really not much point to the password.
I wondered about this too and asked about it on the security stackexchange forum in case I was overlooking some glaringly obvious reason not to. Turns out that most thought it was reasonable too, though maybe too frustrating for some.
In India, most mobile apps have phone number for username and OTP instead of password. Makes perfect sense for mobile apps. Except when OTP doesn't arrive due to congested sms networks. Or that your account gets hacked with sim takeover or sms MitM (both are currently unheard of in India).
This breaks my workflow -- I almost never open the forgot-password email on the same machine I used to initiate the request. Usually I need to briefly access a personal account from somebody else's computer or my work computer, and when I'm told I need to check my personal email, I only want to open that on my phone.
Honestly this just seems like there needs to be a better way. Maybe some multi-factor system that requires like a physical key and either a secret and/or some identifying thing.
The C# app is built using WebBrowser Control[1] which is tightly integrated with the app itself. WebBrowser only supports IE11 but the webapps that it connects to are increasingly dropping support.
The vendor is reluctant to upgrade their app because the replacement options apparently (?) require extensive refactoring to get the same integration.
IE11 seems to be in a weird limbo. But the fact that it's still technically supported by Microsoft means that conservative software vendors aren't forced to migrate.
[1] https://docs.microsoft.com/en-us/dotnet/desktop/winforms/con...