Life Is About to Get Harder for Websites Without HTTPS - <AUTHOR> https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/ <comment><USER3> I'm most worried about the "long tail" of often very interesting, useful, and rare content (a lot of it from a time when the Internet was far less commercialised) that is unlikely to be hosted on HTTPS, and whose owner may have even forgotten about or can't be bothered to do anything about, but still serves a purpose for visitors. The "not secure" will drive a lot of visitors away, and even lead to the death of many such sites.

Imagine someone who knew enough to set up a site on his own server a long time ago and had left it alone ever since. Maybe he'd considered turning it off a few times, but just couldn't be bothered to. Now he suddenly gets contacted by a bunch of people telling him his site is "not secure". Keep in mind that he and his visitors are largely not highly knowledgeable in exactly what that means, or what to do about it. It could push him over the edge.

...and then there's things like [http://www.homebrewcpu.com/](http://www.homebrewcpu.com/) which might never have existed if HTTPS was strongly enforced all along.

I understand the security motivation, but I disagree _very very strongly_ with these actions when it also means there's a high risk of destroying valuable and unique, maybe even irreplaceable content. In general, I think that security should not be the ultimate and only goal of society, contrary to what seems the popular notion today. It somewhat reminds me of [https://en.wikipedia.org/wiki/Slum_clearance](https://en.wikipedia.org/wiki/Slum_clearance) .

(I also oppose the increased centralisation of authority/control that CAs and enforced HTTPS will bring, but that's a rant for another time...)

<comment><USER4> Unfortunately, if the owner of the content is not interested in keeping this site up, the content will be lost sooner or later anyways. He probably also does not bother to install security updates and he will most likely stop paying the bills at some point (domain name, hosting server, etc).

Installing LetsEncrypt is not much work and he might be motivated if a lot of people ask him. If he is really not interested, it is probably best to archive the website to a real archive and hope they make sure they content remains available. Unfortunately this also means that the archive will no longer be found on google or most other search engines. It is really a shame that there is no work on google's side to make sure archived content can be found among other search results.

<comment><USER5> > Installing LetsEncrypt is not much work and he might be motivated if a lot > of people ask him.

Assuming he has direct access to his server of course. If he's on a shared host, he may not have the option to use LetsEncrypt, but may be forced to a buy a certificate from the hosting company.

<comment><USER4> Many hosting companies already give out free LetsEncrypt certificates with the ease of a checkbox. And those that don't will have plenty initiative to do so because their customers will spam their support saying that their website is not save anymore (and many will switch if the price for the certificate is unreasonable).

<comment><USER6> Vast majority of hosting companies don't offer LE.

</comment></comment></comment></comment></comment><comment><USER7> I hope lans are exluded? I'm scared that I will get security warnings everywhere in my lan.

\- when I log in to my webcams it says the connection is not secure

\- when I log in on my nas it says the connection is not secure

\- when I log in on my router it says the connection is not secure

\- when I log in on the web interface of mythtv it says the connection is not secure

\- when I log in on my self hosted gitea instance it says the connection is not secure

\- when I log in to my self hosted nextcloud it says the connection is not secure

\- when I log in to the configuration page of my toaster it says the connection is not secure

All these things are on my lan, and on most things there is no way to install a tls cert on them, nor would I want to do that.

Firefox already nags me that the connection is not secure when i enter a username and a password in any of those sites.

<comment><USER8> I'd hope LAN is included because while you use some services at home, most people will primarily use LAN services in public Wifis. It would be sensible to have HTTPS used there. They'd have to come up with a new idea of login pages (currently most systems MITM http requests) but otherwise it would make sense if you get a warning when you access pages on your hotel/in-flight Wifi without encryption.

<comment><USER7> > most people will primarily use LAN services in public Wifis

[citation needed] - I would say most people will primarily use LAN services in private home/corporate networks. But I don't have a citation either.

It's different use cases. Maybe one needs the warning, the other one not. But putting the warning on everything and overload the user with them is not the right solution.

Using a self signed CA is a pity, because installing it on every phone, tablet, laptop, tv, pc, ... is cumbersome in a home network, and making all hosts public and depending on an external CA for local resources to not get scary warnings can not be the right solution either.

<comment><USER8> > [citation needed] - I would say most people will primarily use LAN services > in private home/corporate networks. But I don't have a citation either.

Sorry I don't have a citation here. But looking at my coworkers and family, none of them uses services in their home LAN. Most won't even know how to access the router.

On the other hand it's very common to use Wifi in public transport (at least here in London for the tube), airports, trains and hotels. Few people consider security when using these hotspots, making sure that SSL is enabled for all pages would be an improvement.

<comment><USER9> > none of them uses services in their home LAN

They don't have printers? They don't connect to a NAT router before their cable modem? They never tether their computer to their phone? Their DVR doesn't have an app to control it? None of them have their receiver connected to their iTunes library?

<comment><USER10> While quite a few users will use services on their home lan, contrary to the parent posters statement, I believe the majority of users don't use those services via a web browser.

For instance (to draw from your examples): 1) Most people either install the printer drivers from the manufacture's web site, or let Windows/OSX auto- discover and auto configure the printer with out a web browser. 2) Most users just use the wifi information provided by the cable/DSL provider when they installed the modem, use the WPS button, or install the app that came with their router rather than use a web browser to configure it. 3) Most users will not tether their computer to their phone. 4) Most don't install a DVR app on their phone. If they did, their phone probably communicates with their DVR via some intermediate cloud service. 5) If their receiver auto-connects to their itunes library, it probably won't complain about that itunes not having a public certificate either.

</comment></comment></comment></comment></comment></comment><comment><USER11> Serious question: if I just run a simple blog with static HTML hosted with Apache, do I really need HTTPS? Will I be penalized by not having it?

<comment><USER12> 3% of routers in Canada and the US have some kind of malware in them, and almost all other countries are worse off. _You_ might not need HTTPS, but I need you to have it so I can trust downloading a PDF when I'm on your site. I need it so I don't get MITM by some shitty black hat tracking company. I need it so while I travel I don't have to worry about shitty governments tracking what I'm reading or watching.

And if your answer is "sure, but there will be other websites that are HTTP" my response is "yeah, but one day soon when enough of the web is secure I'm going to disallow all HTTP connections from my browser". And eventually I'll disallow all connections that aren't on HSTS preload lists. And eventually, hopefully, I'll disallow websites that don't have HPKP with long expires.

<comment><USER13> Then let me tell you it is quite easy to MITM by any company owning part of the connection.

Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS requests.

It was an in-house proxy taking advantage of Apache and IIS APIs for certificate management and SSL connections.

We used it for debugging secure connections, but I can easily envision other purposes.

Many years have passed since 2000, but I am quite sure it is still quite possible to do it.

<comment><USER14> I won't comment on how you built your proxy but HTTPS has come a long way since, eg TLS wasn't common back then and SSL has since been deprecated.

These days the only viable way to MITM HTTPS is to either attack the connection while it's in plain text HTTP (ie before the browser redirects to HTTPS:// (which is where the HSTS header comes in to play - it's cached by browsers telling them to default to HTTPS and never attempt a plain text connection) or to form your own HTTPS connection with your own CA signed certificate for the target site. Which would mean you'd either need to compromise a signing authority or have your own CA certs already installed on the victims PC (the latter is what some bad ISPs reportedly do when they inject ads).

Edit: I believe some corporate network proxies also work on the principal of having their own CA certs on their business workstations - so maybe this was how your proxy worked as well?

<comment><USER13> I can't disclose much, but can give a very basic idea regarding SSL.

That information eventually needs to be unpacked, so you get a replicate of the destination site with the same certificates, which you can easily download by pretending to be a browser, but running on your modified server, which then unwraps, repackages and then forwards the request to the original server.

Since one owns the server, it is also relatively easy to disable whatever validations the SSL algorithm requires at library level.

So I don't know TLS and since 2000 I don't mess with this kind of stuff, but I don't think similar approaches aren't possible.

<comment><USER15> You can't download the _private_ part of the TLS certificate by pretending to be a browser. You can't publicly download it _at all_. Your browser comes with a chain of _public_ certificates from reputable CA vendors, and you verify that a site is who it claims to be by using their _public_ certificate (which your browser downloads).

The only way they can succeed in proving who they are, is if their server has access to the corresponding private key of the certificate, which is why you can't spoof a properly secured site unless you either hack their server, crack the encryption, or install your phony certificate on the client (which is what corporations sometimes mandate). That's it.

It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).

If what you state is true, now in 2017, then there would have to be a huge conspiracy which involves all browser vendors (including Mozilla), as well as all national governments and the EU that hides this fact from the people. All software developers who do catch on (the relevant source code is open source after all) would have to bribed or threatened into silence too.

You are either misinformed or consciously spreading misinformation.

<comment><USER14> > _It 's been 17 years since 2000. Whatever security hole you may have used > (if any) has long since been patched. The weak cyphers used in some SSL > versions which you may have depended on are mostly gone (certainly from high > profile targets)._

I very much doubt he was even doing anything that clever. Since it was a corporate network he probably just had their corporate CA certificate already built as part of the company machine images / build scripts. He possibly might not even have been aware this was happening if the IT department was large enough that different coworkers managed the desktops from himself.

The " _I can 't disclose much_" argument on a 2 decade old hack is effectively just saying " _I can 't remember the details_" or " _I wasn 't directly involved in setting up the proxy_". Either way, while much has changed in the last 17 years, the practice of some businesses installing their own CA certificates on company assets has been a fairly standard way for corporate proxies to intercept HTTPS traffic. And a great deal less trouble than relying on SSL vulnerabilities since you already own and deploy the destination hardware+software anyway.

<comment><USER13> Anyone can easily find me on the net and I don't need to have fun speaking with lawyers.

Believe me or not, I don't care.

<comment><USER14> I don't really understand what lawyers have to do with the discussion but I certainly do believe you that you had an in-house proxy that did MITM HTTPS traffic. Lots of businesses do. The problem is you said _" let me tell you it is quite easy to MITM by any company owning part of the connection"_ using that as your example. While your anecdote may be true, the statement it is trying to support simply isn't true and neither was your description of how SSL works (eg the proxy server being able to disable the client libraries SSL checks).

So it's not that I don't believe your anecdote - I'm sure that did happen in some form or other - but the nature of the exploit either isn't how you described or is so old and long since patched that it hasn't been exploitable in more than a decade thus isn't relevant to the statement you were trying to support.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> HTTPS is pain in the neck and _currently_ I hate it from the bottom of my heart.

TLTR: if you have a commercial service or device running in a local network forget HTTPS and service workers, use HTTP and HTML5 appcache.

\-- RANT starts here --

It would be lovely when every website and webapp uses HTTPS. But for a significant amount of them it's just not f..... possible without driving _users_ completely insane.

If the HTTPS server doesn't (and never will) have a public domain forget about encryption and security, forget about using service workers. The following examples can't, by the love of god, ever provide HTTPS without completely f..cking up user experience due self signed certificates warnings:

1) internal corporation services, websites and webapps.

2) services that run in a local private network like on a Raspberry Pi.

3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services, like to a Philips hue bridge, or any other IoT device which is in the local network but only provides HTTP. These will enlight the users with a shiny mixed-content warning.

.... JUST use self-signed certificates, they said.

NO.

For normal users the UX of self-signed certificates is just non existent, it's a complete mess! It will scare the sh't out of users and will almost always look like your service is plain malware.

It _looks_ much more secure to serve a good'ol HTTP site with no encryption at all.

<comment><USER17> > 1) internal corporation services, websites and webapps

If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services?

2) services that run in a local private network like on a Raspberry Pi

Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech- savvy people.

3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services

I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting.

Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation.

 _edit: formatting_

<comment><USER16> > It's horrible how things like the Philips Hue bridge work and rely on > insecure HTTP to control your home lighting.

The Philips hue bridge REST API is accessible in the local network like [http://192.168.1.123/api/](http://192.168.1.123/api/) .... which is _great_ since apps/wepapps can talk to the bridge without a cloud or philips server inbetween.

And this is the very problem, it's _not_ possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge.

Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?

<comment><USER17> > it's not possible for Philips to add HTTPS support to the hue bridge without > some sort of cloud roundtrip to a Philips server

I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make.

> Because how could that be deployed without self-signed certificates and the > usual browser exceptions and warnings?

The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device.

The simple fact that you accept some insecure traffic, doesn't make it secure.

<comment><USER18> > > it's not possible for Philips to add HTTPS support to the hue bridge

> I don't see why not.

That's not a constructive argument. I don't see how they _could_ make it work?

Even if they somehow solve the problem of giving these devices domain names and even if they generate separate private key for each unit, the key and cert are going to be embedded in the firmware and a sufficiently sophisticated attacker will just extract them and become able to impersonate _some_ Philips device.

How the user of another device is going to tell whether he is connecting to his device or to malicious neighbor impersonating neighbor's device to establish Philips-signed HTTPS with the victim and then another connection to victim's device and MITM the victim?

You would have to make all users install a trusted certificate authority tied to their individual device. Which is a UX disaster in current browsers and also a security disaster, because if this becomes a norm, sooner or later somebody will sell you a toy device bundled with a CA crafted to give him the ability to impersonate any website. And you'll trust this CA because you want to play with the toy.

This _maybe_ could be made to work with some improvements in browser UI. Make it easier to add new roots of trust. Make it easier to learn and/or limit what websites these certs will be authorized to authenticate. But nothing like that exists now.

> The fact that your browser warns you about insecure communication happening > from that web page, that's a good thing. [...] The simple fact that you > accept some insecure traffic, doesn't make it secure.

True. As somebody pointed out elsewhere in this thread, this warning will become another EU cookie banner nothingburger.

<comment><USER17> > > > it's not possible for Philips to add HTTPS support to the hue bridge

> > I don't see why not.

> That's not a constructive argument. I don't see how they could make it work?

Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices.

If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist.

The original issue is that having a public website (used over TLS) that interacts with local network devices without TLS shows warnings about insecure communication. Again, the warning is shown because it /is/ insecure. There are plenty alternatives of securely interacting with an IOT device. Plain HTTP from a public website is just not one of them. For example, look at how Apple's Homekit has implemented that. Homekit is not usable from a public web page in a web browser. That's a good thing. (aside: I'm not a big fan of Homekit but their security is not bad)

So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers.

> sufficiently sophisticated attacker will just extract them and become able > to impersonate some Philips device

Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?)

<comment><USER16> > Missing from your quote: The alternative is freedom. Philips doesn't have to > lock their devices. > If Philips (and other companies, obviously this > doesn't relate to just Philips) would provide a community access to their > devices and software rather than locking them out, I believe that this > problem would not exist.

The problem is technical and won't be fixed by just opening the software.

> There are plenty alternatives of securely interacting with an IOT device.

Please name just one which works for webapps, beside HTTPS.

> So if vendors are annoyed with browser warnings, it's because /they/ are > doing the wrong thing, not the browsers.

Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms.

My whole rant is about browsers and HTTPS in non public networks.

For webapps which want to talk to IoT devices there is _only_ HTTPS and there is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS.

Here are some requirements: (actually real, I'm working on a IoT'ish product)

* webapp must be served via HTTPS, either from the IoT device or vendor site

* it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware)

* the webapp must work offline (service worker or appcache) without internet connection * webapp must be able to talk directly to the device, no cloud or vendor server inbetween

* the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet -- so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack)

To my knowledge it's technically not possible to build such a HTTPS secured _webapp_ in a local network today without breaking the mentioned requirements.

<comment><USER17> > The problem is technical and won't be fixed by just opening the software.

I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API.

> Homekit is nice but not available to webapps, apps of course can take > advantage of several security mechanisms.

That's why basically my point is to /not/ use a web app to control local insecure IOT devices.

> Please name just one which works for webapps, beside HTTPS.

Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC).

* update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2].

[1] [https://news.ycombinator.com/item?id=14751768](https://news.ycombinator.com/item?id=14751768)

[2] [https://blog.filippo.io/how-plex-is-doing-https-for-all- its-...](https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/)

<comment><USER18> > it would have had different protocols by now than just HTTP with a poor mans > JSON API.

Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use.

> Use locally resolvable DNS names and wildcard certificates signed by > commonly trusted (public) CAs. It's been done before (Plex does something > like this IIRC).

Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection.

And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Off-topic: If only IPv6 adaptation would have as much momentum as HTTPS.

<comment><USER20> I suspect the big reason it hasn't happened yet is it would require ISPs to replace tens of thousands of dollars of hardware and it would increase support requests in the short term ("site XYZ is broken but it's fixed when I turn of IPv6").

<comment><USER21> Is the hardware you're talking about the network equipment controlled by the ISP, or the routers and modems in customers' homes? I'd be surprised if the former hadn't been IPv6-ready for many years now, but I can imagine many customers are still using ancient hardware left over from when they first signed up for service.

<comment><USER22> If you have cable, a number of providers have been making customers upgrade to the newest modem. A single old modem that doesn't support docsis 3 will slow down everyone in your neighborhood.

<comment><USER23> Really? Interesting... can you elaborate/provide some reading?

I'm a software engineer with a smidge of basic networking experience so not completely clueless, but definitely inexperienced with DOCSIS and this sort of residential networking stuff.

</comment></comment></comment></comment></comment><comment><USER24> I wish people would stop equating "secure" with "HTTPS".

<comment><USER25> That's not what's done. "No HTTPS" is equated with "non secure".

<comment><USER24> He also claims that Quantas "secured their site" by adding HTTPS to their login page, and that serving sites over HTTPS is "secure by default"

<comment><USER26> This is true. I can intercept your username/password during login by being in close proximity to you if you are logging into their website over plaintext HTTP. Not possible if it is protected by TLS (HTTPS).

</comment></comment></comment></comment><comment><USER27> I hope they did some user testing to see how people _actually_ behave in the presence of such warnings but in my experience it does nothing. Worse, it's in an environment that is already rife with little messages in corners trying to get your attention (ads) so users may be more "blind" when browsing than usual.

The success of "Let's Encrypt" suggests that a key part of the problem wasn't a lack of user complaints about security. Rather, it was a lack of a sane model (both technically and economically) for setting up and _maintaining_ certificates. In the end, people maintaining sites already had 100 other things to worry about and weren't going to get around to HTTPS with anything less.

</comment><comment><USER28> With Cloudflare's first easy to use free SSL and later Lets Encrypt, I think it there are no more excuses for not being secure.

<comment><USER29> Cloudflare's free SSL is not secure.

<comment><USER30> is not? or was not? honest question. care to elaborate for a noob?

<comment><USER31> CloudFlare's "Flexible SSL" ([https://www.cloudflare.com/ssl/](https://www.cloudflare.com/ssl/)) offers encryption/authentication from CloudFlare's server to the client, but none from the origin server to CloudFlare's. Which means that is a vector by which the content could be sniffed or modified in transit.

It's a "better than nothing" option, as there are a slightly higher number of actively exploited attack vectors that apply to the client to CDN connection than the CDN to origin server, such as "free" wifi that injects ads, malicious ISP DNS, and the like. But it's not actually secure, as the origin server to CDN connection could be tampered with, and just because there are fewer active attacks that would be likely to affect that connection right now, doesn't mean that someone won't come along later and hijack such a connection.

CloudFlare offers other TLS options that do include encryption and authentication between the origin server and CDN, but they do require that you set up a certificate on your server, so if all you're trying to do is enable TLS (and don't care about the CDN), just installing a cert on the origin server and using TLS is probably a simpler option that using CloudFlare.

<comment><USER32> We encourage users to use Strict mode which requests and validates a certificate from the origin.

It's great that shared web hosting providers and others are starting to make it easy to acquire and install a certificate, but that hasn't always been the case.

EDIT: We also provide an API that will provision a free certificate for your origin: [https://blog.cloudflare.com/cloudflare-ca-encryption- origin/](https://blog.cloudflare.com/cloudflare-ca-encryption-origin/). The certificate is optimized for communication with our edge (essentially just as small a chain as possible, as we don't need the intermediate to walk to the root). Either that or use certbot from EFF/Let's Encrypt.

</comment></comment></comment></comment></comment><comment><USER33> How is a gateway serving a configuration page at 192.168.1.1 to internal users supposed to eventually get an HTTPS certificate for that address...?

<comment><USER34> It's not. It's supposed to use a publicly routable address. Private addresses were an unfortunate hack that got massively overused when people would've been much better off putting the same effort into using IPv6.

<comment><USER35> Down this path lies the IoT security apocalypse. Imagine every cheap, unupgradable IoT lightbulb with a publically routable IP address. If IPv6 was widely adopted tomorrow, I'd still run my home LAN services behind a NAT.

<comment><USER34> Addressability != access. By all means firewall your devices (though I'd strongly recommend something more granular than a perimeter firewall - particularly in the days of insecure IoT devices, an attack could easily be coming from inside the network), but they can still have proper addresses.

</comment></comment></comment></comment><comment><USER36> I deploy ssl on all my sites, but imo the article is way overestimating the importance of browser notifications.

<comment><USER37> Users are tuned to seeing green icon, and secure as trustworthy. This is over a decade of UX towards these. Suddenly seeing "Not secure" will definitely have an impact on engagement. (I know we're both guessing -- we'll have to wait for concrete numbers to make a call). I'd mark the engagement change at around 10%, and 20% for any site that is login/payments related.

<comment><USER38> they have been seeing that for months now ( i see it often too on sites that are slow to change). I have not heard anyone complaining about loss of traffic. It's becoming transparent to the users, imho, like the EU cookie prompt.

<comment><USER37> It's not red yet. It will look like this eventually.: [https://www.wordfence.com/wp-content/uploads/2017/01/blog- im...](https://www.wordfence.com/wp-content/uploads/2017/01/blog-image-2.png) , which will be a stronger negative signal.

</comment></comment></comment></comment><comment><USER39> How about a warning in Chrome that says "You're about to use _Chrome_ to visit this website, and thus send everything about yourself to Google to do whatever they want with", for _all_ websites staring in Chrome ~67?

</comment><comment><USER40> How hard is it to provide HTTPS these days?

Say you have a plain Debian 8 install, running a typical LAMP stack serving a single domain.

If you want to make it use a LetsEncrypt cert and serve the domain over HTTPS - what would be the minimum number of steps on the command line to make it do that?

<comment> ezequiel-garzon Something like (assuming you've reviewed the terms of service):

        apt install letsencrypt
        letsencrypt certonly -d example.com -d www.example.com -m email@example.com --agree-tos

And then add a weekly cron job with:

        letsencrypt renew

You need to stop your server for these actions, though I'm sure there are ways to avoid this.

<comment><USER40> There is no package "letsencrypt" in the repos of a standard Debian 8 installation.

<comment><USER41> It is "certbot" in Debian 9. Maybe 8 too.

</comment></comment></comment></comment><comment><USER42> I have been anticipating this but have had better things to spend my limited time on. I have more than 135 sites I need to convert to https and they are load balanced. I don't think letsencrypt handles load balanced sites yet. My management is against wildcard certs. This might push them over the edge in favor of wildcard certs.

<comment><USER43> You can have a single cert with all 135 sites' domain names in it. A wildcard cert may be preferable if the list of domain names frequently changes.

<comment><USER42> Thanks. I hadn't yet considered this.

</comment></comment></comment><comment><USER44> HTTPS gives your ISP less of your information to collect, analyze and sell to advertisers which in turn protects the value of Google's information about you. I think the changes to Chrome are well-intentioned, but can't help but smile at how this side-effect favors Google's business.

</comment><comment> gator-io Here's another take on how much of the web is HTTPS:

[https://truemarketshare.com/report?id=https](https://truemarketshare.com/report?id=https)

</comment><comment><USER45> Bleh. Wish I could use ssl on my GitHub pages site with custom domain.

<comment><USER46> I do exactly that with Cloudflare.

<comment><USER47> According to the comments above, it's not exactly secure

<comment><USER48> Please read [https://www.troyhunt.com/cloudflare-ssl-and-unhealthy- securi...](https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security- absolutism/) \- yes, it may not be 100% secure, but it almost never is in the real world anyway

<comment><USER34> It's more like some endpoints are 95% secure whereas cloudflare flexible ssl is 5% secure. Conflating those as "not 100%" is far more misleading than rounding them off to "secure" and "not secure". If [https://](https://) doesn't mean traffic is encrypted as it passes over the public internet then it means nothing, and that's what happens when you use cloudflare.

</comment></comment></comment></comment></comment><comment><USER49> what about self signed certificates? wouldn't it be great if these swebsites treated like http ones, without any security flags

<comment><USER50> Allowing transparent downgrades of self-signed certificates would be a big security hole. For example, suppose I add the following to my website:

      <script src="https://cdn.example.com/awesome.js">

By doing so, I am requiring the script to be served securely. If we allow self-signed certificates, anyone could generate a self-signed certificate for example.com and serve a malicious script to my users.

<comment><USER51> > Allowing transparent downgrades of self-signed certificates would be a big > security hole.

Automatically generated self-signed certificates should have replaced _all plaintext HTTP_ 15-20 years ago. The big security hole was allowing passive surveillance, ISP-level page injection vandalism[1]/attacks[2].

The web could have been almost completely protected from several _classes_ of attack a decade ago, but this _stupid_ insistence on conflating protection from 3rd part eavesdropping or corruption during transit with the _authentication_ of the server. These are entirely separate problems that do not need to be solved at the same time.

> I am requiring the script to be served securely

You're requiring it to be served over HTTPS, which doesn't necessarily mean "secure", because "secure" covers several different goals. You're also strongly trusting the PKI system. Do you trust all the certificate authorities your browser includes by default?

Of course, because HTTP _still exists_ , the initial request for the HTML that contains your <script> tag could be sent plaintext and thus modified during transit in many different ways.

> serve a malicious script to my users.

That can still happen without proper pinning, or if the local browser downgrades the request back to HTTP. Unfortunately this isn't particularly uncommon with corporate/school proxy, in-flight wi-fi services that forge certificates[3], and Superfish-style junk all removing _both_ the encryption _and_ the authentication provided by TLS.

Regarding your specific example about loading Javascript referenced in an HTML document's <script> tag, the solution is to validate the _data_ , not the _server_. The valid server can still send incorrect data. If you include hashes about a page's subresources[4], the browser can validate the integrity of the file it received.

[1] [https://arstechnica.com/tech-policy/2014/09/why-comcasts- jav...](https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript- ad-injections-threaten-security-net-neutrality/)

[2] [https://citizenlab.ca/2015/04/chinas-great- cannon/](https://citizenlab.ca/2015/04/chinas-great-cannon/)

[3] [https://arstechnica.com/information- technology/2016/02/why-y...](https://arstechnica.com/information- technology/2016/02/why-you-probably-shouldnt-be-doing-work-on-that-in-flight- wi-fi/)

[4] [https://www.w3.org/TR/SRI/](https://www.w3.org/TR/SRI/)

<comment><USER52> Of course, even with self signed certificates to replace plaintext http, ISP injecting/vandalism would be really easy. ISP would terminate the TLS, inject some annoying stuff, and then reencrypt with another auto generated certificate. Without the verification by public CAs, the client could never detect the MITMing.

<comment><USER51> > another auto generated certificate

The client can detect changing to a new certificate. Obviously self signed certificates have problems. The main point is that it _does_ protect against some attacks, and raises the complexity/cost. Running a MITM takes a lot more time, effort, and resources compared to simple deep packet inspection on plaintext packets.

> Without the verification by public CAs

While there isn't much support in current client software, verification doesn't have to be from a CA. In an ideal world, your bank (or whomever) could hand out some sort of dongle (or maybe as a QR (or similar) code on a card?) that had a certificate that could be used for direct verification of their internet services independent of any CA, or in combination with CA verification.

<comment><USER53> > The client can detect changing to a new certificate

Not if the client has never visited the site before and doesn't have a known- good self-signed certificate pinned locally to check against. And if the client did have such a certificate pinned, revocation by the legitimate owner of the self-signed certificate becomes impossible, since the client won't trust the new self-signed certificate being presented to it, without out-of- band communication of said intent to revoke and manual intervention on the client side.

> dongle

Again, the problem is certificate revocation. Physical dongles cannot easily be revoked. Corporate intranets deal with catastrophic compromise of their internal CA certificates by re-imaging all corporate machines with new certificates and restoring from off-site backups where needed - <USER2> that for customer machines is impossible.

PKI is like monitoring - it must rely on external services to be dependable and effective.

<comment><USER51> > never visited the site before

I already said that self signed certs are not going to solve every problem. They solve _some_ problems, which is better _plaintext_ HTTP that we should have retired over a decade ago. Obviously you should validate the server - probably through the usual PKI methods - whenever possible.

> revocation

Revocation would happen in the usual manner. The dongle is just a minor example of another way to provide validation. Obviously each methods will have their own benefits and limitations. I'm not saying we should replace PKI with physical dongles; I'm suggesting that alternative (non-PKI) methods are possible and they can not only coexist, they can also corroborate each other.

</comment></comment></comment></comment></comment></comment></comment><comment><USER54> Bit of a scare tactic. Page is an ad for Mr. Hunt's $299 course.

It's all true. However, I would make the case for Pat Q. Mainstream feeling less alarmed by "Not Secure" messages than most HN readers.

Note the Twitter example is from Mr. Hunt, not a random internet user.

<comment><USER55> It's his MO. Every article of his is decently researched with lots of fluff, always points to another article of his, and always ends in some kind of conversion goal.

<comment><USER56> True, but a man's gotta eat, and security is more and more critical these days. I don't begrudge him making a living while beating the drum of be-more- security-aware.

<comment><USER55> True. He's well off already though.

The article that seems to stick in my head is him spruiking a wifi extender he got for free so he can access wifi on his jetski at his jetty.

[https://www.troyhunt.com/how-i-finally-fixed-the-dodgy- wifi-...](https://www.troyhunt.com/how-i-finally-fixed-the-dodgy-wifi-on-my- jet-ski-with-ubiquitis-unifi-mesh/)

I can't bemoan how many times I've had poor wifi at my jetty ;)</comment></comment></comment></comment>


Q about Exercise 10.4 in "ANSI Common Lisp" - <AUTHOR>

I came up with the following solution for Exercise 4 in Chapter 10 of "ANSI Common Lisp" by Paul Graham:

  (defmacro ntimes (n &rest body)
    (let ((h (gensym)))
      `(let ((,h ,n))
         (if (> ,h 0)
            ,@body)
         (if (zerop ,h)
             nil
             (ntimes (1- ,h) ,@body)))))
 Using GNU CLISP 2.44, this works fine.  However, when I use SBCL 1.0.6 via Cusp v0.8.174 and do the following call:

  (ntimes 10
          (princ "."))
 I get the following error:
Control stack exhausted (no more space for function call frames).  This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away.
What exactly is going on here?  Is my solution correct and SBCL is wrong, or is my solution incorrect but it just happens to work on CLISP? <comment><USER2> You've written a recursive macro. That is usually a mistake. Here (unless you mean the first argument always to be a constant) you're recursing based on values that won't be available till runtime, yet the macro could be expanded at compile-time.

You should just expand into a do.

<comment><AUTHOR> I guess I'm not understanding the problem then, because I thought we were not supposed to expand into a do, since the problem states:

"Define ntimes (page 167) to expand into a (local) recursive function instead of a do."

Isn't the problem asking you to write this _without_ expanding into a do, or am I missing something here? What would be a correct solution to the problem?

<comment><USER2> Oops, didn't read the problem. Yes, as other commenters say, you should expand into a call to a recursive function, not an expression that gets expanded recursively.

If you were writing this for real you'd expand into a do, so this problem is somewhat artificially difficult.

<comment><USER3> > Oops, didn't read the problem.

You _wrote_ the problem. ;)

</comment></comment></comment></comment><comment><AUTHOR> Sorry about the non-pretty printing. It was nicely formatted, when I entered it (I swear). Is there something like a  tag I could use?

Also, not all of the error message printed. What's up with that?</comment>


Ask HN: Imagine: what if corporations ran cities? - <AUTHOR> 1. No more jobs. Like..Zero.  Everything is automated. 2. No income. Currency becomes obsolete. 3. No income. No taxes. 4. No govt exists. Only corporations.
What would the world be like? There are still people and there is still some version of 'currency' for transaction.
If there are no more jobs, what would happen to the economy and govt..as we know it?
What would be traded in exchange for the goods that automation produces? <comment><USER2> You're assuming several things beyond "corporations run cities". Why should that lead to no jobs? Is it still a corporation if nobody works for it? Or is it just some rich person controlling everything?

In "Basic Economics", Thomas Sowell defined economics as something like "the allocation of scarce resources that have alternate uses". There's still an "economy" even if there's no money. Just for a simple example, there are more people who want a beach house than there are beach houses. So who gets them? Right now, the one with the most money. Eliminate money, and there are still more people who want beach houses than there are beach houses. So who gets them? Maybe those furthest up the corporate ladder? (That's essentially how it worked in the Soviet Union.)

In the scenario you describe, I could see a barter economy quickly developing, and perhaps even turning into an alternate power structure to the corporations.

<comment><AUTHOR> What is the alternative to currency as we know it?

1\. What if we have a universal currency? How would that change world economy?

2\. What if there were multiple universal currencies? Example: housing currency..food currency..healthcare currency. Which means that you can't use food currency for healthcare currency etc?

3\. What if we had currency with an expiration date? It becomes investment currency once food currency expires.

Thoughts?

</comment></comment><comment><USER3> If corporations were in charge our cars would use leaded gasoline, construction would save with asbestos, sports would put tobacco advertising on everything, we would eat only carbs and sugar and cows that were fed the cheapest mixture of other cows and antibiotics, we would take subscription drugs since childhood, while everything we did would be monitored and sold to other companies for exploitation. The wealthiest cities would be exclusively for straight white males and their families but their white-only wives wouldn't have any rights and the children can only be medicated and obese. So far.

<comment><AUTHOR> No utopian vision?

<comment><USER3> History is full of organizations - churches, government and corporations - doing terrible things when they are unaccountable, to this day, so no. Most of that stuff actually happened in the past and into the present _and_ only stopped under duress, sometimes requiring decades of legal action just to do the right thing and stop spreading lies and propaganda and poisoning and killing people.

Today when corporate accountants deem a thing or place or persons unprofitable enough they just abandon their employees and employee-cities where they funded everything so it's all theirs and there's nothing to sustain the population when they go. Mines, plantations, manufacturing etc have done this for centuries.

[https://www.reuters.com/article/us-southkorea-hyundaitown- id...](https://www.reuters.com/article/us-southkorea-hyundaitown- idUSKBN1KX0UT)

<comment><AUTHOR> Why can't we change? Learn from the mistakes of the past?

I want to believe that we won't repeat ALL the egregious mistakes of our past.

<comment><USER3> The thing that's changing and that we've learned is that humanity _desperately needs_ transparency and accountability to stay benign... two recent examples include security cameras emerging for slaughterhouses and body cameras for first responders like police, both forced into necessity because unaccountable people with authority struggle to be decent.

Why do you prefer corporations over god-kings like Kim Jong Un?

What do you imagine corporations would be doing better than governments with gradually-enlarging oversight and transparency?

<comment><AUTHOR> I don't know if it will be better.

Corporations have to be run well to survive. There seems to be no accountability with government. What should happen for government to be efficient?

</comment></comment></comment></comment></comment></comment><comment><USER4> How would jobs disappear?

See:

[https://en.wikipedia.org/wiki/Company_town](https://en.wikipedia.org/wiki/Company_town)

In the worst cases company town allowed only company shop in company town. Workers worked for a company, lived in company housing and bought everything from company shop.

<comment><AUTHOR> Interesting. I was actually thinking of eco-villages and communes first. But these from the hippee era and collectivist ethos have only had minimal success. What if it was replaced by corporate principles in which the city or town ITSELF is the corporation?

</comment></comment><comment><USER5> No privacy whatsoever.

You get streamed advertising all day long.</comment>


Hydra 1.0 is released - <AUTHOR> https://hydra.cc/blog/2020/09/03/Hydra_1.0 <comment><AUTHOR> New features includes config type safety, more powerful command line interface, new plugins for launching remotely and to perform hyper parameter optimization and more.

Check the blog post for more details.</comment>


Snap responds to the 1.2M petition signers who hate the redesign - <AUTHOR> https://www.theverge.com/2018/2/21/17037100/snapchat-update-redesign-petition-response <comment><USER2> The persistent narrative is that people hate change but eventually they get used to it, and look at this data which shows improved metrics.

Except for the catastrophic failure of Digg v4, there's a general refusal to believe that change can ever be for the worse. As long as people continue to use a service, however begrudgingly, everything is great. Subjectively, I see more and more irritation from normal (non-nerd) people at non-chronological displays. People like _control_ and certainty about the information they're seeing, and clever algorithms take that away.

<comment><USER3> As long as the functionality is there, there will be initial outrage and then people will accept it. Having gone through a few redesigns of a major website, the first few weeks can be a nightmare though. People love to complain. But in the people's defense, we've had a few screw ups too.</comment></comment>


Former Wirecard CEO Markus Braun arrested - <AUTHOR> https://www.dw.com/en/former-wirecard-ceo-markus-braun-arrested/a-53905720 <comment><USER2> I was just listening to a podcast last night, in which a financial analyst who identified problems with Wirecard was harrassed for years, both online and IRL. Interesting story: [https://www.npr.org/transcripts/868001948](https://www.npr.org/transcripts/868001948)

<comment><USER3> What's really interesting is seeing the _same_ people sound the _same_ alarms about extremely popular companies that continue to trade _today_ , and yet our regulators, auditors, and journalists all ignore them.

We really never learn. If I were a regulator I would be taking short seller statements extremely seriously when it comes from one of the proven reliable ones.

<comment><USER4> Though I can't speak for regulators and auditors, you have to keep in mind that 99% of journalists are just hired guns who's sights are specified ahead of time.

Since no one with power had their sights on Wirecard, nothing happened - it's not unexpected.

<comment><USER5> John Carreyrou managed to take down Theranos despite the fact that Elizabeth Holmes appealed directly to the owner of his paper, who sat on her board.

</comment></comment></comment></comment><comment><USER6> it baffles me that it had to come this far. There were warning signs all over it.

The German BaFin messed up so badly that one must either fundamentally doubt theircompetence or question their integrity.

<comment><USER7> At least BaFin boss Felix Hufeld admitted they messed up and that the whole thing was the biggest debacle he ever witnessed.

This is rare, and I find it respectable. But yeah, how they missed that is hard to comprehend.

<comment><USER8> > But yeah, how they missed that is hard to comprehend.

Look at the German DAX and what is in there. That is explanation enough. Heavy industry, consumer goods, banks, insurances. The only IT company other than Wirecard is SAP and it is not exactly known for innovation.

Everyone, especially politics, wanted Wirecard to succeed: the only actually somewhat innovative IT company in the DAX. It's the same pattern with the car industry scandals (not just Dieselgate but also the Porsche attempted takeover) or with Bayer/Monsanto.

Germany doesn't have many "unicorns" so politics will protect them until way too late, for the companies, for the share/stakeholders and the planet.

<comment><USER9> > Germany doesn't have many "unicorns" so politics will protect them until way > too late, for the companies, for the share/stakeholders and the planet.

Interesting. Is there a strong feeling of innovation/unicorn envy among the wider business culture in Germany? Is it a fear of being stale, comparisons to Silicon Valley & Asian tech scene, or something else? I'm curious if you have more insight on this?

<comment><USER8> > Is there a strong feeling of innovation/unicorn envy among the wider > business culture in Germany?

Everyone wants to be like the SV hipsters, no one can because the higher-ups are still mentally and literally stuck in fax times, there is almost no venture capital (and the venture capital that _is_ here gets invested into stuff like Rocket Internet whose "business model" is to copycat US ideas), banks (across the EU) won't dish out dumb money because unlike the US we have public funded pension systems and not capital-based ones and we have strict loan regulations (Basel framework).

> Is it a fear of being stale

Culturally, us Germans are known for being extremely risk-averse, bankruptcies are socially shamed. This of course clashes with the US way of life that from the bottom to the top embodies "fail fast", and the youth yearns for change but as explained above that's hard to do.

<comment><USER10> May I also additionally ask how on Earth a 50k salary for a software engineer is at all justified? After paying taxes and rent, it seems to me there is not much money left over for saving or lifestyle spending?

It seems like an unfair situation

<comment><USER11> Why is it unfair? No-one is forcing anyone to accept development work for 50k per year, yet there are plenty of people happy to do it.

<comment><USER10> Define plenty? It seems to me the other commenters have offered counter points to you.

In the US, before taxes, an income of $130,000 to $170,000 is the norm in bigger cities. I imagine based on my calculations that the difference between Berlin's discretionary income for SWE and NY/SF/SEA/BOS is probably an extra $50,000 post tax.

<comment><USER12> And what do you think do houses cost in Germany, compared to "bigger cities" in America?

I know plenty of people in that income range myself who do own houses (or apartments in some cases) and wouldn't think of forgoing their summer vacation in Menorca or Ibiza.

"The other commenters" is just one, and he's factually wrong. No matter how much HNers love to pile on, 50k Euros is a respectable income in most parts of Germany.

The idea that all software engineering is in Stuttgart, Munich or Berlin is laughable. We have lots and lots of family companies of the so-called "Mittelstand" strewn across the province (but West Germany primarily). Some of those are hidden champions. In towns and regions few Americans will ever have heard of.

<comment><USER10> I've heard of plenty of American and also German towns and cities and even if I was living for free in a caravan (which I've done for many months in my life, much like Germans who go to music festivals will do in the summer), I don't see how it is possible to make a substantial savings in life on a yearly post tax income of $25,000.

After an entire decade of working, this will only result in a best case scenario of $250,000 in savings, which, for my personal lifestyle is not going to work. I think collective action for higher wages is proper here.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> The same people with large shorts in Wirecard like Chanos also have large shorts in Tesla. Just saying.

<comment><USER14> Chanos, the guy sitting on a bearish call against Tesla in November. The stock is up 200% since then. If Chanos were really betting to match his propaganda, he'd never work again after being destroyed like that.

<comment><USER13> Wirecard has been at highs too. That's the point.

If you have high conviction something is wrong then it doesn't matter that it works the wrong way in the meantime.

</comment></comment></comment><comment><USER15> Recent threads:

[https://news.ycombinator.com/item?id=23573386](https://news.ycombinator.com/item?id=23573386)

[https://news.ycombinator.com/item?id=23598824](https://news.ycombinator.com/item?id=23598824)

[https://news.ycombinator.com/item?id=23438323](https://news.ycombinator.com/item?id=23438323)

This, from a year ago, reads interestingly now: [https://news.ycombinator.com/item?id=19737344](https://news.ycombinator.com/item?id=19737344)

</comment><comment><USER16> I am coming way late to this story.

Is there a good backgrounder on this whole thing?

<comment><USER17> I'd recommend this HN post [0] which links to a good background story [1]. It literally starts with "For those who just came back from a 15 year space mission: Wirecard is a German company that..." haha.

[0] [https://news.ycombinator.com/item?id=23598824](https://news.ycombinator.com/item?id=23598824)

[1] [https://valueandopportunity.com/2020/06/19/wirecard-the- germ...](https://valueandopportunity.com/2020/06/19/wirecard-the-german-enron- a-very-personal-history-2008-2020/)

<comment><USER18> As an anecdotal datapoint, I've never heard of Wirecard until the past few days. Although I'm American and not in finance.

</comment></comment></comment><comment><USER19> And yet the stock went up 18% this morning. It's really baffling.

</comment><comment><USER20> Allegedly he will be released on 5 million Euro bail at 5 pm CET.

</comment><comment><USER21> So did the steal the money like Nissan's ex-CEO or just spent over a decade lying about the company's financials? The latter seems incredibly retarded; To what end? It's a job.

<comment><USER22> The latter. Basically the missing $2b of cash equals the sum total of all the net income the company claimed to have earned over its entire history (which was the basis for its $27b market cap at its peak). As for why, who knows, they probably would have gone under during the financial crisis in 2008 and lost their jobs if they hadn't cooked the books. Then once you start doing that you're on a treadmill to keep it going, similar to the Madoff fraud. And in the meantime, the CEO gets to be the big man of the German tech scene and enjoy the perks of being a billionaire on paper. It must have been pretty stressful though, that's for sure! These kind of people have some way of compartmentalizing things so they can function on a day to day basis.

<comment><USER23> In 2020, I'd be willing to short any company whose CEO sports a black turtleneck.</comment></comment></comment>


Ask HN: Why is Bluetooth so unreliable? - <AUTHOR> After all these years and consecutive versions, Bluetooth in my experience is still a hugely unreliable experience.
I constantly have to forget  devices, turn them off and on again etc. I have regular drop outs and I'm forever trying to re-pair.
This is across connection types (keyboard, music etc), brands and devices.
Why is Bluetooth in general so flakey? <comment><USER2> You get flakey Bluetooth when the two implementations on the two devices differ significantly, or when it is poorly implemented.

... Which is made clearer by the fact that the Bluetooth specification is:

\+ Enormous. Even just the core spec, that doesn't include much of what the consumer is interested in, is around 3000 pages long. That's not a typo. 3000 pages to tell you how to make two devices do a handshake. Add in the things that make our devices actually work... And you're asking the software to match what has been written and defined across closer to 5000 pages. Nothing is going to perfectly match between implementations.

\+ Badly defined. The original working group that made Bluetooth left behind so much because they couldn't agree on it that it has more "Undefined Behaviour" footguns than C ever did.

One example of some spec text that I've seen argued differently between implementations:

> There is no requirement for the application to insert additional framing > information into the data, although it may do so if this is required

That's before we get to the actual real world problems that Bluetooth has to face and overcome, like being in the 2.4Ghz range and being a frequency hopper.

<comment><USER3> Good reply...but the real question is why has nobody stepped up to replace it? Close quarter communication is only becoming more prevalent, why do we live with a broken standard?

<comment><USER4> What about Zigbee?

[https://zigbeealliance.org/](https://zigbeealliance.org/)

<comment><USER5> Zigbee is more of a competitor for Bluetooth Low Energy, which is quite a bit more modern, sane and reliable than Bluetooth Classic.

It never really had much of a chance though because BLE support was sort of added to phones for free as part of Bluetooth. With Zigbee (or ANT or Thread) you'd have to add a new chip, which phone manufacturers aren't going to bother with for a tiny market (though I think there are a very small number of phones with ANT support).

</comment></comment></comment></comment><comment><USER6> I was the developer responsible for the bluetooth integration of a "smart lock" in an android app and it was an absolute nightmare.

I don't know if manufacturers have got their shit together in more recent smartphone generations, but at the time every manufacturer had their own Bluetooth stack with undocumented, and sometimes conflicting, quirks. Manufacturer A requires that you pair to a device before connecting? Great, Manufacturer B won't pair unless you connect first.

The only way we could guarantee compatibility with the app was that we tested at least one phone from every manufacturer so could flag which workarounds had to be used for each device. Some manufacturers were at least consistent with themselves, but others had totally different stacks between devices and even android versions.

This was definitely a huge point in Apple's favour; iOS' Bluetooth was snappy and consistent, and I was forever jealous of our iOS dev doing the integration over a few days when it took me at least a month to work all the links out.

And then a manufacturer releases a new hot android phone and we get a complaint from our client that their app is suddenly awful because it didn't work out of the box.

No, I'm not salty at all. :/

<comment><USER5> I had exactly the same experience. Android's Bluetooth stack is shockingly bad. They even changed implementation once (from the standard Linux Bluez stack to some other one). Just as bad, if not worse.

One example: Until very recently the default connection timeout was 20 seconds. There was no way to change it. 20 seconds! Such a shockingly bad user experience. The default on iOS is something like 0.7 seconds.

Several years after reporting this issue they "fixed" it - by changing the hard-coded timeout to 5 seconds. Like, yeah that's better I guess, but I think you're missing the point.

Just in general Android's bluetooth stack was way buggier and less reliable than iOS's. There were entire classes of products (mostly proximity-based stuff) that we tried to make that worked perfectly on iOS but were effectively impossible on Android because it was so janky.

</comment></comment><comment><USER7> I don't know the reasons To this. But I but would comment that when it comes to bluetooth, once again Apple has shown that they "get it" with airpods, the major feature To me is simply that they remove most of the incredibly annoying issues with Bluetooth that other products just seem to not even notice.

I have had other bluetooth headphones where sitting down at the computer means I first have to go find my phone and disable Bluetooth to use them with my computer. Where I have to go through the menus to connect them every single time For every device. But AirPods "just work". Sit at my computer? They connect straight away no action from me, just my magic when I put them in. Walking around with my phone? They just connect (and show battery status) just when I put them in. It's simple and effortless. That couldn't have been an easy feat considering everyone else on the market are failing at this and have been failing at this for pretty much every Bluetooth device for more than a decade.

<comment><USER8> I'm on my 2nd set of "2nd gen" (not the noise cancelling ones tho) airpods.

IMO they work great when new but slowly as you add devices, or whatever, they get worse and worse. And since there are no buttons, if it decides to just connect to one airpod, you're screwed until you can throw them back in the case to 'reset' them or whatever. Once you take an airpod out of its case, it either seems to connect properly, or not, but if not, it's game over.

I took my airpods out the other day for a run. they must have connected to my computer because my phone refused to connect to them.

Doesn't matter how many miles i run from my computer, but they will never connect to my phone until i can put them back in their case and take them out again.

Finally reset the whole thing and they SEEM okay.. I'm intending to maybe just keep my old airpods (<1h battery life) for conference calls, and the new ones for running.

But anyway, far from perfect.

</comment></comment><comment><USER9> Broadcom bluetooth/wifi chips ran out of firmware hot patch ram slots long time ago. Company seems to be too cheap to respin the rom mask with all the fixes baked in. From what I remember even brand new iphone x ships with no room for BT firmware patching.

RECON 2019 - Reversing and Exploiting Broadcom Bluetooth (Jiska, Dennis Mantz) [https://www.youtube.com/watch?v=96Mi8_9ABCc](https://www.youtube.com/watch?v=96Mi8_9ABCc)

35C3 - Dissecting Broadcom Bluetooth (jiska mantz) [https://www.youtube.com/watch?v=4_nI9ok7iQg](https://www.youtube.com/watch?v=4_nI9ok7iQg)

</comment><comment><USER10> 1\. The quality of service for RF vs a wire sucks big phat donkey balls.

2\. For low power devices like Bluetooth, even worse than that.

3\. Bluetooth is a frequency hopper. Frequency hoppers have all sorts of synchronization problems. That plays havoc with link maintenance algorithms.

3b. Distributed link maintenance with no central control is a hard problem.

4\. The people that designed the original spec didn't know what they were doing.

5\. The baseband spec is very complicated. And thus hard to get right on all cases. And there are multiple layers each with a different party responsible for implementation.

6\. Bluetooth devices are designed by groups working for a large number of manufacturers none of whom have license to help each other.

Items 1-3 explains why Ethernet tends to just work and Wifi/Bluetooth kinda sucks.

Item 4 explains why Wifi works better than Bluetooth.

Items 5-6 explains why your cell phone generally just works even though it uses RF.

<comment><USER11> #4 makes me laugh because I had that thought when I was trying to work with bluetooth. I think the real problem is two-fold. The original spec required approval from all members of the consortium. I think a lot of things were left out that are really important, such as security. I know they had security from the start, but really, it's bullshit. Plus the original chipsets were incredibly expensive, and my pure speculative thought is that they cut corners (the firmware part) to bring them out to market. I was really surprised, shouldn't have been with hindsight, to see when bluetooth chipsets started to reach price parity with wifi chipsets.

The second thing is that much of the low level firmware for the stack is closed source stuff that is written in house. I suspect, after working with some of that shit, that it's poorly done and is a major cause of unreliability. Don't know if it would make any difference if it was open sourced, because the hardware/software combo is a lot like what you see with graphics cards. Everyone has their own secret sauce and they don't want to show it to the world.

<comment><USER12> I remember watching a tech news report on cable TV (yeah, that long ago) about a hot new tech called 'Bluetooth' that was going to revolutionize device interoperability, and the BT chipset would be at most $5 of the device cost.... until that never happened.

<comment><USER13> It actually did, charmingly. usually I just click upvote on these but it was stunning to read one and think "wait...that is exactly what happened, even if its not perfect"

<comment><USER12> Yeah, but how long did it take to truly drop to the $5 mark? When bluetooth stuff came out (mice, keyboards, etc.) they were exorbitantly expensive. It was way cheaper for manufacturers to sell stuff with their own RF dongles instead of using BT.

<comment><USER14> I recall buying a USB Bluetooth adapter in the mid 2000's that was maybe $12 shipped from Asia. If that was a the cost to the consumer for a device that was mostly a bluetooth radio I suspect that the cost to add bluetooth to a high volume product was probably at or below $5 ~15 years ago.

</comment></comment></comment></comment></comment></comment><comment><USER15> Well for a multitude of reasons....

First it's on the 2.4 GHz band...which is quite busy as a significant number of devices, and protocols use that band including WiFi, Microwave ovens, baby monitors, and etc. The Bluetooth spec as done a lot to mitigate this in the spec but the issue persists.

Second there is an security element that was kinda added on later but was also built in and was optional.... this causes an untold amount of issues (aka vulnerabilities) and is probably what your experiencing with the paring issues.

Lastly the protocol stack implemented almost everything from audio to serial to TCP/IP...which is probably why it's so ubiquitous and is implemented weirdly because there is multiple ways to do it...see the number of Bluetooth codecs.

</comment><comment><USER16> Even the icon makes me irrationally angry.

Like it's telling me, "yeah, I'm working now, but I'm going to hurt you one day and there is nothing you can do about it."

</comment><comment><USER17> IME it's all down to the implementation these days, which is a low-bidder- gets-what-they-pay-for kind of affair. My phone is cheap and the Bluetooth is nearly unusable on it(it can only really support one device at a time and that device will periodically drop out), but on my laptops, which have more of an emphasis on build quality, it's pretty solid, with few to occasional instances of audio tearing.

Regardless I still find grief from things like the volume resetting on one or both ends after pairing. There is a lot of attention to detail needed to get this stuff right, and most companies can barely manage to ship - that's not on the standard of the spec but the standard of the marketplace.

<comment><USER18> > IME it's all down to the implementation these days, which is a low-bidder- > gets-what-they-pay-for kind of affair.

Then why does wireless not have these exact same issues?

<comment><USER19> what do you mean by wireless?

<comment><USER18> Wi-Fi.

It works ok on most devices.

If Bluetooth being crap was about cheapest solutions, I'd expect to see this problem on Wi-fi, which in practice generally works.

<comment><USER20> WiFi isn't much better in my experience. When I take my phone out of Flight Mode, the 4G LTE data connection is established in a fraction of a second whereas the WiFi can take 10 seconds or more. To a known router that is five metrea away.

</comment></comment></comment></comment></comment><comment><USER21> I hate Bluetooth also but I did think of a use case where it could be great:

If you had a honeypot accessible only by Bluetooth, you could pass off delays and dropped service for quite a while before the attackers figured out that it wasn't BT just being BT. :-)

</comment><comment><USER22> This [episode of Android Studio Backstage]([https://androidbackstage.blogspot.com/2018/08/episode-97-blu...](https://androidbackstage.blogspot.com/2018/08/episode-97-bluetooth.html?m=1)) has a lot of fun details about the Android Bluetooth stack and all the problems they have faced with it.

</comment><comment><USER23> Two months ago I replaced my Macbook Pro and PC plus tens of wires set up with a cheese grater Mac Pro with most Bluetooth devices.

I was burnt by Bluetooth several times, but I really hate wires so I keep coming back. And then keep getting burned.

And it burns me more this time. I found the new generation of Bluetooth headphones like the Airpod Pro and Sennheiser Momentum wireless 3 tried to maintain multiple connections simultaneously, but they really have no idea which one to switch to most of the time. It's literally a nightmare.

I really like the wireless concept, could anyone enlighten me why cannot the industry come up and adopt a better standard?

</comment><comment><USER24> My current bluetooth headset and mobile phone seem to have a directional antenna issue. I can get drop outs on my headset if the phone is laying flat and I'm 2 meters elevated above it and less than 4 meters away.

to me thats seems directional signal type issues.

I've also notice that my headset sitting around my neck will disconnect if my phone is in my pocket when my wife gives me a hug. meaning its range is less than 1 meter if having to go through a human body...

</comment><comment><USER25> Am I the only one with the opposite experience? Given the huge amount of devices, protocols and use cases I'm actually surprised how well it works.

</comment><comment><USER26> I get the impression that Bluetooth 5 is better on multiple counts — based on a set of TaoTronics headphones I've used. (Most of the devices available currently use Bluetooth 4.2, afaik)

</comment><comment><USER27> I have the same issues. Each new version of Bluetooth it's supposedly fixed but still lacks.

</comment><comment><USER28> Yet if you get a device from Plantronics the Bluetooth is immediate and rock solid, so it can be done.

</comment><comment><USER29> I spent two years working with the Nordic nRF51822 Bluetooth chip. During that time Nordic continually modified their developer API, completely changing it at least once. They changed the chips themselves every several months also, and you had to match the API version to the chip. They obsoleted old chips, so the code you had written would not run on the new chips, and it soon became difficult to find the old chips forcing you to upgrade to the new version of the SDK and change your code. Example programs in new SDK's often did not work because Nordic had not finished porting them. None of the example programs were written to coexist with the others; if you tried to combine two examples the result would often fail. The complexity of Bluetooth is also staggering; instead of writing code I could have probably spent those two years just reading the documentation, by which time substantial parts of it would have changed.

Before switching to Bluetooth we used the nRF51422 as an ANT+ radio. The development experience was completely different, it was a joy to work with, example programs were simple and worked. It was easy to code the things we wanted to implement.

My understanding of this extreme difference is (1) Bluetooth was designed to present a high barrier to entry, so that smaller device makers would have a hard time competing. It is intentionally complex and difficult to deal with. The standard for SD cards is similar (which is why almost all open source projects use the simpler, less functional SPI method of accessing an SD card.) (2) Nordic had a team for hire to write Bluetooth code for customers. Some of the API turmoil might have been to make it difficult for customers to develop their own code so they'd have to turn to Nordic for software. It's difficult to prove either of those conjectures, especially since large corporations see a benefit in creating barriers to entry and will support them.

So basically no one reads the documentation, they try to work from the example programs, and stability and interoperability suffers because no one really understands what they are doing (the API's completely obscure the underlying operations). Hence Bluetooth is often unreliable, unless a company has a team devoted to it and spends a lot of resources on it. The large gaps of undefined behavior don't help either, the order of many API interactions is often absolutely critical, even when you wouldn't expect it to be.

Another factor is that Bluetooth subsystems are essentially real-time systems where timing is critical. The chips are often sold as having spare MCU capacity for running your own code, but it's not apparent in the advertising that your code needs to be pristine and flawless in handling interrupts and in how long running operations are handled. Otherwise the Bluetooth firmware behind the API can easily lock up or start to do weird things. So a device maker who tries to have the Bluetooth MCU do other things to save the cost of an external MCU can easily have bugs in their code that interfere with the operation of the Bluetooth stack.

</comment><comment><USER30> Forget Bluetooth.

Why is Wi-Fi so unreliable? At this point you need specialized semi-pro equipment just to get a reliable connection to a router 15 feet away.</comment>


Show HN: Remote jobs aggregator - <AUTHOR> http://remote-all.com/ <comment><USER2> Well done! Saves time going through all these sites when looking for a remote job. It would be nice if the website listed all the sources so that I could be sure it's not missing some site I know about.

<comment><AUTHOR> hi, right now its 6 pages: Github Remoteworking WeWorkRemotely Stackoverflow Jobmote Wfh

they either provide remote jobs mainly or i filter them.

Thx for liking it, it would be really nice to know if someone actually found a job with that page. Truth is the page visits are quite low and i am not motivated to work on it. But it will still run without any change. I may come back to it, but there is a different side project right now that i am trying to accomplish (its great to be a full stack developer :P ).

</comment></comment><comment><USER3> Love this idea, very useful.

Couple little bugs/notes I noticed: The position titles are appearing twice, and my google seems to think this page is written in Slovak? And keeps offering to translate it...

Thanks for creating!

<comment><AUTHOR> ah man, ill fix that (when i return from work :-D )

thx for trying.

</comment></comment><comment><AUTHOR> Just added better design and few simple features: company name, job type, company location -> displayed if available

Some sites offer this info but mostly its not there or hidden in the text

</comment><comment><USER4> You should definitely preserve original content formatting. Description texts are fairly unreadable.

If you manage to add features extraction (company, country, description, requirements, salary/benefits) it will make a great deal.

<comment><AUTHOR> thx for trying, yes the formatting is bad, you should find the job with the tags and then go to that page rather :-D

truth is, not many people are using it (if i don't promote it on some facebook/forum page for that day), so i am not too much motivated to add features that may make it +5% better. I guess i could still try, not many job offers give away the salary, while it would be nice to know.

thx again, would be nice if someone would find his future job there :) .

</comment></comment><comment><AUTHOR> So i made this little project that goes trough several site with remote job offers and gets them all. I tried to make automatic tagging what helps to find the right jobs but it may be misleading sometimes.

</comment><comment><AUTHOR> Just added all used tags on the page, for easier search. You may not see it on a phone.</comment>


APL386 Unicode – An APL Font - <AUTHOR> https://abrudz.github.io/APL386/ <comment><USER2> Still hoping for someone to design a font for J with ligatures so it can match APL's beauty for reading without making it more difficult to type, i.e. automatically rendering /: as ⍋, |: as ⍉, |. as ⌽, etc.

<comment><USER3> Agree this is a good idea.

To clarify: it'd be cool if language's supported multiple lexemes (?) for a single token. So -> and → (U-2192) are equivalent.

<comment><USER4> Julia has this too. [https://docs.julialang.org/en/v1/manual/unicode- input/](https://docs.julialang.org/en/v1/manual/unicode-input/) and [https://riptutorial.com/julia-lang/example/19760/standard- op...](https://riptutorial.com/julia-lang/example/19760/standard-operators) .

<comment><USER5> I was going to mention Julia.

Not only does it have it, it has it in (what I feel) is a really accessible way. Seen a symbol and you don't know what it is or how to reproduce it? Enter "?" and paste them symbol into the repl and it'll tell you what's it's called, the shortcut to make it, what it does, and the equivalent non-symbol function name.

</comment></comment></comment></comment><comment><USER6> I don't know if it's intentional, but the clumsy character shapes, the haphazard line weights and the "bleeding ink" effect whenever there is a curve or a corner give it a strong "early DTP" aura. Or possibly even earlier, like a mimeographed pamphlet in the late 1960s, when APL was new.

</comment><comment><USER7> Kerning on Cyrillic is pretty much awful with this font. Ever on the example string it looks like there is a space between Ь and Э, and Ш and Щ are almost glued together.

<comment><USER8> Isn't this a monospaced font?

<comment><USER7> It is, but it does not excuse it. Latin characters in it do not have such problems.

</comment></comment></comment><comment><USER9> Sudoku solver in APL

[https://www.youtube.com/watch?v=DmT80OseAGs](https://www.youtube.com/watch?v=DmT80OseAGs)

</comment><comment><USER10> I intend to obtain an IBM 2741 terminal and APL typeball before I start learning how to write APL--Anyone got any leads, other than ebay?

<comment><USER11> I used to own one. Pretty clever technology, particularly for the time.

</comment></comment><comment><USER12> There's Ę, ę present but it lacks Polish and Lithuanian (mostly, there are other languages that use this particular letter) Ą, ą

</comment><comment><USER13> Is "with a fun, whimsical look, inspired by Comic Sans Serif" something someone wanted?

<comment><USER14> When I'm in the right mood, I use Comic Code[1] for my terminal, along with a different palette than my normal "working" environment. Even if it's just placebo, it helps me shake up my thinking a bit.

[1] [https://www.myfonts.com/fonts/tabular-type-foundry/comic- cod...](https://www.myfonts.com/fonts/tabular-type-foundry/comic-code)

<comment><USER15> I actually use it for real work. It fixed a lot of problems for Comic Sans and is surprisingly comfortable to read.

</comment></comment></comment><comment><USER16> It's interesting to me to see these projects as alt-history, and see them as the dead-end technical choice that they were.

Has any programming language since then tried to use more than ASCII for its keywords?

<comment><USER17> I program in Agda pretty often and community usually uses Unicode characters for most things, so I do too.

The impl of AVL trees in stdlib: [https://github.com/agda/agda- stdlib/blob/master/src/Data/Tre...](https://github.com/agda/agda- stdlib/blob/master/src/Data/Tree/AVL.agda)

Some basic properties of natural numbers: [https://github.com/agda/agda- stdlib/blob/master/src/Data/Nat...](https://github.com/agda/agda- stdlib/blob/master/src/Data/Nat/Properties.agda)

It makes the code look absolutely gorgeous, readable and it's very easy to type too. I use Emacs agda-mode so it just automatically replaces e.g. \r with → or \== with ≡ etc...

I don't use Agda for theorem proving, I make real life programs in Agda, I compile them to Haskell and compile with GHC to executables.

<comment><USER18> What font do you use for this? It looks weird with my defaults.

I once seriously considered trying to build something that included math symbols in the syntax. It's pretty cool to see that I don't have to.

<comment><USER17> Not currently on my computer with that setup but afair I use Inconsolata.

</comment></comment></comment></comment><comment><USER19> Would look right at home on a 1990 Mac.</comment>


The New GitHub Issues - <AUTHOR> https://github.com/blog/1866-the-new-github-issues <comment><USER2> Under the " _All the small things_ " section of the post:

> "You'll get a notification if an issue is assigned to you."

> "No more mixing: the "issues" tab will only show you issues, and the pull > requests tab will still only show pull requests..."

> "If you use Task Lists, we'll show the overall progress on that issue or > pull request on the listing page: "

Yes! These are three features that I have been waiting on for awhile now. Especially now that I don't have to open a ton of tabs to see task lists for each issue. That's so awesome the task lists are now in the list UI.

Great work, GitHub!

<comment><USER3> I always viewed the issues list including pull requests as a feature.

<comment><USER4> You can totally get to this by removing the `is:issue` or `is:pr` from the search field. That'll show everything, regardless of type.

</comment></comment></comment><comment><USER5> This is nice. There are two things however that would make GitHub issues awesome:

1\. Starring / Voting an issue. The count of stars/votes should be visible and we should have the ability to sort by the number of stars / votes.

2\. Labels with values. Simple integers types would do to begin with. For example, priority:1, priority:2, etc. And then being able to sort by the value.

<comment><USER4> We've long discussed voting. It probably definitely won't ever happen in the near future.

You can set create `priority:1`, `priority:2`, etc labels right now and sort by those values. Not quite the same as what you want, but it's a pretty close solution until we figure out the next features to add to Issues.

<comment><USER6> A bit sad, as a member of a big project on github, I'm sure that "starring" could be a handy way to know what people are interested in. (And avoid a lot of "me too"-comments, from devs and other users alike).

<comment><USER7> I think Google Code does this one right: "Subscribe" is a star and you get notified -- star counts are public. I hope github adopts that model.

</comment></comment></comment></comment><comment><USER8> I'm still confused by the inability to do prioritisation. Why does Github so stubbornly not have a way of doing that including sorting on it? I am aware you can create arbitrary labels, but that doesn't help with sorting.

We long ago gave up on Github issues because of this, and use Trello instead where priority is simple drag and drop. The other problem is that you can't easily copy/move/link issues between repositories. This becomes necessary when you have different repos (eg a server one, an android one and a web one) and something is reported against the "wrong" repo. Not the reporters fault, and very tedious to correct.

This is all one area where Google Code does things so much better (yes you can prioritise and sort). Each project can have any number of repositories and they all share the same wiki and issue tracker. That is a lot easier to deal with. Of course refusing to take money, and apparently losing interest means it can't be used.

<comment><USER7> The problem is you always have to cut features somewhere to remain clean.

Look at bugzilla: So many fields most people don't need. Who needs to separate "Resolved" and "Closed" for example? Who cares about the OP's platform when you're building a web app? And why is "importance" different than "priority"? Why is there a keywords field, a tags field AND a whiteboard field? Wtf.

But all these are actually useful to some people out there. The problem is the end result is a mess. I find github issues to be good enough for 99% of non- massive/non-corporate projects out there. People can just go check out your project and add 3-4 bugs/suggestions as easily as they would comment on a blog post.

Personally what I miss is being able to flag a bug as a dupe of another. But again, do most projects need that is the question.

<comment><USER8> Prioritisation is something I see in every other tracker. If items are dispatched/fixed/closed from the tracker faster than they come in then it doesn't matter, but that is rarely the case. The moment there is more available issues than can be worked on right now, prioritisation needs to be done. The are many criteria that could be used, but "priority" is a pretty established one. The problem with github issues is there seems to be no viable way to get that.

I agree about having lots of different fields. I once worked somewhere where after a series of acquisitions 11 different bug tracking systems were collapsed into one! Having arbitrary labels mitigates most of those. IIRC Google Code also lets add as many different states as you want so that works too, letting projects be as simple or complicated as suits them.

<comment><USER9> This os why Django uses Trac. Github issues can't handle that much traffic, triage as a simple Trac installation with a couple of pkugins.

</comment></comment></comment></comment><comment><USER10> Is there a way to search by the status flags? It's now harder to see them since they're no longer in the same column, and I use the "has passed tests" filter frequently to check which PRs might need shepherding on Servo ([https://github.com/servo/servo/pulls](https://github.com/servo/servo/pulls) )

</comment><comment><USER11> I would like the issues to become part of Git repository. Perhaps some folder structure in separate branch.

<comment><USER12> Sounds like you just want to use a distributed bug tracker. There are several to choose from: [http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...](http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20)

</comment></comment><comment><USER3> I mostly like this, especially the way in which things like label/title changes are finally displayed.

You know what I would _really_ like to see next? A bit of adaptive design. Something that will let me use a narrow viewport without needing to scroll back and forth all the time.

<comment><USER4> Eh, adaptive/responsive features are not that much of a payoff for us honestly. It helps with a few edge cases of screen splitting, but there are far bigger changes we can make than spending time on that. I wouldn't rule it out, but it's not at the top of our list right now.

</comment></comment><comment><USER13> Two feature requests:

1\. hiding issues

2\. CC people / stop notification

For example as more and more teams are using Github, and although the spirit of open source is collobration, sometimes security bugs are probably better handled if they are hidden until resolved.

There are two ways to do this now:

* email

* bugzilla / bug bounty site

Wouldn't it be awesome if I could just let people report security bugs on Github except they are hidden as opposed to managing and tracking tickets from multiple places?

I know now you can CC people using @ but what about muting notification? As a bugzilla user, I can stop being notified if I remove myself from the CC list.

</comment><comment><USER14> This is nice and everything, but the one thing that I don't like so far is that getting to the list of labels isn't just a sidebar away anymore but instead a whole tab change. I do see that you can filter by label through the filter textbox, but that isn't quiet the same for someone like me who uses the colors more than the name of the label.

Overall, looks nice though. Curious to hear what power uses think of it.

<comment><USER4> Hey there! Try clicking on the labels within the issues list—they are linked up to quickly adjust your search without typing. Not quite the same, but hopefully it helps!

<3

<comment><USER14> Oooh, that definitely helps a fair bit. I think the label dropdown in the panel head is nice and what I'll end up using the most often. Still have to find all the little changes hidden around this :D

</comment></comment></comment><comment><USER15> One thing I noticed recently that really bit me was I created a few issues on a public repo which decided to disable issues and so I lost them forever.

<comment><USER7> FWIW the issues are still there if they are re-enabled. You could try asking the repo owners.

</comment></comment><comment><USER16> I can filter by not having a label attached! Ex. "-label:"90 - Complete"" will show all issues not labeled complete!

<comment><USER17> Related: `no:label` will show you everything that's _not_ labeled in your repository, too.

</comment></comment><comment><USER18> just one quick feedback - it will be awesome if the whole bar is clickable instead of just the title of the issue.

<comment><USER4> Up until a few weeks ago, we had the whole issue clickable. It'd toggle the select checkbox for bulk actions across multiple issues/pulls. However, we opted to skip that as missing a click on say a milestone name, user avatar, or label would then toggle that issue's selection. It'd be even worse if the accidental clicks sent you to a specific issue as you'd get inadvertent loads and have to go back.

Bottom line? Too frustrating for common use, so we skipped it.

</comment></comment><comment><USER19> I'd love support for an issues.markdown - which appears at the top of the issues list or above the form for creating a new issue. I have a moderately popular web app which it want to keep client side only but which gets constant requests to add saving / server side..

</comment><comment><USER20> This is great! One thing that I was not able to find: is the activity tracking around labels exposed in the API? We (the Brackets team) actually wrote a tool to collect data about when a label was added or removed and it would be a welcome change to not have to support that :)

<comment><USER21> And we just shipped that via [http://git.io/1hV9Ug](http://git.io/1hV9Ug) and you can get the events through the API at [https://developer.github.com/v3/issues/events/](https://developer.github.com/v3/issues/events/)

:D

</comment></comment><comment><USER22> I seem to get a 500 error page whenever I search for something along the lines of "NOT label:css". I was hoping to be able to find issues that are not labeled as something.

Other than that this seems like a great improvement!

<comment><USER23> To exclude any labels you can use -label:css. Works with most other filters too.

</comment></comment><comment><USER24> All great updates, but it's missing one key thing for us: the checklist tracking only includes check items from the first post on an issue thread. Any checklists in subsequent issue comments are not counted.

<comment><USER4> I think we do that because what happens if random contributors jump in and start adding even more random task lists? We could probably do some checks to prevent that, but this is at least a safe and practical way to do it as a first-pass.

<comment><USER24> Yeah, I can definitely see that for public projects. That said, the subsequent comments could just be edited to remove the extra checklist if it were an issue.

<comment><USER7> A similar argument can be made the other way: The OP can be edited to include further tasklists if needs be.

<comment><USER24> True, but then you lose comment notifications, and edits can't be made simultaneously to the same post by multiple users.

<comment><USER7> You can get comment notifications by hitting the Subscribe button. The latter seems like a good problem to have, and one which you would normally not hit if you're still using Github issues.

</comment></comment></comment></comment></comment></comment><comment><USER25> Exposing the search bar is a very nice addition. However, I'd still like a quick filter that gives me "involves:<me>".

<comment><USER26> That exists: [https://help.github.com/articles/searching- issues#involves](https://help.github.com/articles/searching-issues#involves)</comment></comment>