Oxford Temporarily Blocks Google Docs - <AUTHOR> http://blogs.oucs.ox.ac.uk/oxcert/2013/02/18/google-blocks/ <comment><USER3> They're attacking the wrong part of the problem.

If misleading messages ("phishing") are leading their users to enter credentials onto forms which are then used to send out spam, then the solution is not to block access to one of the sites that supports forms. There are an unlimited number of sites that support forms. There are LOTS of better ways to solve this problem. Here are a few:

* Train your users where it is and isn't safe to enter credentials.

* Don't give your users credentials. Have some alternate way to authenticate them like a login token.

* Put rate limiting on the ability of a single account to send out emails.

Blocking the site for just a few hours as an emergency response to a short- term attack is a much more reasonable approach. Sometimes, to react quickly, you need to take measures that are not the best possible choice. But there were better approaches, and the security team should take measures to ensure that they can react more effectively next time. For instance, in this case, a single mass-email or email "virus" had gone out and was tempting a large number of users to give out their credentials. Instead of blocking the site that was collecting the credentials, a better solution would have been to remove the email from the mailboxes of all the students. After all, the emails system is provided by the university, and this cuts off the problem at the root. They should institute the necessary technology to support doing this next time they have a phishing problem... perhaps they can even do this proactively: set up some honeypot accounts not receiving any legitimate emails and automatically destroy any emails matching the signature of emails received by these honeypot accounts (with manual review afterward to correct for false positives).

<comment><USER4> Oooooooooooooooo rant coming on.............

Im sorry, but that is the typical tech reply that blows normal people's minds. Blame the user. Well, the user says, sod that, lets just block the problem and get on with what we wanted to do in the first place.

People, normal non tech people, want to use computers as a tool, not become experts in thwarting criminals, etc. If a user cant just go to a computer and simply use it, like say a library or book, then the computer and its champions are failing. Its not the users job to provide security. And no, its not like locking a door. The sheer amount of rubbish poor users have to go through to be safe on a computer is frankly a joke, and the reason so many non geeks love Apple. Yes geeks know Apple are as insecure and any one else, but users _believe_ they are simple and safe.

(At this point, by all means picture a toddler going mental in a shop)

I've been in this business for 30 years, and "train the users" is for me a 30 year mantra that no one out side of geekdom wants to hear. It was my job to enable them to do their job more efficiently, not expect them to become some sort of security expert.

This Uni is doing the simple easy thing to let its users function safely. If the IT world doens't like it, then 1: tough, 2: damn well fix it, and 3: stop blaming users.

Then, you tell them to limit emails. "Oh right" says the user, "I thought one point of email was easy mass mailing, and now you want to bloke it?"

Really think about the user. Its they who make computers and the internet worth bothering with.

I feel better now. Thank you.

<comment><USER5> I'd like to use my car like a tool. Why do manufacturers make them so difficult to safely operate, I shouldn't require any additional training to operate it, I should be able to just hop in at location A and hop out at location B.

Regardless of what some folks in the "User Friendly" movement would like to think, most tools require basic instruction in order to be safely used. We can't code away all individual responsibility.

<comment><USER6> Spotting a phishing form only seems like "basic instruction" to you because you're highly computer-literate. It's not; it involves understanding at least some of DNS and the difference between hosts, domains and TLDs, URLs, HTTPS, and not to mention certificates and their validity.

In your analogy, it's like saying "people shouldn't be allowed to use cars unless they can verify the hydraulic pressure in the master brake cylinder"

Which is wrong: manufacturers should (and did) install brakes warning lights. And we need to come up with better warnings for users. Blaming them for these sorts of problems is unacceptable.

<comment><USER7> How to spot a phishing form:

1) Did you click a link from an email? 2) Does the page it redirect you to ask for your login info?

You may have received a phishing email. Are either true?

1) You expected this email because you were notified about it from another source e.g. website, support staff. 2) If you login to the website not via the suspicious link, the linked web page does not ask for your login.

If you answered yes, you probably don't have a phishing email.

<comment><USER6> "Login to the website not via the suspicious link" requires understanding what URLs are, how to isolate which part is "the website", how to edit them and how to enter them. The amount of people Googling for "log into Facebook" proves none of this is a given.

"You expected this email" is also not a hard test to pass in either academia or corporate settings, where users are generally besieged by unsolicted instructions to "Go here, do this, hurry up about it".

<comment><USER8> Not huge blame, but browser makers are making it harder to understand what's going on what how to use the web - obfuscating the URL - taking off parts of it, sometimes hiding the entire URL bar altogether.

Similarly, 'cookies' are 'scary' - there's _no_ visual indication in a browser of what's going on with cookies, what they are, what they hold - you have to dig deep in 'preferences' then 'advanced' or 'security'. Instead of easier to use tools, we get legislation around cookies. WTF?

Don't get me started on certificates...

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's the perfect example of why security teams are often considered to be the least friendly, least approachable part of an already unapproachable department (IT).

Their reasoning seems to be "Google Docs causes us (the security team) hassle, we don't use Google Docs, so we'll shut it down".

They might as well of shut down the whole of the Internet, for all their nonsensical reasoning, except they'd of been affected themselves then..

<comment><USER10> No, their reasoning is that the continuous phishing attacks caused unacceptable trouble with their email system (e.g., Hotmail dropping all emails coming from Oxford). Due to extensive international collaborations, keeping a universities email system running is probably one of the most important tasks of the IT team. Google Docs is nice and useful, but nowhere near as important. Given that they, practically speaking, had no alternative way of dealing with the phishing attacks effectively, they made the right choice in temporarily suspending Google Docs access.

<comment><USER11> "no alternative way of dealing with the phishing attacks effectively"

How about not using passwords? All students, staff, and faculty should have ID cards; start issuing smartcards, and start using cryptographic techniques to authenticate users. Also, digitally sign all official mail, and instruct the users to check those signatures.

These are not insurmountable problems. The real issue is that the IT team is not willing to push for a real solution, and instead went for a bandaid on a broken leg.

<comment><USER12> Your solutions do not take into account the main problem with the security department: budget. There is a huge budgetary crisis in ALL european universities at this moment, including Oxford and Cambridge.

I bet if they ask for the resources to implement all those solutions, they will be told: find something at zero cost, I repeat zero-cost. Roger that?

Not that I agree blocking google docs is reasonable, just pointing out the problems with your suggestions.

<comment><USER13> >Your solutions do not take into account the main problem with the security department: budget. There is a huge budgetary crisis in ALL european universities at this moment, including Oxford and Cambridge.

False.

</comment></comment></comment></comment></comment><comment><USER14> Misleading headline. They blocked it for a few hours until n people complained. There was more legitimate use than expected, so they unblocked it again.

<comment><USER15> The real question is, as IT professionals, why would there be more use than expected? Would you expect the premier free cloud competitor to Office to be heavily used?

It's as misguided as most of the IT departments I've had to deal with blocking browsers other than IE because they are "insecure". No the other browser are not insecure, they just haven't bothered getting up to speed on the security profile of those browsers and confuse getting regular security bulletins about IE to be the same as being "secure".

<comment><USER16> Yes, they should have known better. Google Docs is used a lot at universities because of its collaborative abilities. If you need to work with several people putting a report together, Google Docs is a great way to get started. We often eventually take it out of Docs into a desktop program to finish it off, but Google Docs is one of the best ways to collaborate.

How the IT department didn't know what its students, faculty and staff were doing is kind of hard to believe. For students and teachers in particular, Google Docs is a big deal. It's not just because it's a cloud version of Office, but rather that it has things that Office can't do that are especially important in a university setting.

<comment><USER17> > _Yes, they should have known better._

As they point out, connections to Google Docs are encrypted. There's no way for them to tell what is and isn't legitimate traffic.

<comment><USER16> There are multiple ways to know what your users are doing, and there is more than just monitoring traffic. They can do surveys and qualitative studies, and they would have then known how widely used Google Docs was.

Lack of knowledge is not an excuse.

</comment></comment></comment></comment></comment><comment><USER18> I currently work for the web communications part of a small-to-medium size university. We have around 2000 employees and 8000 students. We embrace all google products on campus. We actually use gmail for our primary email system. We use google forms to collect data throughout our website (not perfect by a long shot, but makes data collection approachable and accessible to end users). We would never shut down google forms. We simply couldn't. We regulate mass email by only allowing a select few individuals to email to all users. We have literally a dozen or so users on campus that can send an email to all users, and most are in the communications department or IT. All this talk of authentication systems, and teaching users not to get caught by phishing, sounds like "ideal world" solutions. Our solution is simple. If you want to send out an email to everyone, send it to a central authority that can approve the sending. It is easier to make sure a dozen people have the skill to send a mass email appropriately and avoid phishing attempts, then it is ten thousand. Also, it has the added advantage to allow us to consolidate less urgent emails into a single newsletter once a week, keeping faculty/staff and students email boxes free of non-urgent notifications. I'm not pretending we have a perfect solution, but it seems like we'd never get approval to stop using google docs in a situation like this. I'm actually rather impressed by Oxford's ability to react and then write a long and thorough explanation of their actions.

<comment><USER19> > Our solution is simple. If you want to send out an email to everyone, send > it to a central authority that can approve the sending.

It sounds like all you are doing is regulating access to some sort of all@university mailing list. How does this solve the much bigger problem of spammers using compromised accounts to spam Gmail/Hotmail addresses, which then end up getting the university blocked? And even ignoring that how does it prevent people from just looping through a list of your university's email addresses and sending them one at a time?

<comment><USER18> You are mostly correct. We are primarily regulating access to a all@university mailing list, but we also have restrictions that prevent mass emails being sent via gmail (though I'm not the authority on this). You are correct, nothing prevents a compromised account, that I know of, from sending out emails one at a time to an list of users, though we do have control over all email accounts and can disable a compromised accounts. If the traffic is internal we have other ways of preventing it. I'm not saying our solution is an absolute substitute for all combinations of possibilities. Just that if we were to be blocked we'd have to deal with it in some other way then to disable google forms. We just couldn't get away with it, and according to some of the comments, Oxford couldn't get away with it very long either.

</comment></comment></comment><comment><USER20> Summary of the blog posting: Google Docs forms are being used in phishing attacks against stupid users. We closed down Google Docs. It didn't work and we had to open it up again after 2.5 hours.

Unfortunately, there's no easy solutions to so-called phishing attacks other than educating users. I would recommend that the IT dept. dedicate its considerable resources and creativity to that end, and try to minimize use of the shotgun approach in the future!

<comment><USER21> This.

The only effective solution is to educate users, but that in itself is a difficult task.

Phishing attacks rely on users being gullible / distracted / ignorant. Telling users _not_ to be any of these usually results in angry answers such as "Are you implying I am stupid !?", and the important part of the dialogue where you explain things to be wary of is completely ignored.

Another way to communicate these things it to _phish your own users_. Email them a fishy message ultimately asking them their password for instance, the same way an attacker would. Of course, some phishing emails / sites look incredibly legit but in my experience most have noticeable deficiencies. If your users can spot at least those, then they can protect against a good number of attacks. Once the victim falls for the trap, redirect them to a page explaining how they were tricked, and showing what they need to pay attention to.

You even get their passwords, so that you can do some analysis and see how many will change it following the 'incident'.

<comment><USER20> "phish your own users"

Now that's the best idea I've heard all morning. You should be running Oxford's IT dept!

<comment><USER17> I disagree.

At best the users who don't care will continue not to care. At worst it will train users to think "oh, it's another drill, ho hum".

Somewhere in the middle is some deeply embarrassed Deputy Vice Chancellor who decides to make those horrid computer people his personal enemies.

<comment><USER22> _> At worst it will train users to think "oh, it's another drill, ho hum"._

How is that a bad outcome? Whether they think it's phishing or a drill, the important thing is that they don't enter their credentials.

<comment><USER21> It's bad if users are trained to only recognize _your_ phishing attempts :-)

I'm not sure I understand which users jacques_chester is talking about. There are users that can recognize phishing, and they are entitled not to care about your teaching. And then there are those that can't recognize phishing - <USER2> perhaps don't even know about it - but I'm pretty sure any user would start caring when they find out someone else can gain access to their email/bank/facebook/whatever online service they use if they aren't careful.

To avoid training users into thinking it's another drill, perhaps it's a good idea to 'attack' them at random intervals, and wait a few months before repeating (thus giving you enough time to prepare the new attack; giving the users enough time to forget about the threat, and to account for new arrivals).

I'd rather be embarrassed by the local BOFH, rather than be a real victim

</comment></comment></comment></comment></comment></comment><comment><USER23> I feel for them. I attend an IT-focused university that has both hardcore techies (computer science and such) but also a lot of non-techies (communication, UI design, etc.)

We frequently (at least once per month) get a phishing e-mail asking us to reply or click a link and provide our credentials. For anyone who has attended the university more than 6 months, there will have been at _least_ 3 e-mails from the IT-department telling people to not ever, in any way, give out credentials. Yet, for every phishing mail we get at least 3-4 accounts get compromised (out of ~1500), and more would get compromised if the IT department weren't quick to block traffic to the offending URLs. And again, this is in a crowd that should be somewhat unfavourable to scammers (as most of us know and can recognise such attempts).

You can try to educate your users, and you should, but just know that it only minimizes the risk, it will never, ever nullify it and if they can send 1 million e-mails from just 1 account, then it is practically a dead-end in terms of stopping the scammers. I can completely understand why they are blocking Google Docs, it's a matter of settling for the "lesser evil" solution.

<comment><USER24> I've had 4 emails in the past month providing information about the phishing emails from my department, JCR and IT services, and despite that a number of accounts still got compromised.

Couldn't agree more about education never actually fixing the problem.

</comment></comment><comment><USER25> I wonder how many of the keyboard warriors in this thread have any experience of running very large and incredibly diverse networks like Oxford University's.

The guys handling security for Oxford are highly experienced and capable. Oxford's network is far more complicated than a typical University.

<comment><USER26> Yet they apparently have not implemented 2-factor authentication or rate limiting for students' email accounts...

As others have pointed out, there are a few very simple ways to deal with this sort of thing. Rate limiting alone would like take care of the problem. This is probably a simple config update on the smtp server.

<comment><USER25> Catering for such a large and varied set of users requires difficult evaluation of risks and benefits to the majority.

The underlying problem in this situation was that Google were so slow to respond to reports of malicious content.

The brief block on Google Docs has served as an excellent way to get attention and highlight a number of things that need consideration.

<comment><USER26> Google was picked on b/c it was an easy target. I'm sure there are plenty of other fishing sites out there that don't use Google, yet those weren't blocked. This a seriously boneheaded way to go about things. Unless you are just going for media attention.

</comment></comment></comment></comment><comment><USER27> "We have to ask why Google, with the far greater resources available to them, cannot respond better. Indeed much, if not all, of the process could be entirely automated."

The problem lies with the people on the Internet though. I doubt the whole thing could be automated because of the simple fact that there are people out there who, just to troll, would and probably already zip through plenty of legitimate public Google docs and click the "report abuse" link at the bottom of each page.

The result is most likely an overwhelming amount of reported "abuse" pages are most likely legitimate, which is why actual malware docs don't get dealt with in a timely manner. Its like when people prank call 911, which could lead to actual emergencies not being responded to immediately.

<comment><USER28> I think a reasonable solution here would be to only automate reported abuse with a registered account, and only automate a certain number per account per time. it wouldn't be insurmountable to abuse, but you push the barrier for abuse over the average troll's willingness.

not a perfect solution, but would help cover a sizeable volume of this kind of phishing attacks.

</comment></comment><comment><USER29> My comment on their page:

So if the real problem stems from the Oxford mail accounts being hacked and then used to propagate the phishing attacks, why not concentrate on that?

You should use 2-step authentication for the email accounts, so that randoms in some other part of the world can't just hack in to an email account and use it.

I was at SBS, and we were on Mircosoft Exchange servers for email I think. Unfortunately, afaik Microsoft doesn't offer 2-step authentication. Instead of blocking Google Docs, you should be moving all email systems to Google Apps so you can use their better security. We just did it at my company for a few thousand users and several domains - I think you could do it too.

</comment><comment><USER30> May be im wrong but why not set LIMIT of only X no. of mails can be Sent/Minute via user account.

Find out how many emails people usually send per minute/hour and just DENY relaying anything else over that limit. That way it'll be less profitable for spammers to acquire user account details if he/she can only sent X mails every minute.

</comment><comment><USER31> Why not enforce a velocity restriction on outgoing e-mails instead and put spam filters on outgoing e-mail then bounce offending mail back to sender?

Spammers are phishing for ox.ac.uk accounts because they're easy to exploit, right? Just raise the bar.

</comment><comment><USER32> If a fixed login/password pair is enough for someone from external network to send mass e-mail via your network, you have a problem.

Obviously I know little about their network so I'm probably already sounding arrogant but there are some solutions that (generally) have better inconvenience/security ratio than just plain login&pass. Especially if you account for the inconvenience of getting the whole site blacklisted. My site uses one-time, limited-time passwords to authorize external connections but the users are tech savvy so I'm not sure if it works in general settings.

</comment><comment><USER33> Sometimes I wonder what the world would be like if it were illegal for institutions to block sites. It shouldn't be too hard to imagine. No one can block postal mail or telephone calls (except as a user). And, the FCC has banned wireless jamming. In spite of those guarantees of service we manage to survive and, on the whole, protect ourselves from fraudsters.

I think it is too late now to guarantee service through legislation, but the upsides do outweigh the downsides.

</comment><comment><USER34> On another note, my University (uws.ac.uk) started blocking HN this week.

I bet it's probably just because of the illicit connotations of the 'Hacker' word.

</comment><comment><USER35> When did OUCS suddenly become a bunch of muppets. They had some credibility once that appears to have gone out of the window.

</comment><comment><USER36> "In the absence of effective monitoring, it can be easy for over a million messages to be sent out before someone happened to notice."

Just wanted to point out this specific detail. They seem to be attacking the wrong problem, as many others already noted.

</comment><comment><USER37> User education is not the way to solve these sorts of problems. The proper way to solve the problem is through automation -- use of a "forcing function." An example of a forcing function is not allowing an automobile driver to shift into reverse until the they have their foot on the brake pedal. This is a far superior solution to educating drivers to not shift into reverse until they have their foot on the brake pedal.

Google needs to implement a forcing function with Google docs so that their software is not misused on the Internet. No amount of user education will fix the problem -- only some sort of forcing function will fix it.

<comment><USER38> Can you give an example of how it would work? (online for forms, not offline/IRL)

<comment><USER37> I haven't thought about it at all as to how Google would fix their problem. Still, they've introduced a component into the Internet ecosystem that has been found to be abusable and they are accountable to install the forcing functions to prevent that abuse. To depend upon user education is simply irresponsible.

The idea of forcing functions is well known in organizational/system theory.

Another way to think about this is the recent notices that Java (and at other times Adobe Flash) has recently introduced a security flaw where people using their computer can have it hacked into (Apple suggests removing Java unless you really need it).

Just as we would expect Java/Oracle and Adobe/Flash to fix their security flaws so should Google fix theirs.

<comment><USER39> This is a very different sort of security flaw than with Java and Flash. Google Forms was allowing users to create forms asking for information and then send links to other people asking them to fill them out. Which is exactly the intent of the program.

When you ask for a "forcing function" you're requesting a way to let people create forms asking for information in general but not letting them ask for information that people aren't allowed to give out. This may be possible, but it is at least very difficult.

</comment></comment></comment></comment><comment><USER40> This kind of black-listing of specific domains is, unfortunately, just a game of whack-a-mole that's very hard for defenders to win.

If they're seeing targeted phishing (which the article implies that they are), then the attackers will just observe the drop off in people following the links and move the phishing forms to another domain or service, making it very difficult for the admins to keep up.

Really addressing this kind of problem has to come down to a combination of awareness training and improved authentication techniques (i.e. move away from static username/password combinations)

</comment><comment><USER41> How about putting a middle page up with a warning?

So a student on the university network clicks a link to google docs and a warning appears warning of potential attacks using google docs, be aware, and click next to continue.

Is this doable?

<comment><USER42> Users don't read warnings, they just click next.

</comment></comment><comment><USER43> My school blocks Google Docs. When I asked why... they blamed China.

</comment><comment><USER44> I don't think there are any professors for Cloud Computing dept in Oxford.

Why not filter the emails/Ips who send out spam rather than blocking the URL? What if Google blocks Oxford?

</comment><comment><USER45> Could they not just block google forms? I don't see many users entering their username and password into a PowerPoint/Word Document.

Perhaps they could implement some more advanced email filters, e.g. removing all links to google docs, instead of blocking the service for all users?

I'd imagine a mass of the user-base of Oxford uses Google Docs for important things, from group work on a PowerPoint/Word doc, through storing their work in the cloud without the Office Suite.

<comment><USER46> No.

"Another is that traffic is encrypted. Many educational establishments will have some capability for filtering traffic to malicious URLs as it flows through their network. That's easy with unencrypted traffic. If the site uses SSL, then you have to do some kind of SSL interception."

<comment><USER47> Network Admins need to learn that looking at what your users do and meddling with his data is not a legitimate activity. They should have learned that long ago. Fortunately, with encryption becoming more widespread, they will have to learn the lesson.

<comment><USER48> If it's your network, and you graciously allow me to use it, and I, through my use of your network breach the security of systems on your network, would you not do anything in the interests of not meddling with my data?

<comment><USER49> Except the network belongs to the institution (i.e. its users), not the IT department (although most do seem to think this way).

</comment></comment></comment></comment></comment><comment><USER50> The problem is that unless you are a Google Apps for education customer who can get Google on the phone, the form doesn't come down for weeks.

That means they'll have hundreds of credentials and can do all sorts of nasty things to your computing environment and to people's accounts.

That's not acceptable.

Hopefully Google will treat this more seriously now that it's hit the press.

</comment><comment><USER51> Teaching users is an O(N+T) solution with N users (term comes from time spent teaching), T total time spent on computers (term comes from time spent being cautious).

</comment><comment><USER52> How about breaking down the email domains into students, faculty, departments, collages etc. That way it's less disruptive across the board when domains are blocked.

</comment><comment><USER53> Why don't they block Microsoft Outlook? I'm sure a lot more scams come through it.

<comment><USER54> It's nothing to do with Gmail Google Docs Forms are used as the destination for the phishing attack.

</comment></comment><comment><USER55> Why not simply block emails that contain a link to a publicly-shared Google Doc?

</comment><comment><USER56> "the importance of the March Hare to the Aztecs"

a reference to an episode of QI, right?

</comment><comment><USER57> They ask "what's next?" at the end of TFA.

Here's what's next: Oxford blocks roads because criminals are using roads. Oxford blocks food deliveries because criminal are using restaurants to eat.

Seriously now: what's the Microsoft rebate Oxford got for taking such a measure?</comment>


DuckDuckGo XSS vulnerability - <AUTHOR> https://twitter.com/hexdefined/status/940170335093006342 <comment><USER2> That second link is seriously scary, how would you ever avoid falling for that? Does anyone know how it works? Going to [https://tranquil- bits.surge.sh](https://tranquil-bits.surge.sh) I'm guessing I'm seeing the attacker's form, but it has duckduckgo.com/vpn as the URL and https.

Edit: If you click submit on the VPN form you get "This could have been a phishing page." so it's definitely the attacker's form, that's crazy.

<comment><USER3> The problem is the XSS vulnerability. This means the attacker can run arbitrary JS on the site, which I assume is used in the second link to modify the form handlers to run the "This could have been a phishing page.". And yes, that could be used to send the credentials somewhere.

There isn't anything you can do to spot this. This is on DuckDuckGo to fix and they not responding to the report for such long time is irresponsible and not really excusable.

<comment><USER2> They're faking the URL too though - [https://duckduckgo.com/vpn](https://duckduckgo.com/vpn) isn't a real site or product - it just redirects to a DDG search for vpn. The page is entirely the attacker's, but it shows DDG's domain with https.

It looks like tranquil-bit.surge.sh redirects to [http://tranquil- bit.surge.sh/vpn](http://tranquil-bit.surge.sh/vpn) so maybe DDG are somehow setting the URL to whatever the u= param redirects to?

<comment><USER4> The URL faking is with the HTML5 history API. It's possible to fake any URL on that domain because the JavaScript is executed in the context of that domain.

</comment></comment></comment></comment><comment><USER5> Wow.

"Reported in March 2017, emailed them 9 times about the issue since then. Still unfixed as of now."

<comment><USER6> We have corresponded many times about this issue, and have made many changes over that period.

It's not as simple as just shutting down the open proxy because we need an open proxy to adequately protect users' privacy on our site, e.g. for image search. It just needs to be more locked down and more obvious it is a proxy, which we are doing right now (half done already -- CSP rolled out fully, new domains in process).

<comment><USER5> \+ 1

</comment></comment></comment><comment><USER6> We are working on further fixing this issue. We require an open proxy in some form to protect our users' privacy, though it should be more locked down and more obvious it is a proxy.

<comment><USER7> > We require an open proxy in some form to protect our users' privacy

Which feature relies on this?

<comment><USER6> Currently all the features that showcase third-party content on DuckDuckGo, the biggest being image and audio instant answers.

<comment><USER8> Thanks for the update and follow-up answers.

Could you comment on the "Reported in March 2017, emailed them 9 times about the issue since then. Still unfixed as of now." claim, as it seems imperative to the discussion?

Is there something that can be improved here? Perhaps that inbox not as actively monitored as it could be?

<comment><USER6> We have real-time monitoring for that inbox and a 24/7 ops team. We have corresponded many times about this issue, and have made many changes over that period.

It's not as simple as just shutting down the open proxy because we need an open proxy to adequately protect users' privacy on our site. It just needs to be more locked down and more obvious it is a proxy, which we are doing right now (half done already).

</comment></comment></comment></comment></comment><comment><USER9> [https://ddg.gg/html/](https://ddg.gg/html/)

No fancy quick-result box, but fast as lightning.

</comment><comment><USER10> Wow. The example in the tweet would completely fool me. If you just go to the address bar and press enter ("reloading" the page, but actually going to the address), you can see it's just a search.

</comment><comment><USER11> [https://twitter.com/hexdefined/status/940183455509262336](https://twitter.com/hexdefined/status/940183455509262336)

</comment><comment><USER12> Thank you, just the push I've been needing. As of this moment, I'm off to ixquick/startpage, which for one thing doesn't require me to go all laid-back and inclusive on the JavaScript, and which for another has those nifty proxy- links.

<comment><USER13> If you just want a search engine without Javascript try [https://duckduckgo.com/html](https://duckduckgo.com/html)

Adding to Firefox is easy via [https://addons.mozilla.org/en- US/firefox/addon/duckduckgo-ht...](https://addons.mozilla.org/en- US/firefox/addon/duckduckgo-html/)

<comment><USER12> That's one trick I had somehow missed. Mind you, that's _extremely_ barebones, not as much as a link to any image-search or options.

</comment></comment></comment><comment><USER14> Can someone explain what I'm seeing? As far as I can tell, both those links really do leave me on DDG webpages. The only requests according to firebug are to duckduckgo.com. What am I missing (or has this since been fixed)?

<comment><USER6> It has since been fixed.

</comment></comment><comment><USER15> There's a typo in the title - it should be "XSS on DuckDuckGo"</comment>


Enforcing Different Passwords for Different Sites - <AUTHOR> http://diegobasch.com/enforcing-different-passwords-for-different-sites <comment><USER7> "Now, one fine day somecrappysite.com gets hacked. The next time you visit, the web page has malicious code that sends your password in plaintext to someone. There go your Paypal funds, your Facebook account, your online life."

What an optimist! somecrappysite.com was probably storing your password in plaintext to begin with and it probably got pulled from the database long before you logged in again.

Having said that, this is an absolutely terrible solution for real-world usage because it inhibits people who are already security savvy from using better solutions like Stanford pwdhash or similar methods.

<comment><USER8> Right, but those people are the one percent. How do we help the vast majority?

<comment><USER7> Other than education and pushing them to use a secure password manager, I'm not sure, but the solution shouldn't involve breaking existing and secure systems which are widely used even if only by a minority of users.

<comment><USER8> "widely used by a minority" <\- you made my point.

<comment><USER7> Not really.

The proposed solution adds little to no real world security (see my other post about how easy it would be to guess which part is the random one which makes this system not useful unless almost all sites use it, which will never happen). Given little to no real world security gain from the described system, it certainly isn't worth breaking an existing system that works just fine and securely even if for just a minority of people.

</comment></comment></comment></comment></comment><comment><USER9> I agree this is a major issue, and in fact was specifically covered in an earlier xkcd (<http://xkcd.com/792/>) than the one cited (<http://xkcd.com/936/>).

It might be a good idea to enforce non-password reuse, but the proposed solutions seem fairly aggravating. In particular the 'webmaster' solution of requiring inclusion of a fixed string is extremely annoying (oops, sorry users who use cryptographically derived passwords (<http://passwordmaker.org/)>), and doesn't solve the problem since someone with your "main" password can probably guess the "derived" password (e.g., the main password with the mandatory substring appended to the end).

My solution as a user is to just use a password manager. I use clipperz(<http://clipperz.com/>), but there's plenty others out there.

* Edited to remove markdown-style links. Forgot it wasn't supported here.

<comment><USER8> The point is that the mandatory substring is random and unique to you. The problem with using a password manager is that it implies that you're already savvy enough about the issue. Most people have no idea such thing exists. How could you enforce the usage of a password manager?

<comment><USER10> Well.. why not do it half client-side and half in the cloud? For example, why not build an pwd-management application which sits in the cloud.

Have the application store in a secureDB in the cloud your encrypted list of passwords. These would be encrypted with a master pwd stored in the local pwd repository of your (mobile) browser.

The idea would be to have the browser do all the leg work for you and have the pwd management service available form anywhere.

The browser would automatically generate a new complex pwd for each new website you subscribe to, then encrypt it and send it over to the pwd mgmt app in the cloud. When you authenticate to the website, the browser queries the pwd mgmt app for the pwd of the site. The app sends it to the client.

In this whole process the whole encryption/decrpytion happens locally, thus limiting the attack surface. It would be easy to use and overall seamlessly integrated with any device you own that has access to the internet.

<comment><USER9> That's exactly what Clipperz does :).

The main weak point is there's no way for the user to know if the javascript they're downloading is the correct Clipperz javascript, or a trojan'd version that will send my master password and decrypted database off somewhere. So, pretty much all is still lost if someone is able to break into Clipperz and modify the javascript without being noticed for a while.

A possible solution to _that_ is to implement a browser extension to hash the javascript (and perhaps display it as a visual hash) so the user can at least easily check whether it's changed. This has been on my "possible side-project" list for a while...

</comment></comment></comment></comment><comment><USER11> Dear god, please let me have the freedom to determine what degree of security I need on a site.

If you restrict my password options in anyway I will use your site less.

</comment><comment><USER11> I have an algorithm for creating unique passwords.

Here is the result for HackerNews: kcahu3602122@#)*

here for Facebook: ecafu3602122@#)^

(I can create them practically in my sleep. The algorithm is personal and easy)

To determine the algorithm, one would need plain text from two sites and be able to match them. Now, everytime a site limits my freedom to creating the password I want (assuming I can't provide my own security - by demanding a capital, a number, a this a that) I default to the same password. If they get one site with my simple pass, they get all the sites on which I use it.

When you put constraints on my password creation, you make my online life MORE insecure, not less.

Free my password. Don't tell me what I can and can't do. Offer a full page of help describing to those who don't care what they should do. But don't force them.

</comment><comment><USER12> I recommend that everyone who read this contemplates this: <http://news.ycombinator.com/item?id=3889435> (AKA the voice of reason)

</comment><comment><USER13> I am the only person I know who uses a unique, memorable and strong password for every site I use. I store all of them in my head.

I have a base password and I add the first several characters of the site to the middle.

For example:

Facebook - <USER2>

Hacker News - <USER3>

Yahoo - <USER4>

For strong passwords I can add a suffix to further strengthen the password.

PayPal - <USER5>

I use the same suffix for all "strong" passwords. If a site requires a capital letter I always capitalize the first letter.

I've gone to create an account with a site, been told I already have an account and I get the password in 1 guess because I'm so consistent with creating them.

I don't know why everyone doesn't do this.

<comment><USER14> What do you do when you log in to your bank and they tell you that your password has expired and that you need to create a new unique 6-8 character password with exactly one capital letter and one number but no special characters? And that it can't contain any part of any of your old passwords?

I guess the same thing you'd do if you ran across a site with this well intentioned but terrible idea: write it down or email it to yourself.

The only sane thing you can do as a developer is let users chose any password they like, regardless of how insecure you think it is. Store it correctly and that's the end of your involvement. Let your users do what they want, or you'll just make things worse.

<comment><USER13> I have a standard set of characters that I add to passwords. So far Craigslist has been the only site to really throw me for a loop. I try to be consistent but I end up using 'Forgot my Password' more than I should with them.

They are the only ones.

</comment></comment></comment><comment><USER15> This sparked an idea for me that I think I'll implement going forward - if you sign up with your email address and password, my server will try to login to your email account with those credentials, and if successful, say something like "hey, did you see that email [snippet of first email in inbox]". I feel this might encourage the user to use a different password.

<comment><USER16> Reading someone's email without permission is a crime. Nice idea though :)

<comment><USER17> Add some fine print in the user agreement, "During sign-up (only) for service X, I hereby authorize web service X to open my inbox and read one (1) email message, if I choose to provide my email account's password as my password for website X."

No longer a federal crime, maybe? Probably still get an angry mob with pitchforks outside your window.

</comment></comment></comment><comment><USER18> Big ol' hole here: You can't identify web apps by domain. Are you going to tell me I can't use "password123" as my password on store.foo.com and secure.foo.com (when they both point to the same database and the same user record)? Are you going to assume that passwords may be shared across all TLDs? (so I can re-use passwords on multiple separate apps on the same TLD)

It's a nice idea, but in practice, it would drive you _insane_ because the web is not a nice uniform entity where everyone plays by a pre-arranged set of rules.

Just use LastPass and let it autogenerate passwords for you. It's stupid easy, and super effective. LastPass will even tell you how many sites you're using the same passwords on! ( [https://lastpass.com/index.php?securitychallenge=1&fromw...](https://lastpass.com/index.php?securitychallenge=1&fromwebsite=1&lpnorefresh=1) )

<comment><USER8> Nobody gets the point. The point is that you can't _force_ 99% of the people to use something. What I advocate is enforcement on the part of the browser and / or sites. If the user has the choice to be lazy, no solution works.

</comment></comment><comment><USER19> So instead of having websites that require "upper, lower, numeric and special" characters, we'll have sites that require "randomly generated word from two years ago that we hope you remember". It's just another constraint that will never be standard and will be near impossible to remember.

<comment><USER8> If you use a different password for every site, it's a given that you won't be able to remember them. Storing your passwords securely is a different problem.

</comment></comment><comment><USER20> The desire to enforce unique password across sites is understood. You might as well advocate all browsers to implement a builtin password manager a la LastPass and a protocol to auto-gen a password (by the site to enforce cross- site uniqueness) to be managed by the password manager. Imagine zero password fiddling signups!

Force a per site password policy on end users other than length is super annoying. The worst kind are those who restrict you to use only alpha-numeric passwords.

Down with manual password policies!

</comment><comment><USER21> Because browsers already optionally store passwords, adding the "password same" warning would be quite a welcome feature (or add-on), for _me_ anyways (in mobile browsers too).

I advocate the use of password managers, but they don't offer "password same" warnings either.

My point: it's a best-practice feature _option_ which should be implemented widely. People can turn it off if they want.

</comment><comment><USER22> I'm no expert, but why does this have to be done on the password level? Why can't we just assign usernames to our own sites, and force people to login with those? I know that's incredibly annoying for a user, but it would at least guarantee the user credentials for your site are unique from any other site.

<comment><USER23> This would mean that there are two "passwords" that I have to remember - <USER6> userid and the actual password. Chances are, your site isn't worth it to remember a new uid. (I counted that only 5 out of my 150 stored account passwords are for something worth remembering anything at all.) If you are important (say, paypal or gmail) - do two factor authentification. If you are not - don't bother me. Even creating an account is already more effort than most sites are worth.

<comment><USER24> It is equally obnoxious to generate a random string of garbage and:

* insist it's the username,

* insist it is in the password somewhere, or

* make them type the string in a third logon field

It adds friction to the process in order to solve a problem that is not "ours" to solve.

An option with less friction would be to ask them to choose a picture from 16 candidates. The 16 candidate photos would need to be generated from the username to avoid the ability to refresh the page and find the persistent image. Each image could have the random characters associated with it to be used as an addendum to the salt, or for whatever purposes on the back end which the random characters are supposed to accomplish.

</comment></comment></comment><comment><USER25> After Gawker was hacked (and my account with it), I have created a website that tells average folks how to solve these issues: <http://www.passmix.com/>. It's not a perfect solution, but it's way better than the same password for different websites.

<comment><USER26> From what I've read this (and methods like it) seems to be a common way to generate passwords. This seems to be a somewhat weak implementation though - imagine you used this method with the same base everywhere, and 2 sites were hacked, let's called them InLinked and Kergaw. Using the examples from passmix.com with base 'house cat' I might end up with: 'housei!n8cat' and 'housek!e6cat'. Say I'm targeting you specifically, I look at these two passwords, and I see that they both follow 'houseX!Y#cat' format. It's only a moment longer before I've a good guess at how the password is constructed, and then try it against your email. Once I've cracked your email I can just use the forgot password feature of any other site to reset your password there.

It would be quite easy to write a script to detect the similarity with the two passwords (9 characters in common, same positions, same length = 12).

You should never use the same password across sites, nor should you use the same password system unless that system is secure. Assuming you can keep your algorithm for password generation private, passing this through a one-way hash function might then strengthen your password a bit (at least a hacker couldn't easily visually derive your password algorithm, or that you are using one) but this still isn't perfect.

Generally it's not a good idea to tell people how to construct passwords unless you're an expert in cryptography. I'm not, so please don't take any of this as advice on how to construct a password. It's advice on how not to, if anything.

</comment></comment><comment><USER27> This will never work for normal people.

For everyone else, there are programs like LastPass and 1Password that make this easy.

</comment><comment><USER28> I cry everytime I read these threads on HN. I've never seen such stubborness than people desperately convinced that they need to be able to memorize their passwords, or that password managers are the devil.

I'll say it again, just use a password manager. It generates random, complex passwords. It memorizes them for you. It pre-populates forms. They are locally encrypted and can be synced by themselves or with other tools. They can even be protected with two factor auth.

My _mother_ uses LastPass. So can you.

<comment><USER8> See all my other comments on this thread. Why does your mother use LastPass? How did she learn about it? How about the other 99% of the people? How do you _make_ them use LastPass?

This is not about us.

<comment><USER29> > Tell the user: your password must contain the following word: "hzru"

Enforcing this kind of thing on the masses won't make for stronger passwords, it will just have them opening up notepad.exe and saving this sites too-hard- to-remember-because-it-has-too-many-rules password on ~/Desktop/logins.txt

<comment><USER8> Now you'd have to prove that having passwords stored in a file is worse than massive password leaks. I suspect that it isn't. People already carry laptops with browsers that save passwords automatically. Losing your laptop already implies a password-change-fest.

<comment><USER30> Are you implying that browsers save passwords in cleartext? A quick search indicates that all major browsers encrypt passwords to user accounts, and some give the option of a master password as well.

<comment><USER31> They do encrypt passwords but that doesn't matter. You can still log in to their accounts and do anything you want. And if for some reason you really do want the actual passwords you can obtain those too, obviously they get decrypted to send to the website you're logging in to so just capture it at that point. Normal people don't configure master passwords.</comment></comment></comment></comment></comment></comment>


Unconventional Wisdom: Quitting is good for you - <AUTHOR> http://www.foundread.com/view/unconventional <comment><USER2> I dont want to hear advice from people who are successful only at writing and selling books that tell you how to be successful. including Dale Carnegie, Steven Covey etc.

I would rather hear it from those who have done - Marc Andreesen and others.

</comment><comment><USER3> That 'Dip' book looks like a perfect target for Squeezed Books in that it looks a bit fluffy. Still though, the concept is worthwhile.</comment>


RSS has been damaged by in-fighting among those who advocate for it (2006) - <AUTHOR> http://www.smashcompany.com/technology/rss-has-been-damaged-by-in-fighting-among-those-who-advocate-for-it

<comment><AUTHOR> Please note, this is why stuff like Twitter and Facebook do so well. Those of you who are surprised, or discouraged, when the public chooses a walled-garden like Twitter or Facebook, please remember how self-destructive some technologists have been, when promoting technologies that could server as decentralized alternatives to Twitter and Facebook.

In this particular story, the villain is Dave Winer, but at other times there have been other technologists who have undermined the very thing they were nominally promoting.</comment>


Understanding Convolution in Deep Learning - <AUTHOR> https://timdettmers.wordpress.com/2015/03/26/convolution-deep-learning/ <comment><USER2> It's nice to see basic signal processing [finally] entering machine learning. As an EE in the machine learning field, it hurts to read "sliding window" when you can do the same thing with a few FFTs.

The author mentions correlation, but doesn't properly give the intuition of what's happening:

> When we perform convolution of an image of a person with an upside image of > a face, then the result will be an image with one or multiple bright pixels > at the location where the face was matched with the person.

Well yea, but the best way to explain it is that when you flip the signal and convolve, you're getting the largest summation when the two align. Simple as that.

I'm sure we'll see the Circular Harmonic Transform for rotation invariant (up to a point) Deep Nets, and maybe even the Mellon Transform for scale invariant (again, up to a point) Deep Nets. <\- Note i haven't done the math per say showing that these will work, but i can't think of a reason they wouldn't.

<comment><USER3> > I'm sure we'll see the Circular Harmonic Transform for rotation invariant > (up to a point) Deep Nets

A fairly easy way to introduce rotation invariance in DCNNS is to perform random rotations on the inputs during training. Likewise for scale invariance. Translation invariance is already introduced by the convolution operation itself.

The thing about deep learning, is that transform kernels are _learned_ , not pre-computed as in classical signal processing. A DCNN will learn whatever convolution kernels it needs to perform the task at hand. I wouldn't be surprised if a DCNN trained on a classical signal processing task ended up rediscovering some well-known transform kernels originally derived from physical first principles...

<comment><USER4> > A fairly easy way to introduce rotation invariance in DCNNS is to perform > random rotations on the inputs during training. Likewise for scale > invariance.

It is a bit silly to call these invariances, as different filter/kernel combinations will be activated when a rotated or scaled input is encountered, the individual filters are not rotation or scale invariant. The entire network can only deal with rotations and scales it encountered during training, whilst having to learn 'redundant features' to a certain extent.

It will get the job done for many tasks, but it's a brute force sort of approach that will complicate the learning process (i.e. more scales and rotations require more filters, thus needing a more complex network that is harder to train).

I think there's definitely a lot that can be learnt from (classical) signal processing in order to come up with a much more elegant and efficient solution.

</comment></comment></comment><comment><USER5> I've been working on a project for matching template images myself for a couple months. I'm using a self made Java library to match static images with pixels on a user's screen. Mainly my project is about finding stuff that looks like static images, on a user's screen, fast ( i.e. <10ms ).

The post here is a really good resource, are there any Java libraries ( excluding OpenCV bindings ) that there exist for this kind of template matching?

<comment><USER2> Check out correlation filters - there's a ton out there - OTSDF, MMCF, MOSSE, ZACFs, etc. They're basically designed do template matching but in such a way that the input statistics are considered to refine the output result for better matching (less errors, improved separation between classes, etc). I don't know of any Java libraries, but here is a MATLAB library of different types ([https://github.com/vboddeti/CorrelationFilters](https://github.com/vboddeti/CorrelationFilters)) and here is a very basic implementation of OTSDF using C++ via the Eigen library ([https://github.com/jsmereka/PatchBasedCorrelation/tree/maste...](https://github.com/jsmereka/PatchBasedCorrelation/tree/master/Linux/ApplyFilters)).

</comment></comment><comment><USER6> I am an "average" ML researcher and an enthusiast, have worked on quite a few small/large works myself. Every time I see the kind of engineering complexity involved in stuff like deep learning - I wonder, how evolution could ever lead to general intelligence like human-intelligence OR if learning is a logical process at all</comment>


Ethically Aligned Design [pdf] - <AUTHOR> https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/ead1e.pdf <comment><USER2> Url changed from [https://ethicsinaction.ieee.org/](https://ethicsinaction.ieee.org/) to the actual document.

</comment><comment><USER3> Effectively implementing and enforcing these initiatives is one of most important issues, if not the single most important issue, of the next few decades.

Personally I've become very pessimistic that anything can be done before a true atrocity occurs.

There's no profit in ethics. Especially when the entities these ethics will govern will be themselves a means of controlling people's own knowledge and understanding of what is being done to them. Information control, targeted misinformation campaigns, misleading PR and lies, these will all be amplified in ways that the average consumer or voter won't stand a chance against. The power differential will expand so quickly that people won't even get the chance to protect themselves.

<comment><USER4> This is one of several reasons why tech labor needs to organize. For the right to practice their craft ethically.</comment></comment>


4 types of content a website acutually needs.  - <AUTHOR> https://www.distilled.net/blog/the-content-matrix/

<comment><USER2> A truly stellar example of blogspam.

Despite the title, the article tries very hard not to nail anything down concretely, and I paraphrase their conclusion as "you nead content". It lists essentially every type of web content imaginable and then pretends to have offered sage, expert advice.</comment>


Adobe on "HTML5" - <AUTHOR> http://blogs.adobe.com/jd/2009/06/adobe_on_html5.html <comment><USER2> _"This whole "HTML5" campaign will likely benefit Flash, because few remain who oppose the idea that "experience matters"_

Sadly for him, many people who back the idea that "experience matters" are _also_ against Flash, in all its nasty, proprietary, CPU-killing ways.

It has taken a long time, but Adobe's chickens are finally coming home to roost. Profits are way down this year, because customers are ignoring CS4, and in a recent conference call they admitted they've had to begin hiring R&D staff again, which must really stick in the craw of the marketers who took over.

It's amazing how often people forget the old "be nice on the way up the ladder" maxim. But then you get to enjoy the schadenfreude of watching them come down.

</comment><comment><USER3> That's some great spin there. The only good argument they have is that HTML5 will take a while. Compared to HTML5, Flash isn't so much better that it's worth sacrificing openness to use it. We'll have libraries that take care of the cross-browser differences. Sure, there will be problems along the way, but it'll be worth it to kill Flash.

<comment><USER4> "some great spin" is being put too mildly. Looks like they don't know what HTML5 is nor the state of its support in current browsers: pretty much all (but IE, of course) already have some support for it. Not sure how that makes minority of browsers, not to mention, that browsers on the new smartphones which are worth something are Webkit based—and that means support for HTML5. Apple specifically advertises HTML5 and CSS3 on its Safari webpage ( <http://www.apple.com/safari/what-is.html> ).

I completely fail to see how the release of iPhone "helped to radically increase the number of phones with Flash support". If it did help something this is to realize that we can do just fine without Flash.

So no, you don't need to wait ten years before HTML5 arrives, it is already on your doorstep (have you seen Google Wave?). There will be no wait, so "during that wait, Flash becomes more and more powerful" doesn't come to fruition. Adobe still cannot make Flash to run without hogging resources on anything but Windows, do they think I will buy this "more powerful" crap?

I don't think that HTML5 will kill Flash though, but if it forces Flash out of the places there it does not belong (full flash sites, flash navigation, etc.) Web will be a better place and I will be a lot happier.

<comment><USER5> Part of the anti-HTML5 crowd is more about simplicity and ease of tools. While you and I may understand HTML5 and it's underlying technologies (ECMA4, CSS3), it's confusing to developers who don't understand the reasoning behind certain features. Like the CSS vs. Tables argument, Flash seems easier to do glitzy effects, and have it supported by all browsers.

That said, I'm all for HTML5. Whenever YouTube officially supports the video tag, I'll me more than happy to uncheck that "Enable Plugins" on my browser preferences.

<comment><USER6> In case you haven't seen it, it looks like they're interested: <http://www.youtube.com/html5>

<comment><USER7> Important to remember that where Microsoft's strategy is to compete with flash via silverlight, Google's was just to build a new browser and create a better HTML by hiring all the people important in the process and throw its weight behind them.

So, yes, youtube is interested in HTML5 video, for the same reason google is interested in Chrome.

</comment></comment></comment></comment></comment><comment><USER8> I agree that it might be a while before the standard is final. And it will be even longer until all the non-HTML5 browsers are gone. But a decade? C'mon. All 5 major browsers should have a released browser with at least a few HTML 5 capabilities by the end of the year.

If your audience is targeted to newer browsers or if you're using a framework that can degrade gracefully, it shouldn't be long until you can start using this stuff on real sites. Some pretty popular sites (gmail) are already using this stuff.

</comment><comment><USER9> It's interesting to see PR in action, especially as Proggit, HN, and several popular blogs have been sounding the HTML5-induced death knell for Flash in the last week or so. Translating the double-speak is actually good fun in this case. With all due respect to Jon Gruber, here is the PR-to-Human translation of this link:

 _The current WhatWG proposals called "HTML 5" have been stirring up a lot of polarizing speech lately_

Positive attention to new technologies is only beneficial if Adobe has a clear monetization strategy for them. So we will introduce a controversy and try our best to make it "polarizing."

 _It's hard for Adobe to have an official opinion_

But unofficially, Adobe will do everything possible to undermine the excitement over HTML5 and torpedo it at all cost.

 _whatever this consortium of minority browser vendors chooses to do_

MINORITY. Get it? Unsupported! Unofficial! What happens if the minority goes away? Don't buy Tucker. Buy GM.

 _seeing what the final agreement turns out to be, and how it is eventually manifested in the world, both are prerequisites for practical tool-making_

Given that we are a tool vendor, this is the only interesting part. And since we largely control the tool market for our tech, this is a major threat to us.

 _Still, I'm glad that an analyst asked a question about it at the quarterly financial call. Here's what Adobe CEO Shantanu Narayen had to say_

What a threatened tool vendor CEO has to say is what you should use to form your opinion about a technology and its future viability.

 _I think the challenge for HTLM 5 will continue to be how do you get a consistent display of HTML 5 across browsers_

The biggest challenge for HTML5 will be the constant undermining from companies that see their current tool strategy and quasi-monopoly threatened, such as us.

 _And when you think about when the rollout plans that are currently being talked about, they feel like it might be a decade before HTML 5 sees standardization across the number of browsers that are going to be out there._

If we keep repeating the fear of how long it might take to implement again and again, it will take even longer. Your hesitation equals cold hard cash for us.

 _we still think that actually the fragmentation of browsers makes Flash even more important rather than less important_

When asked about a potential competitor, I always mention how its rise will make our product more important. Because that's what the board pays me to do.

 _Adobe's about communicating your ideas -- publishing to various channels -- not just about Flash. Dreamweaver, ColdFusion and the imaging tools all benefit from an increase in HTML._

Hey guys, remember ColdFusion? ... Guys?

 _Adobe profits from easing communication in general_

Positive communication about Adobe products. And sowing FUD about competitors. But since Slashdot posters ran the term 'FUD' into the ground ten years ago, you can't use it anymore without being derided. SCORE!

 _Flash is a strong bet for emerging platforms_

I'm high as a kite.

 _I'm increasingly uncomfortable with calling the WhatWG proposals "HTML 5" though_

Giving something that might become a standard the appearance of legitimacy is dangerous to our business model. Open standards are the enemy of our proprietary tools.

 _What counts is not a press release, but a realworld deliverable_

What is not deliverable, for instance, is Flash on iPhone and possibly many other portable devices, which appear to be the biggest growth market/land rush of the next decade. Allowing an open competitor like HTML5 to dominate that market would be fatal for us.

 _Shantanu's last point in there really resonates with me_

Please give me a raise.

 _this whole "HTML5" campaign will likely benefit Flash, because few remain who oppose the idea that "experience matters"_

Our experience in making cold hard cash from selling Flash tools matters the most. Using "scare quotes" will help de-legitimize HTML5.

 _Things are quite a bit different than five years ago._

We now have a virtual monopoly on serving casual video on the web. We will fight anything that threatens us.

 _iPhone helped to radically increase the number of phones with Flash support_

The new QuickTime X plays Flash videos natively. We might be screwed.

 _the "HTML5" publicity helps marginalize those few who still argue that images, animation, audio/video and rich interactivity have no place on the web_

HTML5 uses open standards to play those file formats natively, which severely undercuts our tool/server profits.

 _Flash will be able to deliver on those heightened expectations, regardless of what each separate browser engine does._

Fuck you, WHATWG, Chrome, Mozilla, Safari.

<comment><USER10> Firstly, I respect the idea of cutting through PR speak. I hate it as much as you do. That said, there are some things in your comment I think you're way off on.

 _MINORITY. Get it? Unsupported! Unofficial! What happens if the minority goes away? Don't buy Tucker. Buy GM._

The vendors with minority market share are really putting their weight behind this spec, and adopting features as quickly as they can. The majority browser vendor, Microsoft, is not. They have a conflict of interest now that Silverlight is out. MS has displayed reticence in cannibalizing functionality from their other products in the past; IE is unlikely to subsume Canvas and Video features since its the domain of Silverlight ( for the time being ). We have been in this situation before - how many of us have banged our head against the desk for hours fixing a "bug" for IE6? Though many web devs are brave enough to only support current gen browsers, many of us do not have that luxury. I love HTML 5, but I can't imagine any of the features to be "killer" enough to make users switch to more modern browsers. That said, I'm not big on prognostication, and if it turns out I'm wrong, I'll be a happy man.

 _What a threatened tool vendor CEO has to say is what you should use to form your opinion about a technology and its future viability._

100% agreed. But I also wouldn't discount that opinion just because it comes from someone in a weakened position. Every one of us is a geek, and every one of us has been in a seemingly losing position when we actually know we're right. I'm with you, about not trusting the source, but not on the idea that it invalidates the position of that source.

 _The biggest challenge for HTML5 will be the constant undermining from companies that see their current tool strategy and quasi-monopoly threatened, such as us._

This I have the biggest problem with, and I'll project onto it some other sentiments I've seen from HN and Redditors, just to make it interesting :) I'll posit this: a monopoly, kept in check with free and open source alternatives, is healthy for our web ecosystem. I'll go further: we would not have AJAX if Microsoft didn't invent it. It's a hell of a good idea, but maybe not good enough, alone, to force users to switch browsers. Since MS invented it, and since it had the dominant browser ( a quasi-monopoly ), and since it was a great feature, other browsers could implement it. We all benefited. If it came from Mozilla, web devs would have been bending over backward to not totally ruin the experience of their AJAXified apps for IE users, and no one would have bothered to switch browsers. I know that I'm picking on subtext from your comment, and that's what I'm most disagreeing with, but I wanted to share that opinion.

 _If we keep repeating the fear of how long it might take to implement again and again, it will take even longer. Your hesitation equals cold hard cash for us._

Everyone knows that HTML 5 will be faithfully implemented in at least FF/Webkit/Opera before long. But, for right now, IE is still the lynch pin. Adoption of HTML 5 features will occur as rapidly as they're introduced into IE ( if history holds true - I pray for some really feisty and ballsy web devs, but I'm not holding my breath ). This, obviously, sucks, but for the time being, Adobe is right - if we're going to wait for IE, and if IE remains the dominant browser, we're going to be waiting a while.

 _Flash is a strong bet for emerging platforms - I'm high as a kite_

How is this not accurate? I can reliably replicate any feature from HTML 5 in Flash today, and it'll work on any platform I want (* except all the platforms geeks get cranky about ;) ). Those features have been around for a while now. Flash's been a test bed for new ideas, and we all reap the benefits when it fails miserably ( intro movies = suck // never use a monolithic binary model for the web ) and when it succeeds spectacularly ( cross-platform, single- codec video player: <video>; audio player: <audio>; custom fonts; vector illustration <canvas>; animation [ more CSS3 ]; persistent local storage; etc ]).

_I'm increasingly uncomfortable with calling the WhatWG proposals "HTML 5" though_ I'm offput by this statement as well. I don't know why he's uncomfortable... It does seem like he's trivializing it.

 _Open standards are the enemy of our proprietary tools._

Again, I wouldn't count Adobe out on this one. The <video> tag isn't going to kill Adobe. Proprietary means Adobe can implement DRM. Yes. I know. WE ALL HATE THE FUCK OUT OF DRM. YouTube could thrive without DRM, but Hulu, for right now, could not. It is because Hulu offers protection on their videos ( Netflix, too ) that they're allowed to stream content to us. We could all "send a message" by torrenting those shows, cutting out Hulu/Netflix until they switch to <video> in lieu of Flash. But no one else will. Most people don't even understand what a plug-in is. They don't care that it has DRM attached. And frankly, me watching a few adverts so that the writers of The Office can buy a couple more ivory backscratchers is really not that bothersome for me. Again, Adobe implemented the first successful browser plug- in - they paved the way for <video> in the HTML 5 spec, so while we're chanting for its death, let's not forget that it's done _some_ good.

 _Fuck you, WHATWG, Chrome, Mozilla, Safari._

Now you're just projecting ;)

<comment><USER11> > _I love HTML 5, but I can't imagine any of the features to be "killer" > enough to make users switch to more modern browsers._

Funny you should say that. Users don't really care about features. What they care about is being able to view the content.

Flash is so popular today only because of services like YouTube. It only takes a YouTube to make HTML 5 popular, and speaking of YouTube, guess who owns it ;)

> _Adoption of HTML 5 features will occur as rapidly as they're introduced > into IE_

Complementary to the point above, Microsoft doesn't have any options but to implement it, otherwise they'll lose more market share.

Not to mention that plugins can be developed by third parties for IExplorer to add HTML 5 functionality. Google already started doing that with Gears.

<comment><USER10> Right on - they care about viewing the content. So if YouTube switched to <video>, over night, tons of users would switch browsers. Except that's never going to happen. My guess is that YouTube might serve up content using the <video> tag if the user isn't using a modern browser, and Flash content if they're using IE. I can't see them making such a reckless business move ( some users wouldn't/couldn't switch browsers, and there goes millions of paying customers ["paying" in that they view the ads]).

With companies like Google playing it conservative ( as all web devs do ), and adapting content to allow IE users to view it, there's not going to be an incentive for users to switch browsers.

</comment></comment></comment></comment><comment><USER12> His claim that it'll be 10 years until HTML5 works is absurd. Adobe makes some of the worst software in the software industry. _Great_ marketers though.

<comment><USER13> After working with Flash Lite for way too long, I gotta agree.

I'm still convinced it's all about <video>. All this clamoring for Flash on iPhone, Flash on Android, Flash on GE Ovens etc is all about people getting their video (cough cough PORN) on their handsets.

Give them H.264 and a <video>-tag enabled browser, throw in a little JQuery for animating menus and eye candy, and we'll leave Flash in the dust for good.

Javascript is the new bytecode.

</comment></comment><comment><USER14> _"HTML5" publicity helps marginalize those few who still argue that images, animation, audio/video and rich interactivity have no place on the web_

I don't understand what he means by this. I'm assuming he isn't articulating his thoughts well. For as long as I remember there were images, cheesy animations and background music on pages around the web - long before flash and shockwave.

Does he mean that some people argue Flash is bad for the web because it's contents can't be indexed by search engines? Now that is a different story and a losing arguement since Adobe itself has admitted it's an issue.

<comment><USER15> [ Original poster here ]

The stance that "images have no place on the Web" is the oldest of the lot, dating back to Netscape 2.0 days... it's hard to remember or even believe now, but people did rail against the IMG tag.

Back in the late 90s there was much argumentation that "things shouldn't move on webpages". This has died down as people have realized how motion can help clarify interfaces (iPhone's intertial drag helped lots), but we're still not at the point of universal acceptance that animation helps increase the total number of people who find the message accessible.

My point was that the arguments against richer interfaces have died down, as the browsers slowly advance to bring such abilities within reach. There will always be criticism of the leading edge, but Silverlight, iPhone, and "HTML5" have each helped convert camps away from the belief that only permissible medium is lengthy English text.

(SEO has had the gosh-darnedest amount of misinfo spread about... search engines have reached inside SWF for years and years, as the old Slashdot example query of "'contrary evidence' filetype:swf" showed. Start by visualizing the terms on which people will likely seek your services... research the competition you have for the first ten Google hits on the term... then optimize your pages for those terms in the usual way, as recommended by the search engines' guidelines. The "every little bit of dynamic text" fascination is starting to bite Ajax now too, so I have hope it will soon go away. ;-)

jd/adobe

<comment><USER14> Well thanks for clearing that up. I appreciate both of the comments of feedback. You are right about the IMG tag. I'm not old enough to remember if there was actually a community with positions or if Netscape was single- handedly deciding how HTML should look like.

</comment></comment></comment><comment><USER16> For me it's not even about _how_ the content is displayed (which is Adobe's concern), it's the user interface.

HTML 5 could present everything in mostly the same way, but still be an improvement because the browser would be aware of it all.

Problems that I see only in Flash:

\- Fixed-size text in a fixed-size box in the browser.

\- Text that can't be selected/copied/pasted.

\- Unnecessary customizations to video player interfaces.

\- "Navigation" that is completely unable to interact with the rest of my browser, e.g. can't figure out what URLs things go to, or how to go back.

\- Needing to go to Adobe's own web site to bring up Flash configuration panels to edit further redundancies like Flash's own cookie storage, etc.

</comment><comment><USER2> Hoo, the comments thread on this is still good. It's OK for Flash to suck, because sometimes other apps suck as well. _the Flash plugin on Windows is far more efficient and performs massively better than in the same page on Macintosh. [jd sez: I haven't tested that, but it's reasonable -- 3D and video tools are often claimed to work better on Windows too.]_ [http://blogs.adobe.com/jd/2009/06/adobe_on_html5.html#commen...](http://blogs.adobe.com/jd/2009/06/adobe_on_html5.html#comment-2005744)

</comment><comment><USER17> holding my finger in the dyke is hard, let's go shopping!</comment>


Simple Statistics, a JS library for doing statistics - <AUTHOR> http://macwright.org/simple-statistics/

<comment><USER2> The documentation for the classifier says:

"Create a bayesian classifier."

I think it should say

"Create a naive bayes classifier."

A "bayesian" classifier is a class of classifiers, not a particular algorithm. Naive bayes isn't (in most implementations) Bayesian! Finally you should specify what smoothing, if any, you use.

Hope that helps!

</comment><comment><USER3> This looks great. For large datasets does it handle the long running request issues that cause browsers to display a warning? If anyone uses this for processing a decent size amount of data I'd be interested in your opinion.

</comment><comment><USER4> It's a very nice idea, if you have time, you could aim to incorporate other modern tools: robust statistics (trimmed means etc.), effect sizes, confidence intervals

</comment><comment><USER5> This is interesting, but for the linear regressions I'd much rather get the a and b parameters than a function to interpolate/extrapolate y values.

<comment><USER6> Sounds doable! Created [https://github.com/tmcw/simple- statistics/issues/33](https://github.com/tmcw/simple-statistics/issues/33) \- I'll implement tomorrow.

<comment><USER5> thanks :)

</comment></comment></comment><comment><USER7> Recommendation: have the demos use web workers if they're available, so you don't tie up the main thread when the numbers get really large.

</comment><comment><USER8> Thank you. Great time saver for us all coding up these! Thanks again!

</comment><comment><USER9> This may be really helpful :) Thanks a bunch! Keith</comment>


In Defense of a Switch - <AUTHOR> https://pkolaczk.github.io/in-defense-of-switch/ <comment><USER2> This is known as the expression problem: [https://en.wikipedia.org/wiki/Expression_problem](https://en.wikipedia.org/wiki/Expression_problem)

<comment><USER3> I like Julia's solution to it : Multiple dispatch. It's great for code reuse and generic algorithms, but it kind of need the magic of the Julia compiler to make it shine.

JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski [https://www.youtube.com/watch?v=kc9HwsxE1OY](https://www.youtube.com/watch?v=kc9HwsxE1OY)

<comment><USER4> Julia's function polymorphism shines in a lot of cases, but in general it is less powerful than the OOP solution and also I find it much more difficult to read.

For example, I recently ran into this problem when prototyping a new Julia library. Without going too into the specifics, I can only match on a type of a object. With Scala say, I can override the method of an object at creation without actually defining a class.

In order to do a similar thing with Julia, I have to package the function as a field of the struct, I can't do multiple dispatch on it.

In general I think multiple dispatch is great for the incremental adding of new functionality without modifying the original source but bad at dynamically augmenting functionality at runtime.

A common example in Scala is creating an iterator. I can override the next and hasNext methods at object creation instead of creating a whole new class with a name. With Julia I would have to define a new kind of iterator at the top- level and then implement the necessary functions.

Let's say I want to have an iterator type of numbers in which I want to multiply or add constants to. In Scala I can easily return a new iterator that wraps the old one with overridden methods that adds or multiples by the constant. I could write

      val newIter = 2 + iter

Or whatever and with the right definition of +, everything would work correctly. In Julia I belive the only way to make this work would be to package the next and hasNext functions (or their Julia equivalents) inside the struct itself, which is unidiomatic I believe.

Also the amount of type-piracy can get a little annoying. A lot of libraries end up defining alternative dispatches that are inappropriate.

For Julia's problem domain, I do think this approach makes more sense than OOP and leads to saner scientific code. A lot of Python scientific computing libraries have these crazy baroque mutation heavy brain dead OOP interfaces that serve no purpose. It's just that in some cases, the packaging of data and functions together is really the only way to sanely solve a given problem.

<comment><USER5> >Julia's function polymorphism shines in a lot of cases, but in general it is less powerful than the OOP solution and also I find it much more difficult to read.

Given that OOP is single dispatch and multiple dispatch is a strict generalization, that's not just wrong or an opinion but it's a statement that can't be true. a.b(x) is equivalent to b(a,x) where b is a (possibly callbale struct) function you allow dispatching on a but not x. Multiple dispatch is the case where you can, well, dispatch on both.

>Without going too into the specifics, I can only match on a type of a object. With Scala say, I can override the method of an object at creation without actually defining a class.

You could also just drop to Val to dispatch on values or even define calls from the parameters like GeneralizedGenerated. That's pretty much the behavior you're trying to recreate so that would just do it directly. It's not the most common thing to do since you will hit dynamic dispatch, but of course if you're trying to dynamically add or change functions that's bound to happen.

>Also the amount of type-piracy can get a little annoying. A lot of libraries end up defining alternative dispatches that are inappropriate.

Interesting. Can you please make a list?

</comment></comment></comment></comment><comment><USER6> I think the main concept here is not the exact syntatic construct used, but the idea of removing the behaviour from the data structure, so implementors of new structures are not bound contractually to implement every behaviour.

In a way, the concept of monads attempts to solve this, since each specific data type would only need to implement its respective map/bind method, to be able to work for any other specific operation, since bind can be used to perform both transformation as well as reduction depending on the operation you give it.

(to purists, forgive my nomenclature, I am not a mathematician or fluent in FP lingo)

<comment><USER7> The misnamed _Visitor_ pattern does exactly this: decouple the operations on a polymorphic object structure from the implementation of the structure. It can be used in a way similar to FP-style pattern matching (although with more boilerplate), but is more flexible because the implementations accepting a Visitor are not coupled to the constructors of a data structure (e.g., a DAG object could accept a tree visitor, or vise versa). It would be interesting to have a language that provides convenient syntactic sugar for the visitor pattern.

EDIT: Just to clarify: The visitor pattern is usually presented in the context of "visiting" nodes in a recursive traversal. But the pattern is actually independent from the "traversal" use case. Its essence is really just the "switching", or case distinction, over an algebraic sum-like type (or over a type that provides a sum type view of itself).

<comment><USER8> Also strategy pattern. IMO many patterns are kinds of strategy. :p

</comment></comment></comment><comment><USER9> So, put's on low level hardware architect's hat, the low level method dispatch paradigm used for polymorphism is a really bad thing.

Something like "jsr *N(r)" which in RISC terms is "ld tmp, N(r);jalr (tmp)" is a real pipe-breaker - the load finishes near the end of the pipe while the jump has to be predicted at the beginning, but it can't be resolved until close to the end - this means that a mis-predicted branch (and indirect branches are harder and more expensive to predict) means that many many more instructions need to be discarded (could be 100+ on a high-end CPU).

Tests and branches suffer from mispredictions too, but they often can be resolved earlier in the pipe, discarding fewer instructions, and of course are more open to compiler optimisation.

<comment><USER10> Your comment was really interesting to read. Do you think you can unpack it a little more for someone like me who sits on top of a much higher level of abstraction?

<comment><USER9> I'm not sure how much deeper I can go ... in essence an x86 instruction like "jsr *N(r)" is really 4 micro ops: "ld tmp, N(r); st pc, (sp); sub sp, sp, 4; jmp (tmp)" \- in RISC-V its more like "ld tmp, N(r); jalr (tmp)" \- we can ignore the "st pc, (sp); sub sp, sp, 4" for the moment because they don't slow you from executing that first piece of code in the method you're calling, and it kind of lets us compare apples with apples.

So you need a memory fetch followed by an indirect jump, the results from the memory fetch come at the very end of the cpu's pipelines, if the CPU is simple it wont fetch the next instruction until it knows the value of tmp.

However any modern high end CPU is going to guess ('predict') the destination of the jump and start executing code from that predicted destination, if it guesses wrongly those instructions and their results will have to be discarded (a "pipe-flush"). There tend to be two sorts of predictors - for conditional branches and for indirect branches, the conditional ones tend to have a better hit rate, the indirect ones (this case) always fail on the first attempt and tend to be broken by things like a random mix of function pointers in vtables (to be fair the same can probably be said for using conditional branches in a similar situation)

In RISC-V the compiler can still schedule the "ld tmp, N(r)" earlier in the instruction stream, not so the x86. However if you use a conditional branch (an if statement rather than an indirect call) you can move those instructions earlier into the instruction stream and tolerate load delays and branches can be resolved earlier in the pipe (meaning a pipe flush flushes fewer instructions).

Modern speculative CPUs are very dynamic things, a lot of it designed to ameliorate those load delays, sometimes they are a couple of clocks (from an L1 cache) other times they are 100s (from dram) by finding other stuff to do in the mean time. That means that real-world performance measurement can be a bit mushy because there's so much going on at once

</comment></comment></comment><comment><USER11> > Branching scales well when we want to extend the program by adding functions > but it doesn't scale well when we want to add types.

In languages such as OCaml, when you add a constructor to an algebraic data type (which is the equivalent of adding a type here), the compiler will guide you towards the completeness of all the functions in your codebase that match over your type. So this burden is not on the programmer.

> Polymorphism scales well when we want to extend the program by adding types, > but it doesn't scale well when we want to add functions over these types.

In the same manner, you can add an abstract method to your base type to have the compiler force you to implement it in every types that you have defined and that extend it.

So I guess these are not real problems.

The author's two other conclusions are valid however. And I'll add that I believe good software engineering structure programs around data structures rather than functions. So I completely agree with them: long live the switch :).

<comment><USER12> > the compiler will guide you towards the completeness of all the functions in > your codebase that match over your type. So this burden is not on the > programmer.

That only works if all the functions you care about are in one codebase. If not, then the changes the article talks about become backwards incompatible changes in your library.

> So I guess these are not real problems.

If you're designing a library, the approach you take determines what types of additions are breaking changes and which are not.

<comment><USER11> I hadn't thought of that when writing my comment. You're right, thanks.

</comment></comment></comment><comment><USER13> My favorite part of redux is how reducers are really just big switch statements: [https://redux.js.org/introduction/getting-started#basic- exam...](https://redux.js.org/introduction/getting-started#basic-example)

<comment><USER14> Strictly speaking, nothing says a reducer even _has_ to have a switch statement. A reducer can use _any_ conditional logic it wants inside: `if`, `for`, `while`, lookup tables, etc.

It's just that the most obvious conditional construct for "checking multiple possible values of a single field" is a `switch` statement [0].

Having said that, we now officially teach our new Redux Toolkit package as the default way to write Redux code [1], and its `createSlice` API [2] does actually use a lookup table approach instead.

On a related note: my next task is rewriting that existing Redux "Basics/Advanced" tutorial to modernize it, and I'm currently taking notes on what I do and don't like about it [3]. If you've got any relevant feedback on things you don't like or ways to improve that tutorial sequence, please feel free to comment and let me know!

[0] [https://blog.isquaredsoftware.com/2017/05/idiomatic-redux- ta...](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux- part-2/#switch-statements)

[1] [https://redux.js.org/tutorials/essentials/part-1-overview- co...](https://redux.js.org/tutorials/essentials/part-1-overview-concepts)

[2] [https://redux-toolkit.js.org/api/createSlice](https://redux- toolkit.js.org/api/createSlice)

[3] [https://github.com/reduxjs/redux/issues/3855](https://github.com/reduxjs/redux/issues/3855)

</comment></comment><comment><USER15> This seems very close to a point an engineer made to me on a game. A case / switch statement was considered very ugly in optimized game code. But in terms of performance a polymorphic function was pretty much the same, it just looked cleaner.

<comment><USER16> It's a good point, because you remind us that domain matter so much. Outside of gaming and some other places, I don't think people would, for one second, care about the relative performance in this scenario.

<comment><USER15> And people care less in gaming every day. The part of the code that needs to be performant is often in an engine and thus untouched. And optimizing assets is often more important than optimizing code.

</comment></comment></comment><comment><USER17> > However, generally, branching offers the compiler more flexibility to > optimize because all the jump targets are known in advance. In case of > virtual dispatch, a static compiler may not know all the jump targets at the > time of compilation so generally such code is harder to optimize.

But those are precisely the cases where the behaviour of a switch may be _wrong_ (for example, if a different module adds another implementation of the interface that you don't know about). I'll take slow correct code over fast incorrect code any day.

<comment><AUTHOR> Adding a new value and not updating the switch properly will result in a compile time error in modern languages.

<comment><USER17> Only in cases where the compiler knows there is a "closed world" \- which are precisely the cases where the compiler can optimize a virtual function call. If it's an "open" situation where there might be other, unknown cases, the compiler will silently accept it.

<comment><AUTHOR> The same applies to abstract class / trait with a default implementation. The compiler would also silently accept if after adding a new behavior you forget to update the implementations which need a customized version of that behavior.

Also in the case described in the post, somehow the compiler didn't optimize the polymorphic case despite being able to see all implementations. I guess separate compilation of units makes the closed-world appear like an open-world to the compiler.

<comment><USER17> > The same applies to abstract class / trait with a default implementation.

If you deliberately choose to give a default implementation, yes. But you have the option of not giving a default implementation, forcing a compilation error if someone adds a new case and doesn't implement that behaviour. There's no way to achieve the same thing with a switch; if the switch is "closed" then in some languages a missing case is a warning or error, but I've never seen a language where an "open" switch won't be silently accepted and fail at runtime.

<comment><AUTHOR> But then you should compare a trait with no default method to a switch with no default case. And a switch with no default case would be reported as an error if some cases are not covered.

Also a switch with no default case is still open to extension. But the extensibility happens in a different dimension, as described in the article - the analogue of adding more implementations of an interface is adding more switches, not adding more case clauses. That's why a switch is _not_ a replacement for interfaces.

<comment><USER17> > And a switch with no default case would be reported as an error if some > cases are not covered.

In what language? It's not an error in Scala, which is what the post is talking about.

<comment><AUTHOR> In Scala or OCaml you get a compile-time warning + runtime error. In Java 14, Kotlin and Rust there is a compile-time error if switch/match expression is non-exhaustive.

<comment><USER17> You don't get a compile-time warning in Scala, only a runtime error. [https://scastie.scala-lang.org/6fGnDSzDSdmI4USN5k9OTA](https://scastie.scala- lang.org/6fGnDSzDSdmI4USN5k9OTA)

<comment><AUTHOR> If you're matching on a sealed type, you do get a warning.

<comment><USER17> Right - like I said, if it's "closed" you get a warning, but if it's "open" it's silently accepted and fails at runtime.

<comment><AUTHOR> The openness of match/switch over a sealed hierarchy is in another dimension - you can add more switches without changing old code. This is something that interfaces don't provide.

<comment><USER17> Visitor-style interfaces do provide that flexibility, though they're cumbersome.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> It kind of feels like cheating to make this argument by using Scala.

<comment><AUTHOR> How would Rust, Haskell or Kotlin be different? ;)

<comment><USER19> I think he means something like Java.

<comment><AUTHOR> Even in Java, you can always use a switch based on enums or even int constants. The only thing missing would be exhaustiveness checking, but the other claims about extensibility or readability made in the article still hold.

<comment><USER20> >The only thing missing would be exhaustiveness checking

Not if you're on a recent version of Java, switch expressions are exhaustive and they're a stable (non-preview) feature now as of Java 14.</comment></comment></comment></comment></comment>


Animated Map: Battle of Trafalgar - <AUTHOR> http://www.bbc.co.uk/history/interactive/animations/trafalgar/index_embed.shtml

<comment><USER2> I always wanted a top-down naval strategy game like this.</comment>