skysight-inc/HackerNews huggingface dataset:
>> We desperately need a way of conveniently distributing sandboxed, secure, auto-updating apps to desktops and laptops.

What's the proposal?

* App stores controlled by juggernaut companies, doing the app-screening?

* Signing web apps bu an authority?

* Writing in "safe" languages in java/rust/..?

* Java applets?

* Adobe Flash? Silverlight?

* Uglified, minimized encrypted JS code?

* or Win95 style self-extracting installers for downloaded apps, installed by users with no package management?

* Debian style package managers?
i dont expect site authors to give 2 shits about security when the alternative is ad revenue. that's assuming they even understand the security/privacy implications of spending 5 seconds to add that one-liner social sharing widget.

75% of web devs wont bother to consider it and the other 24% wont care.

it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is that most browser vendors get a cut of the ad revenue.

there's a massive need for a payment platform that allows for browsing ad-free but still paying directly for content as-you-go. i think Brave is trying to do this.

cryptocurrency may provide the privacy protections for this type of arrangement.
Fine grain virtualisation is pretty hackish in Linux, but it's part of the design of the Hurd.

On the Hurd you can trivially virtualise the filesystem (on Linux you need FUSE for that but it doesn't go far enough), there are user namespaces by default (on Linux they are a hack and that makes local privilege escalation bugs really bad), drivers run in userspace, so different users can have different views on the hardware, etc.

All of this is quite relevant today, especially on shared systems such as HPC clusters.

The Hurd is the only multi-server micro-kernel system with a Unix persona (other micro-kernel systems are either single-server systems or don't bother with a Unix-like persona). I find it a lot more elegant than Linux, which needs to move more and more things into privileged kernel space.

With the NetBSD rumpkernel the Hurd can reuse NetBSD device drivers in userspace.

There are a lot of things to like about the Hurd. If only it had more contributors! It's a great project that provides practical software freedom (like other high profile GNU packages), thereby liberating users from the root user.
The article doesn't make sense without an alternative. What open standard is being proposed to replace the open WWW?

Mobile apps and app stores are not a replacement for the open Web, and it can't reasonably be argued that locked-down mobile devices loaded with craplets and no root access are better than the WWW.
Not to me, it isn't. Care to elaborate? (Pointing out "there is a flaw in your logic" to someone who has a flaw in their logic is rarely very helpful unless you actually point out the flaw too.)
> It’s time to kill the web ... I’m going to review the deep, unfixable problems the web platform has: I want to convince you that nuking it from orbit is the only way to go

gee, those statements are bold. Not only JS or even the front-end stack, the author wants to kill the whole web and make a new one.

I can say it is not a first time I've seen an engineer seeing something imperfect and suggesting that everybody should immediately abandon it to make something better from the scratch.

Like many of you, I am looking forward to see the second part for a web alternative. What I am interested in is how the author wants to make his proposal as beginner-friendly as the web already is.
True story showing why coders who create things need marketing skills
Invictus Games 2017 Live Stream
> Machines 10000x faster, personal value/productivity: flat or below.

I'd love to hear an argument for this, personal value/productivity has increased massively in the last 15 years.
I asked you guys about image-saving because I was considering using Racket to build a new version of bard, and I thought I might like to both use image-saving during development and piggyback on a Racket implementation of it for use in bard's runtime. As I recall, you guys wanted to know what I found compelling about image-saving, but you didn't find it as compelling as I did.

I still might build a bard on Racket, but if so, I'll most likely build my own VM and implement my own image-saving solution for it.

Assuming, of course, that there are enough hours in the day, and enough years in a life.
Flux is not equivalent to Windows Events. The analogy is DOM Events. Also, Flux is not required for building web apps.

After this I thought that it makes no sense to read the article further.

For me the problem with web apps is low performance, slow load time. Another problem is people who try to push programming patterns from functional languages (like immutable values) into mainstream JS libraries. Please use Haskell instead if you love immutable values that much.
The use of "may" to mean "might" frustrates me. Usually the meaning is clear but sometimes it can negate the meaning of a sentence.
We are using a stateless document model for apps. You can select text on buttons. Madness.
Fun fact: The colorful Windows 98 explorer sidebar that is shown in the first screenshot was implemented as HTML (and Javascript), along with the desktop background (called active desktop).
What does it mean for you to consent? It means that. According to the worldview I have been expounding, I'm "just" a really complicated program running on wildly convoluted wetware. Whatever it means for a person to consent to something, is what it means for that pattern to consent.
What about it seems like a vulnerability? At best, this is an avenue for a phishing hack for getting someone to put in a bad URL and then send their credentials. No different than registering and convincing someone go to go facebooksecurityservices.com and log in with their Facebook account.
1,500 hours? That's nothing! These guys should give Civilization a go. (I say this only partially in jest. I've logged a few thousand hours playing the various Civs over the years. And, I'm not even a heavy player, compared to many.)
The web is way worse and less coherent than something like Cocoa, even though Cocoa is older. That’s because the former was designed for text documents.
> "Web development is slowly reinventing the 1990's."

> The 90s were slowly reinventing UNIX and stuff invented at Bell Labs.

Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1]

> "Buffers that don’t specify their length"

> Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever.

Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately.

1: https://www.cs.purdue.edu/homes/dec/essay.criticize.html
As Equifax Amassed Ever More Data, Safety Was a Sales Pitch
You are talking as if every country will accept you with open arms to become their citizen.
The thing is, though, the web is reasonable - for its intended purpose, which is displaying and interlinking documents. And despite the complaints, faults and shortcomings, it's even remarkably not as bad as it could be at being an application platform.

Throwing that out because it's less than optimal at a use case it was never intended to serve would be monumentally short-sighted. Just build something else and leave the web be.
Even if they were completely open source how would you verify that they are using the same software on their servers? That the hardware is not compromised?

Audit reports? How trustworthy are they if Symantec was able to provide good reports for such a long time for their certificate issuance when things were clearly not ok.
... I feel like I've read the same about terminal apps, tons of programming languages, etc. and it's again missing the point.

Nothing is reinventing anything. The code you write these days in Go, JavaScript whatever is still following the same principles as in the 1980s. All we do is swap out tools and languages, add comfort.
The article was a response to a guardian article that ultimately cited https://siliconangle.com/blog/2013/06/14/duckduckgo-the-pris...

> “By not storing any useful information, DuckDuckGo simply isn’t useful to these surveillance programs,” says Weinberg. “We literally do not store personally identifiable user data, so if the NSA were to get a hold of all our data, it would not be useful to them since it is all truly anonymous.”

DDG is "unfairly singled out" for good reason, namely that company representatives made an incorrect assertion. DDG is still useful for ongoing surveillance, as the article pondered:

> But what if DuckDuckGo provided a splitter-feed to the NSA? DuckDuckGo can claim without lying that they store no personal information, but that speaks nothing of a collaborating partner storing it.
Absolutely, let the server go to the advertiser and fetch the ad content to push, don't make the client do it. I'd go far as to say that any content coming from a 3rd party - even images - has caused more trouble than it's worth.
Coffee, please. Yes. Thank you very much indeed. Good day!
Here's another solution, from the late Pieter Hintjens: https://www.indiegogo.com/projects/edgenet#/
Controversial crime tracker app expands to SF with $12M in funding
It's probably not possible to evaluate this post without waiting for part two, where the author says they'll outline their plan for The One True Platform, because after reading part one I come away saying "yeah, so what?".

I don't think many people working on the web platform evangelise it as the most amazing software development platform that's ever existed. But they do recognise the reasons why it has proven to be as popular as it is, and what can be done to improve it. That's why we've got WebAssembly for native code, Service Workers for offline capabilities, WebGL for performant graphics, so on and so forth. Yeah, it's scrappy, but it has much more chance of being successful than some start-from-scratch idealised standard (that will have no security vulnerabilities, naturally) that someone just brewed up.

But hey! Maybe I'm wrong. Maybe part two will blow the web dev world away. But I'm not holding my breath.
So basically typosquatting? It seems to me that any service that doesn't show the SSL certificate (or the EV name) is vulnerable to this, not just Exchange on iOS.

Edit: It seem it doesn't check the SSL certificate either. But it's super easy to get a valid SSL certificate nowadays, so just checking the SSL certificate for validity wouldn't be enough.
Haha, no worries. I did.
As others have pointed out, solutions that work in Amsterdam, may not generalise to other parts of the world.

Over the last 15 years, a combination of power cuts, shoddy maintenance and cable theft have made traffic lights a lot less reliable in South Africa.

In some cities, like Johannesburg, drivers tend to follow the rules regarding broken lights, and treat them as four-way stops. In others, such as Durban, I’ve seen drivers barrelling through at high speed, hoping for the best.

Given the apparent wide geographic variation in dealing with this sort of thing, perhaps a more appropriate title for the article should be “What happens if you turn off the traffic lights in Amsterdam?”
When can I gene-therapy away my 'seasonal' allergies? As an otherwise-healthy thirtysomething, that's the big one for me at this time in my life :-)
While i understand the article and agree with it, i love programming webapps.
The combination of html/CSS is much easier (for me at least) to work with than most other rendering framework, also JavaScript while not perfect is very good for fast moving target, and with "extension" like typescript you can even manage very large application in a progressive way (you can mix js and typescript).

I also work with the android layout system and a bit of the iOs one, and they are a lot more confusing, (Constraint-layout fixed a couple of problem on android recently).
Currently i work manly with legacy asp.net app at work, and shiny all-js webapps at home, but i done a lot of work also with winform and android apps

Also the ability to update the app "on the fly" and be able to download only the part of the application that you need is pretty cool. Your can make your user always use the last version and quickly deploy hotfix.
I understand that this are not propriety desirable for every type of application but sometimes are game-changer.

What i really want to have is a lighter implementation, i think that Facebook did something similar with is Facebook lite app.

Here's a gist with what i really want for a layout/app runtime.
* Using a Url style system for retrieving resource.

* A binary protocol similar to protobuf,capnproto etc.. for talking with the server.

* A clear separation between the template and the data, so that i can cache the entire page and only request the data for populating it.

* A Module and a Permission system, with versioning (for backward and forward compatibly),maybe integrated.

* One way to store data (i personaly like key-value system, but i think a document system would be more suitable).

* A Unified syntax for html and css.

* a Component system(this is a big one), ideally the spec should only define a div-style generic container that can be specialised in a new component by adding to it, a name, style and optionally a script witch control is behaviour, (I'm not a fan of the web-component spec as it is).

What would you want from an alternative layout/runtime system for web-like app?
I'm really curious!

PS: I really hope there will be more engineering post about the Facebook lite app, it seem a concept really cool that could be used for a lot of other apps!

edit: adjusting formatting
I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval.

In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML is a lot more complicated, which matters a great deal if you're using non-memory-safe libraries for parsing. Also, because XML is so general purpose, you get things like libraries allowing deserialization of arbitrary objects from XML, which is a security nightmare.

That last point isn't a clean win because sometimes the same library will handle JSON and XML, and so you have to audit the use carefully. However, if you're sure that your serialization libraries only use JSON, its simplicity means that it shouldn't have that kind of deserialization vulnerability.

P.S. If you want to rag on JSON, that's fine. It's not a great format. But "it's less secure than XML" is not the tack I'd take.
Solving the problem with technology is 1000000 times easier than solving it from the "social" side.
Screening apps by a large company is not bad. Users don't want to guess whether the app contains malware or not. They would prefer someone do it for them.
But the problem is that the server is deciding for the user. If they want to show me sketchy ad content, they can go fetch it and send it to me as part of my request to them. Don't tell me to go get it myself.

If an ad server is malicious, let it be the web server that has to deal with them, not me.
3 vendors is still better than one.
But they aren't likely starting their own businesses, which is what we're discussing.
> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately.

If this was the case, it would be near-impossible to write HTML by hand. And if you're writing HTML with a tool (React, HAML etc.), the tool could be doing HTML escaping correctly instead. This isn't an issue with HTML, it's an issue with human error.
I did some research a few years ago and HP had one of the higher revenue streams per capita in the entire state. There's lots of money in the city government, but not a lot of results, which points you toward the underlying problems.
> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure.

Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java.

> Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems.

It's not buffer overrun in the "undefined behavior" sense, but rather problems relating to the need to parse text data, which can be tricky and susceptible to injection attacks.
And you can't block ads in youtube, instagram or fb apps.
"Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately."

How so? If you allow the user to send arbitrary data, and your handling of that data is where the problem lies, it isn't going to matter whether the client sends a length-prefixed piece of data. You still have to sanitize that data.

HTML, and whether it uses closing tags or not, is pretty much irrelevant to the way injection attacks work, as far as I can tell. Maybe I'm missing something...do you have an example or a reference to how this could solve injection attacks?
And yet, reportedly US pharmaceuticals spend more money on marketing and promotion (i.e. coddling up to the doctors who prescribe their products) than R&D.

https://www.washingtonpost.com/news/wonk/wp/2015/02/11/big-p...

https://www.sciencedaily.com/releases/2008/01/080105140107.h...
I think what he meant was "throw out the web as a platform for applications", not as a platform for document distributions.
I agree.

People seem to think that there was a time when the internet was better than it is today. Well, I've been 'online' since before the web was world wide. Frankly, it was never good.

In fact, it is better now than it has ever been. It's just people choose to use the worst parts of it.

I've seen the various tech that was supposed to rebuild and revolutionize the web. It's just created more kludge. It's just lipstick on a pig. It's just one more set of standards that get half-ass implementations and even worse support.

If you tear it down and rebuild it, it's just going to end up the same except it is using different names for the protocols.

I'm not angry when stuff breaks. I'm amazed it works at all.

And, truthfully, I kinda like it the way it is. We have, at our fingertips, vast amounts of information and entertainment. It works, after a fashion and for some definition of 'works.' If the Internet sucks for them, maybe they should look elsewhere? The Internet is huge. It's not hard to find parts that don't suck.

Tearing down and rebuilding isn't going to work and nobody is going to invest in that. Hell, we can't even get ubiquitous IPv6 adoption. Not one browser is fully compliant with HTML5. And it's okay. It works, mostly.
There are no machines that make meals, fold laundry for the average person and there won't be in ten years either. I think Ford did the 1999AD video showing this happening in the '70s. There are machines that may assist you in doing such things but they require a lot of human intervention and judgment.
My understanding of HEIST is that it is completely defeated by disabling compression on dynamic content. That doesn't seem to be "the end of the web" to me...
"Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java."

And, we complained endlessly about how slow and bloated those programs were. So it goes.
Randomly sample game states, giving more weight to those that affect balance more strongly and/or occur more frequently.
I think there's a lot of audience for this kind of game on Linux but there's only one launch.
I would have bought it straight away.

The dev said they would look into it, but I probably wouldn't notice or remember to look in the future.
To be clear, the issue in "Test A" is the lack of certificate validation. It wasn't immediately clear (poorly worded, IMO) but that's the (only) issue I see in that scenario and that is, indeed, a security issue (allows a MITM attack).

"Test B", however, is not a security issue at all, IMO; instead, it is "working exactly as intended".

> The Apache logs are not even needed without SSL enabled because the first request to the web server includes the username and password in clear text.

If SSL isn't enabled then, yes, of course it does. This may come as a shock to the author but standard IMAP4/POP3 without SSL also sends credentials in the clear (as does -- gasp! -- every other plain-text protocol!)

> Even when SSL is not enabled the client should not be sending the credentials without first verifying that it is a real exchange server.

And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response?

> Realistically the client should not even send the password before verifying the user exists.

That, however, would be an information disclosure vulnerability (identifying valid usernames on the server). That's why no other mail server in use on the Internet does that either. Not to mention that it's real easy for a malicious attacker (in control of the server) to lie about that too.

Aside: if you're running an Exchange server, set up Autodiscover [0] and all your users need to set up their mail account is their username and password (no server details are needed!). For other (i.e. non-Exchange) mail servers, there's a similar "Autoconfiguration" method that is supported by various mail clients, such as Thunderbird [1].

[0]: https://msdn.microsoft.com/en-us/library/office/jj900169(v=e...

[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...
Well for home computers at least the way to get it to load a new program was to kill the power.

The institutional ones probably had uptimes measured in months though.

You didn't just reboot something that multiple people, including senior staff and tenured professors, may be using...
Cool, thanks. I'll try this out if I ever want to switch to WebRTC.
The reason the web platform is "ugly" is because nobody owns it. Multiple players need to get on the same page in order for things to happen. The end result is not pretty (different browser versions behave differently, incomplete specs, etc.), but one thing is constant - nobody owns the platform.

This is important because of things like this [1]. You may dislike some apps' mission, or approach to moderating content, but you cannot outright ban it from your platform, if you don't own the platform.

[1] https://arstechnica.com/tech-policy/2017/08/gab-the-right-wi...
Protection from the Nation State Actors cannot come from companies. One must implement protections on one's own client-side. Proper encryption always. Tor when needed. Software and, where possible, hardware only from trusted sources.
Just woke up and it seems to be working now. No harm done, I guess?
I'm not so sure. I didn't know what London black cabs were and I still read it as (black cab) driver. I just assumed black cabs meant something like black car cabs, e.g., Uber SUV.