It's quite incredible how the web managed to get along with such a janky sandbox model.
It's a very important thing that users trust their browser and won't hesitate a second to enter an unknown URL. They see "going to a webpage" as the equivalent to looking at a poster in the street, not eating candy provided by a random stranger.
Eroding this trust would ruin it for everyone, even well behaved static websites without javascript.
Maybe it's time to reconsider giving the same execution rights to gmail and unknown web pages ?
Do you want to reinforce established monopolies? Because I can't think of a better way of doing that than having a technical difference between "trusted" and "untrusted" sites.
Well, I personally would be fine with the fair policy of disabling js everywhere but I'm sure most would not agree, so what's the alternative ?
If anything, Spectre class attacks really showed how hard it is to properly sandbox arbitrary programs.
Yes, the CPUs are complex, but the attacks happen on a high conceptual level, level at which the CPU is fairly simple. It's not like they rely on an obscure detail or bug.
No one (publicly) figured those out for 2 decades when the involved ideas (speculation, cache timings) are well known, common and did not change.
This indicates that for something with such a large surface as the various web standards, where both the spec and the implementations are changing all the time, there is very little hope.
What about differentiating applications and web sites? The line between the two is blurry, I know, but I would be happy if the document metaphor were divorced from the application one.
But what about applications that link to web pages or web pages that link to applications?
What valid reason is there to have an "application" and any documentation or related HTML material from the same site on different ports? Or, as some have pointed out elsewhere when this has come up, to have "applications" and "documents" use completely different protocols, languages and native clients, when both are often used together?
'Application' can be backward compatible with documents just fine. That does not mean a new category 'Document' that has reduced capability is useless.
Banking websites for example don't need to be Applications and added protection for cross-site scripting etc. would be beneficial. Restrict things further and you default to supporting screen readers etc.
What definitions of "application" and "document" are being used here? Banking websites are applications in terms of their functionality - they're certainly not documents. At least not the parts where I can access and modify my account.
Client side code including third party media players etc.
IMO it's a simple question 'can you do the same thing with a sheet of printed paper.' I can fill out paper forms and hand them to someone just fine. Don't forget a Check is really just a piece of paper with a form on it.
So a spreadsheet running in the client with javascript or WASM would be an application, but a spreadsheet running on the backend wouldn't?
I'm not trying to be overly pedantic or combative here but making a distinction between client-side and server-side code seems arbitrary. I understand it in terms of managing privilege - you can't control what someone does on a remote server, and that code isn't running on your machine, but it seems like the meaningful distinction here isn't between documents and applications but between local and remote applications.
Just because I type in yourdomain.com does not mean I want you to be able to start playing death metal from my speakers. What about typing yourdomain.com means I want you to break my back button? Show a popup rather than close the browser? Churn CPU cycles crypto mining or do just about anything beyond hand me a document? Display a flashing GIF?
The current model is basically handing complete control over my machine to a third party that may be compromised by anyone any time I click a random link.
The single greatest web innovation in the last 30 years was readability mode.
>Just because I type in yourdomain.com does not mean I want you to be able to start playing death metal from my speakers.
Given the way HTTP works, I think it kind of does. It means you want the server at yourdomain.com to send you whatever content that URL points to, if anything. Which, granted, given the complexity of the web now, does seem fraught with danger, but what alternative would there be? Profiling each site for embedded content, size and complexity and whitelisting the elements before rendering? Browsers already let you block scripts, disable images and autoplay, overwrite or disable stylesheets and mute tabs, that would seem to be sufficient.
>The current model is basically handing complete control over my machine to a third party that may be compromised by anyone any time I click a random link.
That's a good point, but separating "applications" from "documents" wouldn't solve that problem, since that's presumably the model the applications would still be using. Sure, static pages that aren't running client side code would be safe, but those pages already are safe.
Anything that could be done to make a separate application space run safely could be done to make them run safely on the existing web, couldn't it?
>>Just because I type in yourdomain.com does not mean I want you to be able to start playing death metal from my speakers.
>Given the way HTTP works, I think it kind of does. It means you want the server at yourdomain.com to send you whatever content that URL points to, if anything.
I think the issue is really that the client (web browser) shouldn't try to interpret whatever was sent back if it isn't considered safe. In other words, there should be limits of what the browser will do with whatever is send back over HTTP.
Anything that could be done to make a separate application space run safely could be done to make them run safely on the existing web, couldn't it?
Yes, but you could tighten things down and treat the modern web as a transient application delivery system. Where users have to explicitly grant access to each application, and grant it whichever specific permissions it needs. I also wouldn't be against having two browsers, one for running applications and one to browse the web.
The problem is that the dancing and singing monkeys enabled advertising to be increasingly lucrative to the point where the monkeys are running the show.
That's a complete non-starter as long as advertising pays for the web pages. Or even longer, if the replacement compensation methods require JS as well.
Maybe there would be less money in it, but it is possible to do advertising completely on the backend as well. You send the advertiser some targeting info, e.g.: what does the article(s) on the page talk about, what is your site about, what is an estimated profile of your readers, and the ad network gives you the ad images and text in some nice format.
Yes, it does require confidence that the publisher will actually show your ad, but it was the same thing for the journals. On the web you can still track outgoing links and have the referer, so you can know the actual impact of your ads anyways.
Aren't we sort of starting down that path already? IIRC Chrome only allows certain operations on HTTPS domains as of late such as webcam or microphone access.
It seems like this sort of iterative securing of different things over time could be a good way to secure the web while also giving time for older sites to upgrade.
Anyone can get an HTTPS cert, and with Let's Encrypt it's free. Restricting dangerous features to only websites that can demonstrate their traffic hasn't been man-in-the-middled is very different from giving established sites more expansive permissions.
(Disclosure: I work at Google, though not on browsers)
The key thing is differentiating one set of pages from another set of pages - putting security boundaries into a hypertext system that was originally designed to allow mixing resources from different sources.
The web didn't used to be able to do much, and we're using browsers that depended on tons of multi-decade old code, so I see how it happened. Agreed on the main point though.
That hardly helps. For true security devote a device purely to banking. Preferably a diskless device running an updated live CD on a security oriented distro with no rewritable storage attached connecting out over a VPN through an equally dedicated firewalled router. Then you're just left to worry about your bioses getting infected off an unpatched or 0d exploit.
He identified his threat model (other tabs + addons doing something shady) and made a security assessment based off of it.
You're here bullshitting that he needs "true security" like he's dealing with APTs trying to access his bank account. He's not. He's concerned about other tabs + addons, and private browsing mode is a solution with the slightest friction for his threat model.
Please, in the future, try making security assessments based on the actual threat model.
If there were a big target on my back I would do that, but since I am running Linux, I am not a rich person or have an important job I assume that I will be attacked by regular malware and not skilled hackers.
No. The burden needs to be on the user to understand their own security. If we stopped taking the burden out of user's hands and tried to ensure that everyone on the Internet understood that anything they access becomes data on their computer/device, we'd have a smarter Internet. Frankly, I think if we made people understand that they have a responsibility to choose what they download, there might be more vocal group demanding the ability to do whatever they want with data transmitted to their computer, save for directly malicious acts against other users.
The browser should be only two things: a client between a user and a server, passing information; and a parser which displays that information on the client-side. The moment a browser alone begins controlling what the user sees, or does not see, without the user having the ability to control it, we have a major problem.
That becomes a security problem, a privacy problem, and a functionality problem. All data on the Internet should be treated the same by all browsers' client functions. The display may vary (e.g. the difference between Lynx and Firefox), but all data should be treated equally and the user should have both the authority and the responsibility for their own computer.
> The moment a browser alone begins controlling what the user sees, or does not see, without the user having the ability to control it, we have a major problem.
What you're describing would be inordinately taxing for even the most experienced developer, not to mention the average internet user. The only way this could possibly be viable would be if we used gopher:// instead of http(s)://
Currently, there are tools such as Privoxy Actions & Filters, which allow you to do 100% of what you're describing, Greasemonkey which allows you to do ~80% of what you describe, or uMatrix which allow you to do quite a lot. The prerequisites for using those range from full-blown programming skill (for the former 2) to managing a relatively advanced in-browser UI (for uMatrix), and having a lot of spare time. For every single webpage you visit on the web. This isn't viable for 99% of people.
>The prerequisites for using [Privoxy & Greasemonkey] range from full-blown programming skill...
Neither Privoxy nor GreaseMonkey require actual programming knowledge. I do not program, and I use Greasemonkey with some regularity - I use a combination of userscripts.org scripts and my own. They require a basic knowledge of specific scripting language implementations. Besides, Greasemonkey & uBlock/uMatrix both have a right-click menu entry that amounts to "hide anything like this".
You're saying that 99% of the Internet's users can't handle being required to interact with the most basic front-end technologies which power the network they use every day, and which they willingly give up their private information to - thus having no ability to provide evidence for their trust or any expectation of their privacy. Frankly speaking, my mindset is that if it's not viable for them to understand it, it shouldn't be viable for them to use it. Uneducated users lead to nothing but trouble; and sure, I'll grant that I'm suggesting educating them the hard way, but I think the Web as a whole would be better off in the long run from smarter users and dumber clients. Heck, I think the whole world would be better off with smarter users and dumber clients/terminals/systems.
Also, please, don't even begin to suggest that uneducated users should be directed to Gopher holes. You know as well as I do that if there's enough people going back to it, some yutz is gonna start trying to figure out how to add streaming this and scripted that to Gopher, and then Gopherspace will be ruined. And sure, on a technical level it would be a neat project to look at. But to reference Jurassic Park, a lot of very smart people have been so amazed at what they could do with the Web and the Internet as a whole, that they never really stopped to ask if they should do it.
It's a very important thing that users trust their browser and won't hesitate a second to enter an unknown URL. They see "going to a webpage" as the equivalent to looking at a poster in the street, not eating candy provided by a random stranger.
Eroding this trust would ruin it for everyone, even well behaved static websites without javascript.
Maybe it's time to reconsider giving the same execution rights to gmail and unknown web pages ?