New in PHP 8 - <AUTHOR> https://stitcher.io/blog/new-in-php-8 <comment><USER3> At these rate of improvement, along with Laravel, may be I should seriously evaluate moving back to PHP stack. It was only the other day Antirez, author of Redis [1] was complaining the Ruby Stack is more complicated than it should be. And I wholeheartedly agree.

[1] [https://mobile.twitter.com/antirez/status/122328600521977446...](https://mobile.twitter.com/antirez/status/1223286005219774464)

<comment> core-questions There was never anything wrong with PHP, really.

* If you wanted to scale it horizontally, it was ready to do that 15+ years ago

* No problem running it completely stateless

* Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much

* Performant enough as far as the interpreted web languages go

* No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want

* Server side rendering since day 1

Like, it came down to people complaining about some function names / param orders as if it were the end of the world. I think a certain subset of people (shall we call them hipsters?) are just keen on finding new ground where they can rewrite the same boring things instead of working hard to improve the ecosystem of something existing.

I moved on from PHP aeons ago because it got this undeserved bad rap, but I still follow it and would welcome the chance to run it again.

<comment><USER4> Function names and parameter order matter. That is the difference between having to look something up in the documentation and not. Back in those days most text editors didn't have fancy autocompletion with parameter documentation, if you weren't sure about the order you might have to look it up in the documentation. Having a self-consistent API that was easy to remember was essential. _Especially_ in a language with dynamic types!

When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.

<comment><USER5> It takes 10 sec to google "str_replace" and have the params presented to you. Using a manual is an integral part of development. I don't think there's many people who can memorize all the methods and their params, including optional ones, nor should they.

<comment><USER6> That sounds like it takes a lot more time and mental energy than if the API were consistent.

<comment><USER7> We have machines to do that _for_ us. As in, "press Ctrl+Q, IDE shows relevant help." I don't value encyclopedic knowledge of every API out there any more...especially since those I do recall are of rather, um, limited use nowadays. Like with any language, the point isn't to cram a dictionary into your brain, it's to communicate.

<comment><USER4> It's a red flag if the _basic operations_ (like string and array functions) are so inconsistent and weird so as to require use of an IDE or constant use of the docs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is pretty awesome, I've been migrating from C# and NodeJS back to PHP and it's awesome. Want to know why?

\- Everything is either built-in or can be enabled from an OFFICIAL repository (like functions for bc,xml,etc). No more trusting sketchy npm packages or having to pull in a ton of dependencies that might stop working some day.

\- It's so fast and elegant to consume a (SOAP or REST) webservice. Visual Studio insists on creating tons of files, obscure web.config settings and other misc. stuff. PHP handles this in a couple of lines.

\- Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available.

I estimate I've slashed development time in half compared to C#, less bugs and less security issues (verified through two independent code auditors). Even large projects are easier to work on in PHP compared to C#

<comment><USER9> I have to disagree with pretty much everything you've written, because it seems like you're running into issues of a paradigm shift.

If I'm going to consume a web service, I am going to write the models in C# and let a JSON deserializer like Newtonsoft.JSON map everything. To me, there's nothing better than having a fully modeled web service. I learn a bit about how the service works when writing the models. I know what the data looks like before I start working with it in my own application.

Regarding your web.config note, I guess I don't understand what you're trying to get at. .NET projects tend to throw configuration items into, well, a configuration file. Again to me this is far superior to doing the PHP- industry-standard of having a config.php and chucking a bunch of global variables into it. Putting configuration items behind a parser in a document that you expect the user to edit is good practice.

 _Development feels natural, every file can be a single class if you want and there are plenty of highly matured frameworks available._

Maybe this is a note more for the NodeJS space, but a single file per class is the general guideline for C#/.NET. Additionally, I've generally found that the .NET framework and libraries written against it tend to be of much higher quality, are more secure, and are more production ready than most I've worked with in PHP land.

On top of that, Visual Studio is a _wonderful_ IDE and is pretty much the gold standard of our industry. I've not had a better experience as a developer than being able to create a .NET Core MVC web application and hit the ground running. I've written anything from 5 line Azure Functions to working with 100k+ line web applications and I'm not sure I could have done it without the excellent debugger available and the very context-aware Intellisense typeahead. In contrast, other than PhpStorm, I find PHP environments to be extremely messy and a bit of a hack to get working properly. If I didn't have some sysadmin background I'm not sure I'd move outside of "debugging" using var_dump().

I was a PHP dev primarily from ~2009-2017 and have been working almost exclusively in C# since.

<comment><USER10> > Additionally, I've generally found that the .NET framework and libraries > written against it tend to be of much higher quality, are more secure, and > are more production ready than most I've worked with in PHP land

Unless you've a solid proof, this is just.. blatant lie. How did you measure the security and quality? Was it "ok, this seems nice" or was it literally reading the code, running the tests and hitting the lib with a pentest suite?

See, it's one thing to compare languages (which is silly) and completely another to let your subjective feel get in the way of objective analysis.

Stating that libraries which contain more than 1 class per file are more secure and robust is just a nice wish, but nothing more than that. It's simply not true to the point it's funny :)

> On top of that, Visual Studio is a wonderful IDE

It sure is, top notch IDE.

> In contrast, other than PhpStorm, I find PHP environments to be extremely > messy and a bit of a hack to get working properly.

You've PHPStorm and there's VSCode. PHPStorm is better. It works almost flawlessly. What's an IDE got to do with environment? Why are they a hack?

I'm a dev who started with PHP in 1998. and have been using it since (among many other languages). Reason I'm writing this (despite hating it) is to nullify your experience as any sort of valid argument.

Unless you can provide actual, hard proof for what you wrote - it's merely how you'd like it is.

Now, is any of that important? It's not. You use C# and you're satisfied. That's all that matters. If some other guy says PHP is better - you know that it's not, in your particular case. And that's great.

IMO, as a PHP dev, I consider C# an excellent language. As a sysadmin, I hate Windows and its ecosystem from the bottom of my soul.

<comment><USER9> > Unless you've a solid proof, this is just.. blatant lie. How did you measure > the security and quality? Was it "ok, this seems nice" or was it literally > reading the code, running the tests and hitting the lib with a pentest > suite?

Yes. Additionally features of .NET binaries such as signing tends to be a bit more favorable to me.

> Stating that libraries which contain more than 1 class per file are more > secure and robust is just a nice wish, but nothing more than that. It's > simply not true to the point it's funny :)

That's not what I was stating. I was stating that 1 per file is common in .NET land and I personally believe that it leads to more organized code.

> You've PHPStorm and there's VSCode. PHPStorm is better. It works almost > flawlessly. What's an IDE got to do with environment? Why are they a hack?

VS Code isn't an IDE, really. It's a text editor with extensions. I was speaking more to the fact that setting up a proper development environment with PHP is a chore. If you're using an *AMP, you've got one shared environment across all your development projects. Things like debugging two PHP projects at once can't happen. Edge case stuff sure. Using vagrant or another VM solution is a super heavy way to accomplish something that should be simple. Using Docker is nice, but has its own pitfalls. I agree PhpStorm is fantastic. It's always been one of my favorite tools. A bunch of its editing features are leagues ahead of VS. Unfortunately, it's not a complete solution to a dev environment. And yeah, I'm aware you can launch `php` directly from PhpStorm. I usually find that to be a nightmare in its own way.

Again, I started as a PHP dev and it holds a certain place in my heart. I'm not sure I could ever find an instance to use it over any other platform, though.

Also, you should try to give .NET Core a try. It's a pretty fantastic platform. Like PHP, I would never choose to start a project with .NET Framework.

</comment></comment></comment></comment><comment><USER11> PHP is already one of the fastest languages. Hopefully JIT will make it even faster.

Currently it places #11 on the famous framework benchmark:

[https://www.techempower.com/benchmarks/#section=data-r18&hw=...](https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db)

<comment><USER12> I don't really understand that benchmark. How can swoole (#11), written in PHP, be faster than PHP itself (#125)?

<comment><USER10> Swoole hijacks network I/O from Zend Engine. Thus, it's capable of performing async I/O while keeping the userland code the same. What the benchmark shows is what happens when there's non-blocking I/O when speaking to the DB. PHP's problem is its synchronous nature, but Swoole easily bypasses that limitation.

Btw. Swoole is not written in PHP. It's C++. It's compiled as an extension for PHP.

</comment></comment></comment><comment><USER13> Honestly php seems like the common cold... an annoyance that is everywhere and treated with little seriousness. However every evolution it gets better and stronger and adapts other learnings from other languages. It really shouldnt be treated as a joke any more.

Ps: I love php and jquery... not for any real saas systems but no other tool set allows me to spin up and prototype full web app prototypes in sub 90 min. As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders.

<comment><USER14> > As a senior tech manager php and Jquery allow me to show functional > prototypes quickly and easily get buy in from other department stake holders

I totally get it if you prefer to leverage your knowledge of jQuery, but modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`, and many more. Combined with modern css with flexbox and grid, and prototyping becomes very quick.

<comment><USER15> jQuery: include this lib, modify DOM.

Modern JavaScript: traveling menagerie of package managers, compilers, build tools, etc. Now that is all in place, modify DOM.

At least, this is my impression from the outside. The last time I actually wrote js was around a decade or more ago.

<comment><USER16> As someone who is not very familiar with JS in its multitude of variations this is what it feels like to me. Somebody told me to try Vue and while reusability of components is surely nice to have I feel kind of lost when all I need is a popup when a "save action" was successful.

What about jQuery? Is it still the go-to for simpler things?

<comment><USER14> > What about jQuery? Is it still the go-to for simpler things?

Unless you need to target older browsers (like any IE, really), I'd just use vanilla JS. Vanilla JS means no packaging or build process needed. Just create write a JS file, reference it in a script tag in a basic `index.html`, start a web server (like `python3 -m http`) and you're good to go.

Spend a little time learning about flexbox and grid CSS APIs, and you don't even really need CSS framework if you're a decent designer (if not, use Bootstrap or some other CSS framework).

If you're targeting older browsers, like IE, then yes, it's probably a good idea to use jQuery and some CSS framework like Bootstrap.

Absolutely no need for Vue.js or React if you're just doing a very basic UI (however, note that basic UIs have a tendency to become more complex with time, so for that reason most JS devs start with something like Vue.js even if it's not needed initially).

(I'm a senior software developer working in frontend development exclusively for the past 5 years, but have been using JS since 1998, and jQuery since like 2008 - I left the software industry for a number of years after the dot.com bust and came back a decade later).

</comment></comment></comment></comment></comment><comment><USER17> Every time I see an article about new features in PHP I search the page for the "annotation" keyword. To be honest I find it a little bit puzzling that to this day a large part of the ecosystem (Symfony, Doctrine, API Platform) revolves around docblock annotations.

<comment><USER10> Agreed. Personally, I hate annotations. This is the reason why I never bothered with any tool in PHP ecosystem that relies on annotations. It looks ugly, it feels ugly, it doesn't fit with my mental model - I avoid it entirely.

<comment><USER18> Agree so strongly. Executable comments. Whose bright idea was _that_?

</comment></comment></comment><comment><USER19> Given how much PHP is used, having a JIT will probably save a meaningful amount of electricity

<comment><USER20> that page seems to state that it only works in the context of a single request

unless you've got CPU bound PHP code... it seems like a complete waste of effort

<comment><USER21> It's a way to promote php for other type of applications. Check swoole and reactphp, they will be benefiting the most.

<comment><USER22> Also check for memory leaks while you are at it.

</comment></comment></comment></comment><comment><USER23> > Undefined variable: Error exception instead of notice

Well, this is where the chaff separates from the wheat. There's no small amount of crappy code out there which will WSOD after this. Or actually print the exception because they couldn't even bother to switch display errors on... Of course, no even remotely sane codebase will be affected, but... Make no mistake, this is a good change but it will cause some teeth gnashing.

<comment><USER24> Over time I think (hope) this sort of change will help to improve the code that people write.

But I will not be surprised to see some people say things like "PHP 8 broke my code". Of course, what those people might not realize is that PHP 8 did not break their code, the code was always broken, and PHP 8 is now going to surface the brokenness of that code.

But even with code that people refuse to fix, this sort of change will make the brokenness of that code more apparent to others, and so the number of people that use that broken code will cease to grow. If not entirely, then at least reduce in pace of growth.

That is good for the ecosystem of computing. As a proponent of correctness in computing, this makes me happy :)

We all write bugs, but everything our tools and languages of choice can do to help us reduce the number of bugs and the severity (impact on security) of our bugs, the better.

<comment><USER25> I think it's really a philosophical question what is "broken". An undefined variable used to have a particular and also well-defined behaviour, now it has a different behaviour.

Personally, I think a lot of these design decisions which some people abhor is why PHP became popular in the first place. In that perspective, turning it into yet another "big bureaucratic language" is very much against the spirit of its existence.

<comment><USER26> Since the dawn of programming there's been a schism as to whether undefined means empty versus being a logical error. But deep down we all know what it should mean.

</comment></comment></comment></comment><comment><USER27> > The @ operator no longer silences fatal errors

Interesting. There are still some legitimate (well, "legitimate") use cases for that behavior e.g. with PHP's native XML extensions.

<comment><USER28> Are you sure those are _fatal_ errors?

<comment><USER29> [https://3v4l.org/saHj2](https://3v4l.org/saHj2)

However you could just catch Exception. Not sure why a parse error is a "Fatal error".

<comment><USER30> A PHP parse error (of your code) is a fatal error.

A xml parsing error in the SimpleXmlElement constructor is not a fatal error - it throws an exception.

An uncaught exception is a fatal error.

</comment></comment></comment></comment><comment><USER31> Union types!

This is amazing to see. So many languages these days agree that functions are good. Now they're all adding type systems of one sort or another.

PHP has always been a bit behind the curve but good on the developers for pulling in a cool feature like this.

</comment><comment><USER32> # Summary of some of the new changes:

 _## Union types_

Specify multiple types

        public function foo(Foo|Bar $input): int|float;

_## JIT_

Just in time compiler for improved performance

 _## Static return type_

Return static of class

        class Foo
        {
            public function test(): static
            {
                return new static();
            }
        }

_## Weak maps_

Prevent blocking of garbage collection for improved memory usage when needed

        private WeakMap $cache;

_## ::class on objects_

Get class type from object like get_class($object)

        $foo = new Foo();
        var_dump($foo::class);

_## fdiv function_

When you don't care about division by zero

        fdiv($x,0);

_## Concatenation precedence_

Math takes precedence in string concatenation.

        // this
        echo "sum: " . $a + $b;
        // evaluated as this
        echo "sum: " . ($a + $b);

_## Some others_

\- Create DateTime objects from interface

\- Type annotations for internal functions

\- Variable syntax tweaks

\- Breaking changes

\- Consistent type errors

\- Reclassified engine warnings

\- Reflection method signature changes

* Note: HN pretty please get improved mark down parsing

</comment><comment><USER33> I've used PHP from 1998 to 2016.

Things I remember I didn't like about/around PHP:

\- too many aspects of the language were dependent on config/php.ini.

\- it had errors and exceptions. I just wanted exceptions.

\- was not very interesting/useful/great outside web backend.

\- mb_* functions were not enabled by default

\- it had no decent REPL.

\- "reference" libraries had bad APIs or were over-engineered.

I'm not sure about the state of these issues now, but frankly I never felt the need to look back. Good to hear there's still progress though.

</comment><comment><USER34> I expect to have some time soon and I'm planning on writing a full-blown application in PHP, using nothing but functional style programming. Should be fun.

<comment><USER35> It should! Have a look at Illuminate\Support\Collection, which you can pull in as a separate package (apart from Laravel).

It makes doing functional stuff in PHP a lot of fun.

<comment><USER36> You might also be interested in Dash: [https://github.com/mpetrovich/dash](https://github.com/mpetrovich/dash)

<comment><USER34> NO FRAMEWORKS!!!

</comment></comment></comment></comment><comment><USER10> Judging by comments I saw and what I had my own clients tell me over the phone/mail, it would appear that there's stigma associated with PHP, mostly due to one super-popular blog post called "PHP - a fractal of bad design". I won't go into rebuttal here, the author of the post did enough damage as it is.

PHP evolved significantly since version 4. Version 5 was the "big" deal, with good object oriented features. Version 7 brought the performance in, so we could get rid of Facebook's crappy HHVM (thank you PHP team). Version 8 brings JIT, however most of the workload isn't CPU bound but I/O bound.

So, here's something for PHP devs:

Swoole. [http://www.swoole.co.uk](http://www.swoole.co.uk) -> this is an extension for PHP which brings in the same primitives available to people using Node.js or Golang - coroutines, async I/O, channels, event loop control and much more.

What it essentially does is turn ALL I/O from synchronous to asynchronous. Without any code change or control structure in form of async/await or promises. Write synchronous code, get asynchronous performance.

From my own experience (I've been running swoole in production for 18 months), the performance gain I saw was minimum 500% to a maximum of 2000% (the numbers aren't a joke).

As for PHP - it's a programming language. You can use it right or you can use it badly. This rule applies to almost any language. There's no language in this universe that can turn a bad programmer into semi-ok programmer or even good programmer. If you haven't got the habits and knowledge, there's no language that can rectify it. I've seen way too many people thinking the language of their choice is to blame, but it was always the person in the chair.

PHP performs well. Ecosystem is quite large and luckily there aren't competing standards. Composer, the package manager, is wonderful. There's plenty of frameworks to choose - for web and for CLI usage. Features are being added, slowly but steadily.

I use PHP with Laravel + nginx, next to Nuxt + Vuetify + TypeScript for frontend stuff. Personally, I really like how the mentioned tech can be utilized to create great apps _fast_ \- with structured code, that look good and work quick.

Edit: one of the best and most powerful features in PHP (starting with 7.4) is the FFI - foreign function interface. The option to utilize libraries or entire software, without the need to write PHP extensions, is what's amazing for me (I also need it due to nature of my work).

PHP is way more powerful than people give it credit for. But I guess that's what happens when opinions are formed by looking at titles and number of "likes" or other meaningless numbers designed to mislead.

<comment><USER37> I like the look of swoole, first i've heard of it.

There is also a complete application server that supports php servlets, message queue, persistence etc. that is well-supported. Its free, open source.

[https://appserver.io/](https://appserver.io/)

A team that supports Magento, Typo etc. based in Germany wrote it.

You can use either the PHP-FPM or the more interesting is the servlets, because the data is kept in-memory - probably much in the same way as swoole functions.

Its basically enterprise Java for PHP.

<comment><USER10> I know about appserver.io and I would strongly advise against it (I have used it, along with every other project that tried to use pthreads or bypass PHP- FPM). It's not scalable. It also achieves "performance" by having the same process(es) work on the requests over and over again, effectively bypassing what PHP-FPM does on each request. If you set PHP-FPM up that a child process kills itself after 500 requests processed, you'll get the same performance as with appserver, but it'd scale horizontally. It's a toy and I would never use it in production, the authors made a huge mistake of trying to process requests in separate threads - my assumption is they just learned there's a way to expose threads to PHP userland so they toyed with it.

Swoole is entirely different beast, it's like comparing a skateboard (appserver) to intergalactic starship (swoole). It's not just about the performance as it is about exposing OS primitives and having fine control over I/O and processes.

Excellent find, but luckily - the current tools we've got at our disposal are even better. No offense to people using or working on appserver, some projects are just that - toys that help people learn more.

<comment><USER38> Have you any view on libev and the PECL ev library? There's been a recent discussion on the php-internals mailing list about whether PHP needs a built- in event based system ([https://externals.io/message/108226](https://externals.io/message/108226)) .

Having input from you with production experience of Swoole would be _fantastic_.

</comment></comment></comment></comment><comment><USER39> I'm a bit confused. I thought PHP 7 introduced a JIT, hence why it was much faster (in some cases ~5x faster). How is it different from the PHP 8 JIT?

I always assumed that HHVM is what brought JITs to PHP originally, followed by PHP itself.

<comment><USER40> I believe there were attempts at implementing JIT in PHP 7 which were unsuccessful against the timeline for release. Instead, they did other optimizations and managed to squeeze quite a bit of performance doing this (comparable to HHVM).

<comment><USER41> I think 7.1 or 7.2 was where it generally beat HHVM.

</comment></comment></comment><comment><USER42> I like that 8 has some great changes coming and the JIT will be a long term win.

I just hope the core maintainers evaluate true async/await constructs for PHP. I also hope that the JIT leads to more significant advancement in PHP and how it manages memory. For all it's improvements it's still really prone to memory leaks easily

<comment><USER43> PHP is synchronous (if you dont add async extensions). How would you use async await in the language?

<comment><USER42> reactphp already fakes this with Promises, much the same as JavaScript Promises. Why not make this a genuine language construct. You can even use the async and await "sugar".

Coroutines would also be a genuine improvement

<comment><USER43> Sure there is also most notably swoole if you want async i would go all in. That said it is going to be so wierd for most php programmers you might aswell hire nodejs people and do it in node where language and ecosystem is all about async.

<comment><USER42> Maybe, maybe not. The nice thing about adding constructs to a language is that you often can _opt in_ when you do use them. Also, if you have PHP developers, its going to take less time for them to learn async constructs in a language they're familiar with than switching your _entire backend_ to nodejs just to leverage those features. Seems to me like that'd be far more work and cost a lot more.

Its not trivial to just upend an entire system.

</comment></comment></comment></comment></comment><comment><USER44> I'm going to go ahead and play devil's advocate here and make the argument that iteratively transforming PHP into a Java/C# clone is actually doing a disservice to PHP. The reason PHP is so popular, and it's greatest strength, is that it offers a "simpler" paradigm of development.

Many of the latest RFCs accepted (while I agree are great steps forward for the language) may actually reduce it's foothold going forward. That is, they are not a good fit for the community. I see no compelling reason to choose PHP for a greenfield project if, when used in a production environment with a stable framework, you are writing essentially the same code as you would for Java/C#. There is hardly a feature where an ASP.NET core C# project isn't still miles ahead of the same Symphony/Laravel back-end. Hell, with the new Razor-Pages template, you are essentially writing "PHP" in C#... where you get all of the bells, whistles, helpers, type-checking, generics, pattern matching, LINQ etc that C# already offers!

IMO (emphasis on the "O") they are missing the point. I don't want my PHP application to "look" just like a Java/C# app. I don't want a `Controllers` directory and `RepositoryInterface`s everywhere... I don't want all of the same ceremony it takes to develop a .NET Core/Spring app copied into PHP. What I want is a composition of "scripts" (functions)!

PHP should focus on and develop towards it's strengths not it's weaknesses. _Lean in_ to include. _Lean in_ to $GLOBALS. _Lean in_ to a more functional approach. These are the things that have made PHP so dead-simple/approachable over the years.

You want more features? Fine. Add pre-processing directives (akin to .razor). Allow for files to truly be treated as modules. Simplify/abstract templating into the language better. That is, instead of focusing on the kinds of "features" that better-enable OOP (and move away from a composition of "scripts"), focus on making it easier/better to compose "scripts". Make _that_ safer, clearer, more ergonomic. There are _plenty_ of ways to dramatically improve PHP (as a platform) without simply updating the language semantics. The language was _never_ the draw!

As many of the comments in this thread indicate/imply, PHP isn't chosen because it is such a great _language_ , rather, it is chosen because it offers an extremely convenient development paradigm. PHP is very-much "batteries included" when compared to its contemporaries[0]. _This_ is why people reach for it over and over again. So instead of changing the vehicle (PHP), how about we give it more/better batteries instead?

/devil's advocate

How'd I do?

[0] I have always found the whole "framework vs raw PHP" debate in the community a bit humorous. The "framework" crowd never seems to really understand that, in many ways, raw PHP _is_ a framework. What other scripting languages _automatically_ parse HTTP requests for you as part of the runtime? Or come with a default "routing" scheme? Or offer built-in templating semantics? PHP gives you all three out of the box.

</comment><comment><USER40> Union types look somewhat handy, especially if you're using

        T|null

In PHP 7, you can still do

        function foo(string $bar = null): void

Which is a little clunky...

<comment><USER45> In PHP 7 the correct code should be

        function foo(?string $bar): void

Having `= null` marks the parameter as optional with the default being `null`. Using `?string` means there is no default and you can pass in either a string or null.

<comment><USER40> Yes thanks. A little rusty on the old PHP knowledge off the top of my head.

</comment></comment></comment><comment><USER46> Is it just me or PHP is trying to become Java? I remember 7~ years ago PHP devs were "mocking" Java and not it kinda feels like its moving there

</comment><comment><USER47> PHP and Perl are as dead as the Diesel engine in 2020. Somehow they are still everywhere, but it doesn't feel right to start anything new with them.

</comment><comment><USER48> PHP is looking a lot like Java these days.

<comment><USER49> I've seen a lot of people say this but I don't understand the sentiment, could you explain it?

<comment><USER50> Either you haven't used Java, or didn't look at the examples in the link.

The code looks similar to Java code, how classes are constructed, extra type modifiers, type access levels etc.

<comment><USER49> Or I'm surprised at the notion that types in an OO language is the minimum bar for "turning into Java"?

That seems like a nonsensical litmus test.

<comment><USER50> Other languages that have these but they do look different.

I personally don't see anything wrong with it, but it does resemble Java to me.

</comment></comment></comment></comment></comment><comment><USER51> wow, even PHP gets union types.

More languages really need to adopt union types.

</comment><comment><USER52> why does php garbage collect anything when there is a reference ? (weakmaps)

<comment><USER53> Right now, it doesn't. If there's a reference, then the item is not garbage collected. The WeakMaps change will allow a developer to take a reference to something but say, "Hey, I'm caching this for now, but if you need the space, I'm not married to it."

</comment></comment><comment><USER54> Misread that as "new in PDP 8". I was expecting an old-school DEC story for a moment...

</comment><comment><USER55> I hate php because: even if I used it for ~3 years I had to google how to send GET/POST/PUT ... request. There are lots of ways to do that but each method has its own issues. I'm now using dotnet core and happy with it's orm/speed/infrastructure l/productivity/...

<comment><USER10> This is exactly one of my points - and don't get me wrong - you're to blame here.

Let's dissect your post a bit: you had to google how to send GET/POST/PUT TO PHP or FROM PHP? Regardless, PHP doesn't care what you send it, you can send JSON or base64 encoded string. It's completely irrelevant. If you used PHP for 3 years and are unaware of basic HTTP communication - how's PHP to be at fault here? The real problem here is that you _imagined_ something, it didn't work like you wanted it to and the next logical step is to blame the language. This is such a bad way of thinking, I genuinely feel sorry for you.

I could pull several projects that deal with input via HTTP in PHP, and they do it more than nicely. Issue is that you're simply - mediocre. And there's no language that can fix it. Btw. my intent is not to insult you, even a mediocre programmer can become a superstar.

<comment><USER56> I think most other languages and frameworks work via a more declarative API - "if a GET request to /this comes in, return that". I had to look it up / remind myself how it works in PHP as well the other day, and it's a bit more involved:

        - Create a .htaccess file that rewrites /api/x/y/z to /api/index.php/x/y/z
        - Read $_SERVER['PATH_INFO'] for the /x/y/z
        - Read $_SERVER['REQUEST_INFO'] for the HTTP method (GET/POST/etc)
        - Create the response starting with some calls to `header()`
        - 'echo json_encode($resp);'

I'm sure all that is abstracted away in e.g Laravel though. The PHP standard library could also do with an overhaul for modern applications for requirements like this though.

<comment><USER10> \- $_SERVER contains server and execution environment info \- $_REQUEST contains request input parameter values (regardless of http verb)

That's it. It's not a lot. They're 2 super simple arrays.

PHP can also work from command line where $_REQUEST/$_POST/$_GET are unavailable. You can also entirely ignore the existence of the above variables. You can read from standard input and treat input as JSON - <USER2> are endless. This merely means that the example shown is not entirely correct - it's not "how it works in PHP". It's merely one of the ways. But the real problem is: no one bothered to research it and you blindly assumed that's how it works.

Laravel (Http/Kernel library) standardized the interface towards the dev and that's great. But the input itself isn't as tied to PHP core as your comment makes it seem.

</comment></comment></comment></comment><comment><USER57> I wish PHP makes the end of line semicolons optional like other modern languages.

It saves a lot of typing when I have to trace brackets after auto completion to add the semicolon instead moving to the next line.

<comment><USER58> In JavaScript the automatic semicolon insertion is almost universally reviled. Why not just have your editor insert the semicolons for you if it's such a pain to type them?

<comment><USER57> > Why not just have your editor insert the semicolons for you.

They don't insert the semicolons automatically as it can't tell if it's the end of line or I'm about to invoke a chained method etc.

Not sure what the down votes are about as it literally increases 2 to 3 letters of extra typing just to append the semicolon after auto completion.

> In JavaScript the automatic semicolon insertion is almost universally > reviled.

Why? There's literally no need except on a rare occasion. My IDE happily gets rid of JS semicolons and it's far easier to type.

Ruby and Python don't need one. Just feels tedious compared to other scripting languages.</comment></comment></comment>


Indo-Pacific Ocean warming is changing global rainfall patterns - <AUTHOR> https://phys.org/news/2019-11-indo-pacific-ocean-global-rainfall-patterns.html <comment><AUTHOR> The changing rain patterns are getting more noticeable. I am in agricultural trade and have been noticing a lot of crop size and quality variations because of unseasonal or untimely rains. For example if rain happens 20-25 day before the expected period the flowers get destroyed so you get fewer fruits. Or when the rains are 15-20 days later than expected the fruit quality and size is as not good as the fruits didn't get the water when growing on the trees.</comment>


Show HN: My friend misspelled "which" command, so I created this script for him - <AUTHOR> https://gist.github.com/shanielh/ca5ff87d7d7b43394224a34f0ee0d20f <comment><USER2> This is fun gag to play. But something that would really awesome would be if you could call your script if an unknown command is run and have the script look for a command that's most similar to the misspelled one and ask if that's what the use meant (or even auto run the corrected command).

<comment><USER3> Sounds exactly like this: [https://github.com/nvbn/thefuck](https://github.com/nvbn/thefuck)

</comment></comment><comment><USER4> Haha, nice! Which will be the next word that you will convert in something funny?

How about: deer/dear or die/dye

:)</comment>


DOJ plans to strike against encryption while the Techlash iron is hot - <AUTHOR> https://cyberlaw.stanford.edu/blog/2020/02/doj-plans-strike-against-encryption-while-techlash-iron-hot <comment><USER2> Why does this say that the DOJ has been pushing for this since 2016?

They have been pushing for some variation on this since basically forever. I first became aware of it back under Clinton with the [https://en.wikipedia.org/wiki/Clipper_chip](https://en.wikipedia.org/wiki/Clipper_chip). And the debate has been essentially the same since.

Law enforcement wants to be able to break security, and promises that their super secret, super safe system will provide everyone else protection from evildoers while letting law enforcement find the bad guys. Cryptographers have maintained that when you create a back door, it is a question of time until it is found and publicized.

And the back door doesn't even have to be found to be abused. Because it will be made available to law enforcement and the courts. Which are surprisingly easy for third parties to subvert. And which are happy to build programs for themselves that break the rules that they are supposed to follow. (Snowden anyone?)

Success has gone to both sides. But on the balance, the cryptographers have been right.

<comment><USER3> > Cryptographers have maintained that when you create a back door, it is a > question of time until it is found and publicized.

Why would it not be possible to create a system that required several manual and offline steps in order to break the encryption?

For example (and perhaps similar to offline cold storage of bitcoin) why couldn't a system be designed whereby 3 or more people in geographically diverse areas were in a position to agree that a request for information was legitimate (by court order) and thereby produce what is needed to unlock certain information? So one person would not have the key or access.

After all right now you have a case where a single person (the owner) is able to unlock information. The feeling is a back door can be hacked. What if it's not a back door though?

<comment><USER4> Apart from what others said, there is also the following problem. People won't like this and will start encrypting traffic with non-compromised algorithms. Given that properly encrypted traffic appears random, how would you enforce the requirement that everyone uses the state-sanctioned, compromised algorithm? In order to check and enforce, you'd have to turn this into an online, warrantless, dragnet-style system, the very thing you were trying to avoid. A contradiction.

It's not feasible to ban people from using their own encryption unless you plan on severely restricting their freedom.

<comment><USER5> Law enforcement likes to talk about big, scary threats like terrorism, because those make the public more likely to accept their position.

The article below argues that the real use case for breaking encryption is to catch everyday criminals, not to go after shadowy Bond villains. Would the public still go for it, if they looked at it this way? Probably not...

The Encryption Debate Isn't About Stopping Terrorists, It's About Solving Crime [https://www.lawfareblog.com/encryption-debate-isnt-about- sto...](https://www.lawfareblog.com/encryption-debate-isnt-about-stopping- terrorists-its-about-solving-crime)

Edit: And most everyday criminals are not technologically savvy. Half of them probably have a hard time using Telegram safely.

</comment></comment></comment></comment><comment> caleb-allen A small anecdote.

A few years ago in an undergrad business class, we were having some discussion and the topic of encryption came up during one of my presentations. A student asked a question related to the ethics of encryption (I don't recall exactly what), and I was clearly confused by the question.

To clear up confusion, the professor asked those who thought encryption was "bad" to raise their hand, and at least 60% of the class raised their hands.

It was pretty jarring to me, and makes me pessimistic about the outcome of a DOJ campaign to demonize and regulate encryption

<comment><USER6> It sounds like a majority of the students had no idea what encryption was and because the authority figure (the professor) asked them whether or not it was bad they just went with it? I'm having trouble understanding why people would say mathematical functions are bad.

<comment><USER7> Encryption allows data to be locked away from the government including law enforcement and prosecutors in a way that was nearly impossible for the average citizen a few decades ago. Warrants can't break encryption like they could doors or locks. As much of life moves to the digital world and becomes encrypted, that can be a drastic change in how the justice system works. Pro- encryption people need to keep this in mind when talking to anti-encryption folks. Criminals being able to hide evidence is a serious concern for the average person.

<comment><USER8> > Criminals being able to hide evidence is a serious concern for the average > person.

 _Suspects_. _Alleged_ criminals. Until convicted, they're not criminals. The government does not have an unlimited right to collect all information; they have a limited, judicially controlled right to _try_ to collect information.

One key detail: strong encryption does not prevent investigations from targeted collection of information, such as through physical surveillance, bugs, etc. There are many tools available to law enforcement, those tools are just less _convenient_. Framing it that way helps: in order to make investigations more _convenient_ , the DOJ wants to prevent anyone from using secure communications.

<comment><USER7> >Suspects. Alleged criminals. Until convicted, they're not criminals.

And even after they are convicted, they and their associates are still protected by encryption. Encryption protects everyone equally. That is viewed as a positive by pro-encryption people and a negative by anti-encryption people.

>The government does not have an unlimited right to collect all information; they have a limited, judicially controlled right to try to collect information.

This the point of warrants. The problem of massive warrantless collection of data by the government is a bigger and separate issue. I personally think encryption is a valuable tool to address the symptom of that problem, but it does nothing to actually fix problem of a corrupt and/or authoritarian government. One of my personal annoyances with the tech community is that we have a tendency to try to work around any governmental problems as if that solves the issue while making no attempt at fixing the root cause.

<comment><USER8> > One of my personal annoyances with the tech community is that we have a > tendency to try to work around any governmental problems as if that solves > the issue while making no attempt at fixing the root cause.

Agreed. We need to produce technical solutions, _and_ effect policy solutions, _and_ get a lot better at PR and rhetoric.

</comment></comment></comment></comment></comment></comment><comment><USER9> > the "techlash" by Congress and the public "in the wake of myriad privacy > scandals" and the 2016 election

This just makes my head explode. Because tech companies tend to be poor at privacy, let's use that logic to make it so the government can invade your privacy anytime they want?

<comment><USER10> This is a world where (at least it seems to me) the same people are against net neutrality legislation but want the government to regulate Facebook. By the time you get into the nuances of why the tech companies support encryption in some cases, you've lost the PR game.

</comment></comment><comment><USER11> Questions to the public should be phrased: "Do you want Chinese style surveillance to be advanced in the United States?"

<comment><USER12> +1. This is something tech bros don't seem to get, while politicians get very well: the majority is driven by emotions and has small cognitive ability, but they vote and thus arguments to win their vote must be trivial emotionally charged ideas. A politician says "encryption is a tool of criminals!" and those who start arguing in the rational plane have already lost; instead, the answer should be "lack of encryption enables Chinese style totalitarian communism!" \- no need to explain the details, just push their "scary communism" button and let the public contemplate on the "crime vs communism" topic.

<comment><USER13> Agreed. I wish I did not have to agree, but framing has proven to be very important.

</comment></comment></comment><comment><USER14> Isn't the tech lash for the complete opposite reasons? The fact that too many people have too much of our data? Why would people (outside of effective propaganda, which would be true even without the tech lash) support something that makes their problems worse?

<comment><USER15> Exactly. But for the people that want that data, for the people who will pay for it, FUD is a great political tool, and this issue is too subtle for most people to get. I've tried to explain to my family, how the abdication of private behavior logs to some companies is creating economic/political inequality that may forever destroy norms of fairness & competitiveness that we enjoy, but they just don't get it...

For example, _a friend_ worked at a proprietary hedge fund of a major US bank that was looking into the private accounts of their customers to drive trading decisions. Other investors can't compete against that, stock market investment is no longer fair. And you've broken a fundamental component of the economy, a fair & transparent investment system.

</comment></comment><comment><USER16> So terrorists will use one-time pads and other strong encryption and everyone else will have their information exposed on a massive scale when the backdoors inevitably are exploited.

<comment><USER17> I look forward to the day when one time pads are the norm for general encryption.

A scifi novel I read, "A Deepness in the Sky" described how the pads themselves were a valuable item of trade. I don't think it's farfetched to imagine purchasing OTP data to use with internet browsing, the way we buy yubikeys to use with passwords. It would be a far simpler encryption scheme than those we currently use, and that simplicity would make it easier to catch bugs like heartbleed in the future.

How hard would it be to extend the ssl protocol to allow the use of OTP pads, where available?

<comment><USER18> One Time Pads are perfect, except for the rather crucial problem of key exchange. You have to meet your intended recipient irl at some point to exchange pads, and I don't fancy meeting up with every sysadmin who's server I want to access some HTML files from.

<comment><USER17> That's the point of my second paragraph. The pads would be an item of trade. You buy an 'OTP yubikey' with 2GB of otp data for each of the top 50 websites, plug it in, and you're good for a month. The website spends 10k on a petabyte of otp data.

<comment><USER19> So you can only securely access the top 50 websites, and need to go in person to buy the key.

That sounds like a beyond ridiculous system. We can do better.

</comment></comment></comment></comment></comment><comment><USER20> I was talking to a layperson about encryption and privacy and they were very much against both interestingly. They compared encryption to wearing a mask in public and said if people don't want to be noticed (w.r.t privacy and encryption) they shouldn't be "participating" (it was unclear what they meant by this).

Just goes to show you how the average person thinks about these things. I have to admit I wouldn't like it if people wore masks in public in a way where I couldn't recall their face, but I don't think that's necessarily the same as encryption, but I guess I see the comparison.

<comment><USER21> Ask them if they'd be ok with the mailman reading all their ingoing and outgoing mail. If they say "Yes", at least they're being consistent.

<comment><USER22> Dangerous analogy to offer in an argument. The easy reply: "The Government can get a warrant to read my mail today. All I'm asking is for the same capability online, so they can get warrants to read pedophile and terrorist messages"

<comment><USER23> And isn't that a valid point to make?

<comment><USER22> Yeah. But I disagree with the larger position it argues for. Like all "real world" analogies applied to digital concepts, there's a sort of impedance mismatch.

In the real world, resources are naturally constrained. It's usually impossible to read everyone's mail in real time and retroactively pull up the contents of a letter sent 3 years ago. This limitation vanishes with online communications. Encrypted messages can be stored indefinitely and later decrypted.

The super safe backdoor we build today could very easily be used by a tyrannical regime a decade from now to get dirt on everyone. We can dream up all sorts of technical solutions that allow for a backdoor, but make it really hard to abuse, but at the bottom, those solutions rely on the government obeying their own law.

</comment></comment></comment></comment></comment><comment><USER24> I guess it comes down to who are you more afraid of? Terrorists and pedophiles or law enforcement with unlimited power and resources to spy on you and imprison you. Of course it's a false choice anyway, if encryption is legislated away the bad guys will very easily continue to encrypt their communications anyway, after all you can communicate with someone by shooting a wall in a game of halo if you want to.

</comment><comment><USER25> We tried to respond thoughtfully to each of the strange arguments made by the DoJ regarding the need for encryption backdoors to protect children:

[https://blog.nucypher.com/todays-kids-need-end-to-end- encryp...](https://blog.nucypher.com/todays-kids-need-end-to-end-encryption/)

It's difficult at this point to think that the DoJ is arguing in good faith.

<comment><USER26> > It's difficult at this point to think that the DoJ is arguing in good faith.

I think people in the tech industry, and especially people working on security or privacy, have known this for over a decade. Unfortunately, the public doesn't pay enough attention to the issue. And why would they? They have enough things to worry about, why pay attention to one of the things that is currently working?

It's unfortunate that we're not that good at PR.

</comment></comment><comment><USER27> You first DOJ. These folks want back doors so they can read everyone's traffic, but once you put a back door in an encryption standard, it affects everyone.

<comment><USER28> My favorite interview over the last few weeks is from NPR when a guy in law enforcement said that police don't even use that type of encryption (that normal people use) as if he forgot that his police radio, payroll, camera footage, information storage, are all most certainly protected via encryption.

<comment><USER29> I found this exchange amusing as well, for a slightly different reason. The gist of his point was that "who needs this level of encryption, other than maybe the military?".

Substitute guns instead of encryption and see how that fits.

</comment></comment></comment><comment><USER30> Interesting to read in context of the fact that public sentiment surveys suggest there is no "techlash" at all.

<comment><USER31> I agree. It kind of feels like the media is pushing a "techlash" narrative where there is none.

</comment></comment><comment><USER32> This is genuinely threatening to too many interests in the US, will not pass. Much smoke, but no heat, just like the last few times its been proposed. They will not get a master key to everything lol, nobody trusts DOJ like this. The people in power have dirt to hide too, just like you and me.

</comment><comment><USER33> This will just push people to open source applications and peer to peer networking. Basically, devolve back to the early days of the internet with regard to person to person communications.

How is the DoJ going to force Signal or even Telegram to add a back door?

<comment><USER34> Well, during the Cold War the feds declared encryption to be "Auxiliary Military Equipment," listed on the USML [1]. It was illegal -- prison time illegal -- to ship software which could encrypt communications outside the USA up until 1992 [2].

I'm old enough to remember the tail end of this and it was absolutely absurd, yet still very real. I remember Zimmermann being investigated by the feds [3]. Zimmermann was smart to tie publishing PGP to the First Amendment. Something like Signal in those days may well have resulted in charges and a conviction.

Never underestimate the potential for folly when it comes to government regulation.

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

[2] [https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...](https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States)

[3] [https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_i...](https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_investigation)

<comment><USER17> I wonder if encryption could be tied to the Second Amendment as well. I'd be interested in the legal theory discussing that.

Many of the arguments I've seen here defending encryption are basically the same as those defending guns.

</comment></comment></comment><comment><USER35> Encryption keeps the government out of things it shouldn't be snooping on, and also keeps other governments out of those things. If key escrow is mandated, it would be cracked to high heavens by parties unfriendly to the US within a year or two,tops, mark my words. Then what?

</comment><comment><USER36> Shouldn't the US government be pushing good encryption? I wonder what sort of world we would be living in if the NSA had spent 1/2 as much time over the last 10 years trying to protect Americans from hacking as they do trying to spy on Americans.

<comment><USER37> Exactly. I can't believe I'm supposed to pay for taxes for this. The government is supposed to be for the people, not control the people. I don't remember ever having voted on or agreeing to be spied on for no reason.

</comment></comment><comment><USER38> Privacy is extremely important, especially as also our democratic governments cannot be trusted always, at least this is the impression I get when reading the interview with the UN Special Rapporteur on Torture concerning the Assange case: [https://www.republik.ch/2020/01/31/nils-melzer-about- wikilea...](https://www.republik.ch/2020/01/31/nils-melzer-about-wikileaks- founder-julian-assange)

</comment><comment><USER39> MITM-as-a-business has been nothing but a slow motion train wreck destroying individual liberty. FAANG may bicker with the DOJ/NSA (and Ma Bell) about who is in control of all the surveillance data, but none of them are fighting for _we the people_. They're all just jockeying over who gets to rule.

The sane response to corporate totalitarianism is most certainly not government totalitarianism. Sadly with how the two political salesteams frame a false division merely over different flavors of authoritarianism, this has a good chance of working.

As always, the true answer is trustable software running under the control of users ourselves. Unfortunately, we will have to see how bad things get before most people are driven away from all of these centralized attractive nuisances.

<comment><USER40> Very true. Nobody cares for the individual citizen. It's just a power struggle by large players on the backs of the little guy.

</comment></comment><comment><USER40> Are there any concrete proposals on the table that can be looked at?

This feels to me like one of the typical debates where people are shooting at each other but nobody understands what they really are talking about.

<comment><USER41> I think you're mistaken.

Virtually any proposal that the government might offer will be a key escrow. We already know it's bad and why it's bad, because it's been debated for decades. I don't think there are any more novel solutions that should revitalize the argument.

The problem isn't that there aren't enough oversight mechanisms or checks to prevent abuse. The problem is that the design has unfixable security defects.

<comment><USER40> You say "might offer". Have they offered anything?

<comment><USER42> "Offer" is perhaps an overly positive term. The DOJ has issued a number of speeches, letters, etc. insisting that tech companies must build a backdoor to let the government decrypt messages as required.

<comment><USER40> I know but I have never heard any details especially how they want to keep the backdoor secret. Cracking the backdoor would be such a high value target that a lot of people would spend insane amounts of money and energy on it.

<comment><USER8> Do not under any circumstances let the discussion move from "whether" to "how". Reject the premise of the question. Such a system _cannot_ be built; the requirements are broken. Treat it as though someone asked you to build a system that solves the halting problem, or factors products of large primes in linear time: the correct direct response is patient explanation of impossibility, and the correct indirect response is good PR from real security experts who understand how to do good PR.

<comment><USER40> I don't think it's right to reject something outright. You should always give people the opportunity to show what they have. Then take a look at it and decide whether it's good. A strong indicator for a scam is that they won't show anything when asked for details. Then things should get rejected.

<comment><USER8> I'm not suggesting a refusal to listen to the question. I'm observing that it's dangerous to accept the premise of a question that may move the goalposts, without first noticing the implicit premise or differing definition, and explaining why the premise or definition is faulty. Accepting the faulty premise moves the line to "so you just need to come up with the right technology", which then moves to "what's the most secure system you can build while still having a backdoor". The right answer to that is not "here's what we could hypothetically build", it's "by definition we cannot build a secure system with a backdoor, and _also_ here are all the additional problems that a backdoor would introduce".

By all means, fully listen to proposals, in order to understand the misconceptions and better address them. Or, in some cases, it's useful to listen to proposals to anticipate upcoming security threats and build a more robust security model. For instance, the potential threat of compromising CAs led to the invention of Certificate Transparency, which almost completely eliminates that possibility.

We also need to get a _lot_ better at rhetoric and PR.

<comment><USER40> "so you just need to come up with the right technology"

That line is not OK. If somebody wants something and you say you are not able to do it then it should be on them to prove you wrong.

Reminds me of work BS. You say "it can't be done in the timeframe". VP response: "you are just not working hard enough". It's a nice way to manipulate the conversation.

Technologists definitely should get better at messaging and arguing with bad faith actors.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Is this news or is this a blog post? I understand it's very informed, and I don't necessarily mind opinionated journalism, but this seems to be speculating as to the motives of the FBI.

To me, this seems like only one very passionate side of an important debate. A big question I have is, "how likely is this legislation to actually become law?" UK and Australia passed similar laws, sure, but they also banned guns and that's not gonna happen here.

<comment><USER44> It's a blog post, as stated in the URL and at the top of the page.

</comment></comment><comment><USER45> Sorry, did I miss something? WTF is the "techlash"?

</comment><comment><USER46> OK, so how have things been going for the UK and Australia? Has anything concrete actually happened as result of the legislation that has helped law enforcement get access to encrypted communications?

In other words; does legislation actually make a difference in practice? Or is it just some sort of pointless political signalling?

</comment><comment><USER47> I think the term "techlash" is an attempt to shape opinion on the existence, source, nature and of the problem being discussed.

Really, the issue is "corplash", or backlash against large corporations abusing privacy... and even then, it's really not the corporations' fault, it's the fault of the US government for not making what they're doing illegal.

Corporations are actually obligated to make money for their shareholders. A corporation does not have the free will to choose a moral course over those obligations, especially in the US.

Corporate officers have to seek out and take advantage of every opportunity to make money available to them or otherwise they may well lose their jobs or even be sued.

Since it's not illegal to make money off of invading privacy, corporations are obligated to try provided doing so won't negatively impact their profits.

Calling it "techlash" implies that somehow tech is at fault, or even large tech corporations, but in truth the US Government is at fault for not updating privacy laws for the computer age. The term directs anger away from the real culprits.

</comment><comment><USER48> Real criminals won't use such platforms anymore, but use custom end-to-end encryption. They'll find people to make them something, if need be by using steganography.

This will only hit innocent people or low-level criminals, the real bad actors will find ways around it.

</comment><comment><USER49> People eager to give others power over them don't really appreciate what it's like to live under a totalitarian state.

The older I get the less hope I see of people learning anything from history. Perhaps we really are doomed to repeat it.

</comment><comment><USER50> I'm guessing this is cryptographically impossible but are there any schemes that allow 2 different keys to decrypt to two different messages for deniability? Perhaps a key containing a seed number to adjust the algorithm?

<comment><USER51> This is a neat idea but I also have no idea if theoretically feasible or not.

</comment></comment><comment><USER52> So there is a "techlash" against privacy abuse now, and DOJ thinks it's a good idea to push even further privacy breach by fighting encryption? How stupid is that?

Hopefully they'll get even a stronger push back.

<comment><USER47> I think the term "techlash" in the blog is an attempt to shape opinion on the source of the problem.

Really, the issue is "corplash", or backlash against large corporations abusing privacy... and even then, it's really not the corporations' fault, it's the fault of the US government for not making what they're doing illegal.

</comment></comment><comment><USER53> As soon as law enforcement is granted any exceptional access they'll go on to claim they need more access and less oversight.

As soon as they're granted such access it will become an irreversible status quo.

</comment><comment><USER54> Seriously question, how are they going to stop me from downloading signal from source, building it locally, and installing it on my and everyone i knows cell phones?

<comment><USER44> Why would they try to stop you, when they could just order Apple or Google to push out a backdoored update to the OS?

<comment><USER55> Would Apple or Google be able to get a backdoor to Signal? Edit: nevermind, I think I understand what you're suggesting.

<comment><USER37> The obvious example that comes to mind is a simple keylogger.

</comment></comment></comment></comment><comment><USER56> If legislation was passed, couldn't Apple essentially move it's HQ to a different country where there are now laws against encryption?

</comment><comment><USER57> Fantastic, the party that is all about personal freedoms is waging a war against personal freedom. We have come full circle.

</comment><comment><USER58> If you were forced to design an exceptional access system that minimized abuses and risks of compromise, how would you do it?

<comment><USER8> Leave whatever jurisdiction was attempting to force me to build something unethical, and after being safely out of that jurisdiction, disclose absolutely everything I can about the attempted coercion.

<comment><USER58> In that case you would not be forced, at least in a more extreme application of the word.

Regarding ethics, my opinion is that it's unethical to offer strong E2EE to the masses at scale, without considering the needs of LE.

<comment> CKN23-ARIN LE in which jurisdiction(s)? If the E2EE is widely used, the "needs" of local LE will be varied and often contradictory.

<comment><USER8> This is one of many excellent arguments against such backdoors. The US would like backdoors into everyone's communications, and doesn't want anyone else to have them. China would like backdoors into everyone's communications, and doesn't want anyone else to have them. Every country and jurisdiction would like backdoors into everyone's communications, and doesn't want anyone else to have them.

<comment><USER58> In America, our govt

</comment></comment></comment></comment></comment></comment><comment><USER59> Their attempts will make no difference. I will use encryption and they can't do Jack shit about it

</comment><comment><USER60> I might be ok with this, but not while incompetents like Trump are at the wheel.

<comment><USER61> Which previous administration would you be ok with passing these laws?

<comment><USER60> Roosevelt

<comment><USER61> If Roosevelt enabled/required these back doors, what would stop all future administrations, including the current one, from doing what they want? IE, why is it any different for a past administration to make these changes compared to the current administration? Expansions of executive power tend to be permanent.

</comment></comment></comment></comment><comment><USER58> I find it interesting that the hn world is largely unified in beliefs about the trade-offs of exceptional access that aren't necessarily true. Perhaps this is a cultural top-down tribal mentality borne of an adversarial arrangement between the billionaire oligarchs behind the startup scene and the government which serves to offer counterbalance against unchecked power.

I personally find it reprehensible that large trillion dollar tech corps wash their hands of responsibility for the safety of citizens by offering strong encryption to the masses.

I'm personally okay with secret police, but such things work better in secret. The calculus has indeed changed. Checks and balances within such secret societies do need to exist. I'm hopeful that tech geniuses will help to solve the problems regarding technical and social trade offs and risks behind exceptional access, instead of conforming to the often strict libertarian mentality of the sv community.

<comment><USER62> > I'm personally okay with secret police

What? Why are you ok with secret police? Where has this idea ever worked?

> I find it interesting that the hn world is largely unified in beliefs about > the trade-offs of exceptional access that aren't necessarily true.

Which trade-offs are you suggesting aren't true? The base claim is that back door access makes security weaker. Do you disagree?

<comment><USER58> Yes, it's serious (in response to your handle). I don't think it's necessary to create a throwaway to respond and is also against hn policy.

I've been downvoted to oblivion simply for stating my view; also not necessary.

Secret police worked when criminals were put away with parallel reconstruction, for instance. (This being borne of limitations with the anachronistic constitutional notions of civil liberties in the rapidly evolving digital age). I'm all for reducing abuses of surveillance systems, but frankly it's tech oligarchs who own us, not as much the nsa.

"You can't stop math." Not true, strictly anyway. You can ban tech oligarchs from using unbreakable E2EE which slows it down and reduces the proliferation of digital entropy.

Backdoors are an antiquated way of implementing exceptional access. The proper way is to provide third party access that is truly exceptional (living up to the name), and not based on flaws that a malicious actor or rogue nation can break. Instead of E2EE, how about building E2E2EE. Doesn't need to be measurably weaker.

Sorry on my phone, response isn't nuanced.

<comment><USER63> > _I've been downvoted to oblivion simply for stating my view; also not > necessary._

I personally downvoted because I believe your statement is wrong in fact and problematic in opinion.

> _Secret police worked when criminals were put away with parallel > reconstruction, for instance._

Parallel construction is a morally dubious method of hiding illegal and unconstitutional activity on law enforcement's part. What crime was truly committed to warrant law enforcement's action is therefore hidden.

Using the idea of parallel construction to support secret police is likewise dubious.

> _"You can't stop math." Not true, strictly anyway. You can ban tech > oligarchs from using unbreakable E2EE which slows it down and reduces the > proliferation of digital entropy._

When you outlaw guns, only outlaws will have guns.

It's illegal for citizens to download and distribute music and movies too, but illegality doesn't stop them from doing it. You _might_ block tech oligarchs from using it, but you won't be able to block citizens from using it.

Likewise when you outlaw math, only outlaws will have math. Banning tech oligarchs from using unbreakable E2EE won't undo the fact that that encryption has already been created and disseminated in open source repositories.

> _The proper way is to provide third party access that is truly exceptional > (living up to the name), and not based on flaws that a malicious actor or > rogue nation can break. Instead of E2EE, how about building E2E2EE. Doesn't > need to be measurably weaker._

I have yet to see even a _single_ idea which isn't open to abuse by _someone_ , whether it's law enforcement or citizens. And, frankly, the constitution's goals are fairly clear: citizens have rights and law enforcement is prohibited.

<comment><USER58> Thanks for responding. Which part was factually inaccurate?

<comment><USER63> > _Secret police worked when criminals were put away with parallel > reconstruction, for instance._

It wasn't the secret police which worked. It was the parallel construction.

> _"You can't stop math." Not true, strictly anyway._

You can't stop math.

> _Backdoors are an antiquated way of implementing exceptional access. The > proper way is to provide third party access that is truly exceptional > (living up to the name), and not based on flaws that a malicious actor or > rogue nation can break._

This statement is a fantasy. There is no way to provide third party access that is "truly exceptional" that a malicious actor or rogue nation can't break.

> _Instead of E2EE, how about building E2E2EE. Doesn't need to be measurably > weaker._

Anything weaker than E2EE is measurably weaker than E2EE. E2E2EE is measurably weaker than E2E2EE.

<comment><USER58> It was the secret police with pr

You can stop math. Legally stop fb from using E2EE. You've stopped math. You haven't stopped some people from using it. But you've prevented common people from having default usage of that math.

Disagree. Don't use key escrow. Find a better way. Two parties or three parties; three doesn't have to be significantly more susceptible than two

Apologies on the wording. Significantly weaker, not measurably. My mistake.

<comment><USER63> > _You can stop math. Legally stop fb from using E2EE. You've stopped math. > You haven't stopped some people from using it. But you've prevented common > people from having default usage of that math._

No, you haven't "stopped math". You've enacted a law and stopped Facebook from using end-to-end encryption.

Math is universal. Math is something that should never be outlawed. Math is a fundamental right, an irrevocable truth based solely in fact. You can sooner stop alcoholism by outlawing alcohol than you can stop encryption by outlawing math. The idea of outlawing math would put us hundreds of years behind today; to enact a truth based on the church's "do this because I tell you it's true" instead of "understand this for yourself, I cannot tell you what is true". Outlawing math is dangerous and I cannot believe you are trying to make such an argument in good faith.

> _Find a better way._

I do not believe there is a better way. You don't understand the math behind it. Instead of even trying to understand the math which is already widely understood by many, you instead want to make that math illegal and create your own. You don't even want to spend the mental effort to do that much: you demand others to do it for you.

> _Two parties or three parties; three doesn't have to be significantly more > susceptible than two_

This is factually false. The third party is a moving party which changes every moment. You _can not_ meet that and still be "secure". It is antithetical to the very notion of encryption.

<comment><USER58> Semantics aside, if FB isn't allowed to use the math behind E2EE, they've effectively been stopped from using math. Just trying to avoid getting into the weeds.

Similarly to you questioning my faith in the matter, you're ignoring my argument, ostensibly not in good faith, either. I'm suggesting to build a better mousetrap. It may not be perfect but might help maintain and improve civility in society.

Alcoholism and alcohol aren't really a great analogy.

I understand math better than you may realize. You said that you don't believe there's a better way. You've effectively conceded that the existing key escrow solutions with the known risks are the best that can be done. I'm suggesting to do better. Find a better compromise.

Three party access in current incarnations may have flaws but the statement isn't factually false. It's simply undiscovered.

Conflating ideals with beliefs can be tricky..

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER64> Conspiracy theory: The NSA hamfistedly contributed to various leaks in the same way the CIA gave guns to terrorists, i.e. by providing various groups with the tools they'd need to break into American companies.

Now they can capitalize on it - "see, tech companies can't be trusted with your data. Trust us instead."

</comment><comment><USER65> I've posted plenty of times on HN about the danger of the government being overly involved in tech and the last thing you should want if you value your liberty is more government involvement.

I've also warned that giving government more power to "protect" people from big tech would come back to bite the very people who for some strange reason trust government.

Every time I've been downvoted to oblivion.

Now the chickens are coming home to roost.....

<comment><USER66> So, you can't trust the government to oversee the tech companies.

You can't trust companies to protect privacy.

You can't trust voters/users to make good decisions on voting for the government or choosing the "right" companies to support.

That doesn't leave a lot of options, unfortunately.

<comment><USER65> It's called free will.

You can logout of Facebook

You can not use Google and use an ad ad blocker.

You can buy online from some place besides Amazon

You can not buy a mobile phone running an operating system written by an ad company.

What you can't easily do is change your government.

<comment><USER39> I'm all for protecting oneself in the framework of anarcho-capitalism, as it the default state of nature. But most people agree it is the government's place to prevent aggression between members of society. And pervasive surveillance is aggression.

Suggestions of individual actions are worthwhile, and it behooves everyone to take all of the personal steps they can to protect themselves. But the existence of individual actions culminating in a hypothetical path to opting out does not justify harm being done when people fail to live up to them.

<comment><USER65> So generically, who should I be more worried about having my information and having more power? Google to advertise to me better or the government who can take my stuff based on a vague suspicion via civil forfeiture and has the power to send me to jail?

More personally, as a Black guy living in the mostly White burbs in the south - ie looking suspicious for living my life - who should I worry more about big tech (that indirectly provides for my livelihood) or the "justice system"?

<comment><USER39> > _who should I be more worried about having my information and having more > power_

Wu. Constructing a "lesser evil" choice is simply a way of justifying evil.

> _Google to advertise to me better_

It's not mere "advertising". Google's surveillance trove will be exploited for economic gain in unenumerable ways. Sort individuals into classes, market a message of safety, and discriminate to keep the undesirables away - it's the age old playbook. The results of this paradigm will eventually be sold directly to the de jure government, as Experian et al currently do, making the distinction moot.

> _big tech (that indirectly provides for my livelihood)_

So you've chosen to align yourself with a more-distant oppressive power, hoping that doing so will buy you power to defend against a closer oppressor. Sure that may be prudent, but it is not morally right nor is it sustainable. And backfitting from "what is" to "what should be" is never a good idea.

Less abstractly, yes the US government is corrupt and generally pushes garbage like this EARN act. But that isn't an intrinsic argument against anti- totalitarian regulation akin to the GDPR. Rather the lack of the action on the latter is better seen as further evidence of said corruption.

<comment><USER65> _Constructing a "lesser evil" choice is simply a way of justifying evil._

On the scale of "lesser evil" the government being able to arrest, harass, violate civil liberties and lock someone up is off the charts compared to what big tech can do.

 _Sure that may be prudent, but it is not morally right nor is it sustainable. And backfitting from "what is" to "what should be" is never a good idea._

So I should be more worried about what you consider is "morally right" instead of putting myself in a position where I can afford a competent lawyer - instead of an overworked public defender - to keep me or my family from being railroaded by the criminal justice system?

 _But that isn 't an intrinsic argument against anti-totalitarian regulation akin to the GDPR. Rather the lack of the action on the latter is better seen as further evidence of said corruption._

You realize that you want to give the government more power that in my parents lifetime (who are still alive) has said that interracial marriage should be illegal, segregation should be legal and even as recently as the 80s has had laws making it crime punishable by jail time for adults of the same gender to have sex?

As far as big tech vs the government, big tech has never discriminated against me when trying to get a job. I feel the same way about tech vs the government that Muhammad Ali felt about going to the Vietnam War. I'll leave it for the readers to search for what he said.

<comment><USER39> Your comment comes from a perspective of having been abused. While I respect your struggle, stressed analysis is not good when trying to foresee where the next source of abuse will come from.

The commercial surveillance industry is not currently engaging in abuse on the scale the government has previously committed, but the government is not presently doing so either! Yet we are rightly concerned with setups that make such things possible - for example I presume you don't just chuckle at white supremacy protestors for being on the wrong side of history, but view them as a threat that could gain momentum any time.

The commercial surveillance industry is currently poised with a more invasive scope into everyone's personal life than a government could ever have, operates autocratically, and actively resists the desires of its targets to opt out (eg Do Not Track). That last bit puts them deeper into the domain of wielding governmental power than a straightforward monopoly. Trusting the people controlling these companies to be benevolent is a setup for failure.

> _You realize that you want to give the government more power_

I don't see something like the GDPR as giving the government more power, but rather just shifting it around. Government and corporate power are merging regardless (hence this thread), and it's better to have the result under democratic control than fully autocratic. The real solution is of course for people to shift to using software that they control (and hence can actually _represent them_ ), but unfortunately that seems a long ways off, or at least unevenly distributed.

<comment><USER65> You realize that the government is trying to get the right to have backdoors to allow for surveillance.

As far as what the government is presently doing. The "war on drugs" is presently more focused on minorities while drugs are treated as a "disease" in rural America.

Presently, my son had four or five keys on his key ring that looked alike and he fumbled through them trying to get in our house. I made him a different color key so the overzealous neighbors who look at him strangely wouldn't harass him (or call the police) for breaking into his own house.

So yeah, I have a good reason to be worried about the government wanting more power to surveil people and to have a back door for encryption.

<comment><USER39> Yes, I do realize. I do not think this is a good thing. I think the government is currently doing plenty of terrible things. It has done bad things to me personally. The magnitude of those bad things would have been from three times to infinitely worse if I were Black.

You keep repeating these assertions as if we're not on the same page. We are on the same page here.

Where we diverge is that you're taking this indictment, and extrapolating it to an indictment of _all_ government regulation.

I'm actually predisposed to this point of view as well, with regulatory capture and all, but the fact of the matter is that the synergy of government and corporate power _is going to happen regardless_ of which rights we attempt to obtain for us individuals. And so we might as well try to reserve an ability to opt out of commercial surveillance as part of their bargain.

Commercial surveillance eventually feeds right into that _same_ government which has abused you and your family, while being much more agile than blunt government programs. As far as I'm aware, there is no law which requires Experian, Lexisnexis, etc to pass their surveillance data to all levels of government, including the local cops that you're rightly worried about. They do so because it is profitable, and because power generally coalesces.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>