Chromium devs want the browser to talk to devices, computers directly via TCP, UDP. Obviously, nothing can go wrong Google's Chromium team has proposed a way to allow web apps to establish direct TCP and UDP network connections, a powerful capability that could complicate web security. The Raw Sockets API, which may end up being renamed the Direct Sockets API, represents an attempt to give browser apps networking capabilities that aren't …
>>ZedZedPluralZedAlpha
I would have upvoted apart from your deliberate mistake.. ZedZedNinePluralZedAlpha is the sector I believe you were looking for. I can't believe the 42+4 upvoters didn't spot that and yes, my towel is currently hanging on the towel rail in the bathroom...
Apple has refused to implement some of Google's ridiculous crap like web interfaces for Bluetooth and GPS, so I hope they will refuse to implement this (or at least leave it off by default) But Safari is really only a solution for Mac and iOS users, the PC/Android crowd needs an alternative to Google's embrace/extend of the web.
Firefox really needs to stand up to this and start positioning itself as the more secure and more privacy protecting alternative to Chrome. The ship has sailed as far as it competing head to head as "best browser" now that Microsoft has sold out and PC users are getting it from both directions. So stop following Google's stupid attempts to reimplement ActiveX in all its glory and start saying no to stupid web extensions - and alert the user somehow when a web page is trying to use these facilities so they know Firefox is preventing their use.
at that point in the sentence, you should have become vvvverryyyy suspicious. And I say that even though I would probably benefit from the new API.¹
Also, what's this "[the API] will come with a higher barrier to use [than asking nicely]"? Are we seeing another step to Appstorification of the free and equal interwebs? "Yes, we have that API, but you can only use it from vetted code that you download through our AMP AppstoreMoneyProgram. This ensures your libraries and page will load quickly from our CDN, wherever in the world your users are. We even include 5000² free³ downloads every month⁴."
¹ because as soon as lethargy leaves me, I will write an homage to BarcodeBattler that uses TLS certificate data, and you can't introspect that from Javascript.
² subject to change ³ 49.99 setup fee; developer membership required ⁴ offer valid until September 9852, 1993
> Like WebUSB, WebMIDI and WebBluetooth, …
Yep, that bit screamed "OH FUCK" at me too. 3 things that I've gone out of my way to try and nobble in the browser to make sure that sites can't use them in the first place.
There have been handful of times I've had a need/desire to be able to do non-HTTP connections in javascript (usually, needing to do some kind of DNS resolution and capture the full response rather than the actual result).
I'm not sure it's worth it though - the "mitigations" they've put in place make the workflow inconvenient, so wouldn't fit what I need (it'd need explaining to distant end-users), but without the mitigations the whole spec is a *massive* ball of fire.
"Yep. If I wanted a browser-OS, I'd use ChromeOS. You can't simply shoehorn a browser into doing everything!"
It does look as if the endgame here for The Goog is an appliance with the absolute bare minimum of OS under the browser, just enough to run it, and everything else is a webapp.
It hasn't worked so far--their Chromebooks keep gaining new features for some level of Android or Linux compatibility because people have realized that computer that runs most things beats computer that only runs a browser. Why do they want this so much anyway--they could just make Android laptops (just add more keyboard support) and get users to hand over all their data that way. It seems to me that if they want to capture all our data, they don't have to do so much work to try to force a limited OS on us when they've already got one that people use.
I don't want to firewall every host on the network in their own little bubble but it looks like that time is here.
I like the idea of the dialog box. Can they added that to "This web page wants to load external Javascript. Please enter all the remote sites that it is allowed to talk to". I would be ok with that. Add the same thing for cookies.
> I like the idea of the dialog box
Which will be something along the lines of "Click here to access our supercool content!!!", and will be subsequently implicitly valid for every other connection, site and app. The "refuse connection" link will be hidden in 1-pixel height letters of background color, and will prompt you "Click here if you're really that big a loser (and want to die alone)" before grudgingly accepting your choice for a day or two.
Sorry, in plain honest English that dialog box can only say "Click here if you blindly trust the internet".
Though in this case I think the dialog will both fail because too many users will just enable it anyway, while also failing because people who were supposed to turn it on were like "what's an IP address?"
and as those above commented, the line about regular application software being the real attack surface is utter cow flop. A raw socket coming from an arbitrary web page and that is indistinguishable from a standard web request to the OS and firewall software is obviously a huge risk. Crap software with network access still has to be installed on the system, which we have a pretty good tools and methods to work with.
Chrome should stop trying to build a universal rootkit interface and work on keeping one ad on one tab from using 90% of your system resources and draining your battery. If they can lay that problem to rest , they may have a shred of credibility to add even more low level browser access.
It essentially allows the browser to talk directly to devices and other computers via the network.
So practically the same as happens here on El Reg with virtual machinery talking to humans and advising them of future surreal developments, which they may or may not be equipped to understand and assist with? That's nothing new and novel.
As we know very well, all problems in computer science can be solved by an extra level of indirection. Which means in this case that all the security crap you know and love (firewall, access control lists, certificates, crypto algorithms, switching from TCP to TLS1.3, from UDP to DTLS, need I go on?) -- all of it -- will have to be duplicated in the browser.
So isn't this just a way of helping along the plan for Chrome to take over the universe?
It essentially allows the browser to talk directly to devices and other computers via the network.
As if we don't already have enough web-based dodginess to worry about.
The Twitter discussion between King and Schuh is interesting ; King has clear concerns borne out of experience and, while Schuh attempts to allay those concerns, it is apparent that his own concerns haven't been fully taken on board in the proposals. hence the suggestion that King should get onto Github with hers.
My overall impression is that this is a potentially useful development for those who know what they're doing but a very dangerous one for the average user.
Perhaps the whole api should be delivered disabled by default, with a high barrier to enabling it (a hidden config setting would probably do it). Then those that can handle ti safely can have it while the rest are blissfully unaware of its existence.
What's really scary, is if you look at the issue list, amongst the few open issues - there's already requests on there to "break" standing security practices:
- https://github.com/WICG/raw-sockets/issues/19 - it'd be useful if this bypassed/ignored CORs
- https://github.com/WICG/raw-sockets/issues/14 - suggesting the spec will allow connection to port 25 to send mail
It gives some idea of what (some) people are already hoping to use this for - the first is a guy who want's to scrape content from sites (reddit etc) that are using CORs to try and prevent exactly that.
<grumble>Nothing good can come of this insanity</grumble>
.. and the second is clearly somebody who wants to easily sent his bulk emails from clueless users' computers...
I've been hearing for ages that "email is dead", not to mention there are heaps of email apps out there, why on earth would anybody need to send mail through a browser app? There might definitely be some isolated edge case where this might be vaguely desirable, but it definitely doesn't justify the obvious eagerness to create yet another spam vector.
This is pure, unadulterated feature creep, and I'm not surprised that it comes from a company who's biggest concern is marketing its users. All I've seen is aimed specifically at breaking barriers users might put up to reduce spying telemetry. I've yet to hear about a feature I (simple standard user) would need (or even just like).
Just about anything is useful for those that know what they are doing.
An interface to alter engine timing while you are driving, useful if you know what you are doing. An interface to override coolant flow in a nuclear reactor, useful if you know what you doing. For that latter, there might not be anybody who REALLY knows what they are doing well enough to fuck with it, but that wouldn't stop people who WRONGLY believe they know what they are doing well enough to do so.
This should not be the bar for adding a capability to a browser that is enabled by default. The bar for adding something to a browser that is enabled by default should "will this enable new classes of malware and make the problem of malicious web pages larger than it is today?" and unless you can answer "no" it should NOT be added, or if they are MUST always be disabled by default and appropriate warnings shown if you try to enable it. Just like stuff like a web interface to bluetooth or GPS should NOT be added, or if they are MUST blah blah blah.
Google just wants to destroy the world.
Now that web safety has been completely solved,
That sentence needs to go down in El Reg history.
That aside, there is a reason why Chrome is banned from my network. Anyone in the IT world would see the grand canyon sized holes in this idea.
Google really have lost the plot unless it is all part of their next generation slurping system.
"Google really have lost the plot"
They haven't even read the CliffsNotes[0] from what I can tell.
They see that familliar black & yellow "under construction" sign, and all they comprehend from that point forward is the Almighty Buck .... and fuck everyone and everything that they trample in its pursuit.
[0] That'd be Cliff's Notes if you are my age ...
"This will end with Chrome and it's derivatives being banned from my networks."
I did that years ago.
For the users where I wasn't allowed to ban it, I had a little script I liked to call fuckchrome. Stick it on their machines, and they'd have a random amount of time from 30 seconds to 15 minutes after launch before Chrome would crash. They knew better than to come to me to complain about it, because all that would get them was a "I told you not to use that garbage."
They (Google) don't care about your users. They care about the mass market, which is where they collect the private information that makes advertisers super happy.
I was forced only the other day to fire up Chrome, by a video streaming site that simply told me that my other browser was no good. Also because using Chromecast except from Chrome is a bust. So they got a bit more of my private life into their machine learning system.
"Forced? Were they holding a gun to the head of your firstborn or something?
Or do you mean 'I had to because SHINEY!!!!1!'?"
Well, I wasn't that person, and I haven't been forced to run browsers for a while, but maybe it was one of those services that it's not that easy to avoid. For example, services where you have to submit paperwork that your employer or government is asking for. Those sites have a distressing tendency to demand one browser, and while they sometimes work in other ones, sometimes they just don't. You could hope that the system concerned has a mail or fax option (if you don't mind printing things and waiting a week for the post and two or three for someone to pick it up and process it), but otherwise you're a little forced to use what they're asking you to use. Not deadly force, but force nonetheless.
The person I was responding to was forced "by a video streaming site". SHINEY!!!!
As for your argument ... When I run across government sites that don't allow me to use my browser of choice, I simply tell them that their broken software doesn't run on my machine, please give me the alternatives that are available by law under 42 U.S.C. § 12101 ... either that, or they can ship me a machine that'll run the broken code. It might take a week or three, but I have plenty of time.
To date, I have never been penalized. It's their fault that their system is broken, and they know it.
If you just sit and take it, eventually they won't let you sit anymore. But that's OK, because you probably won't feel like sitting after taking it long enough ...
True. And this shows that this level of control was the real reason the wanted to get rid of plugins like Flash and Silverlight in the first place. If you try to replicate all functionality of those plugins right in the core of the browser you will run into all the same issues. And Google sure seems to be eager to do that...
I have written a fair number of WebSocket servers in C and C++ (because most existing open-source solutions are a bloated mess).
After doing so, I still can't quite see the additional security it provides over a raw SSL socket...
1) You have the handshake with some random magic number (which is always the same) where you hash it and things.
2) You have the payload header which is just an "old school" way of specifying how large the "packet" is.
3) You then mask the bytes as you send them (basically to ensure caching proxies don't do anything weird)
4) [optional] Everything using an SSL bio
None of this prevents my browser from doing anything any compared to a raw TCP socket anyway.
Someone else working for Cthulhu responds:
I'm curious why, and confess that I suggested this style of mitigation. The intent is to support config flows for legacy protocols like SSH, IMAP, SMTP, etc. So, this is both consistent with existing native flows, while also providing high friction against likely abuse cases.
They live in a world where SSH, IMAP, and SMTP are considered legacy (i.e. not invented there) and a popping up a "press yes to make the shiny work" dialog box is considered security. It's like a cult, probably involving kool aid.
Who's calling who "legacy"?
Who?
The DHs* who want to implement this crap.
ie: "... the browser to talk directly to devices and other computers via the network."
Why?
Well ...
You could be lenient and follow Hanlon's Razor reasoning.
ie: stupidity, incompetence or a dangerous mix of both.
Or you could be a wee bit more subjective/paranoid and see a whole world of unwanted possibilities behind this really dumb move.
You choose.
O.
* DickHeads
"Who's calling who "legacy"?"
"Legacy" is used at Boardroom Level to indicate stuff the youngsters don't understand because they don't bother teaching it in school anymore. It must be eradicated at all costs, because it's not new and shiny.
If you want to see a C-suite member go apoplectic, point out that all his financial assets are handled by Legacy Mainframes running Legacy COBOL and Legacy Fortran.
Another attempt to make an application into an operating system without the fifty plus years of development, no instrumentation and piss poor resource control and security. If you want that sort of thing I guess you could buy a Chromebook, but most people don't. If you want to see how well this tends to pan out, just look at the mess that is you most/least favorite Java application server.
>Another attempt to make an application into an operating system....
Its not really doing anything of the sort. What its acknowleging is that a browser envrionment is now the preferred environment for local code execution. In effect its just this year's model of older graphical shells such as Tcl/Tk with the added twist that the code that gets to be executed can be downloaded from some remote host masquerading as a web page. Now -- I wonder what could go wrong with that?
I'm not going to give up the Internet, silly! I might, however, give up most of the insecure festering shithole subset of it called "the web".
Come to think of it, I pretty much already have ... And it doesn't seem to have made my life any more difficult or frustrating than it already was. Quite the opposite, in fact.
"What its acknowleging is that a browser envrionment is now the preferred environment for local code execution."
No, that's not it. When people wanted the browser to be the user interface, they made that. Applications have used a web interface while running local code for years. They could do lots of things, like arbitrary network access, because in reality they were local applications using a web framework (sometimes they wrote their own, sometimes they used a XUL-based one, sometimes they even put most of Gecko in). That was fine. This isn't the same, because the browser wants to do all of that for scripts. Instead of the application controlling their framework, the browser is planning to do that for anyone who requests it. The browser is adding a bunch of utilities that were previously available to local applications. Basically, the browser is trying to do what an operating system does, namely providing utilities for accessing local resources like ntworking, disk, peripherals, etc. It's not going to work well, for the reasons you state and for others.
This is straight out of the school of moron developers who just cannot understand that a web page is not a fucking modal client application. When they find that a web page does not operate as if it was one they just to try to bodge, lever, hack and generally very badly kludge things until they can pretend that it is.... then vomit out a barely usable bug ridden mess of a "web application" and proceed on their merry way to break something else because some other new shiny JavaScript library has been dropped out somewhere and therefore must be used.
See also Java, ActiveX, Flash or Silverlight in the browser.
Where I toil away the days as a programmer, we have started to abandon the Windows platform in favor of the web. The reason is that nobody seem willing to want to install any binaries these days. Security and all that lark. (or possibly just laziness -- difficult to tell)
The irony of another wave of "let us see if we can make the browser a more capable platform for running your code" has not escaped me. Meanwhile, the quality of the tools involved is just not up to the standard I have grown accustomed to. IMO both developers and end users end up with the short end of the stick.
The large part of the problem is that many developers just do not understand that a web page, as in a web application is very different to a modal client/desktop application. Therefore they attempt to develop a web application as if it is... not helped that for years useless shit coming out of Microsoft/Visual Studio that tries to convince developers that a web page is just the same. It's not.
It's scary the inconceivably stupid things that I've seen developers try to do to force a web page to behave more like a modal desktop application. These always fail.
As a web dev who also plays around with ardupilots and other home made gadgety things this is a godsend. But do I want it implemented in chrome? Do I ****.
if you *need* to do something like this. shoehorn it off to a server, or installed binary or if you absolutely must, do it with electron. Obviously if you don't know how to do that, you shouldn't be allowed near it which defeats the point anyway.
This is what happens when you have a bunch of mediocre developers and a popular web browser. *Everything* has to be jammed into the browser instead of being separate applications.
Why do mobile apps exist? Because mobile browsers and mobile versions of websites are so piss poor. So why aren't desktops treated the same way? If you can be bothered to make an app for one or both of the major mobile platforms, why can't you make one for the three major (one major and two minor really) desktop platforms out there?
Browsers need less functionality and fewer potential exploitable back doors. Not more.
> Browsers need less functionality and fewer potential exploitable back doors. Not more.
This.
.
Unfortunately this doesn't sit well with the "shiny-shiny" crowd obsessed with appearance, which is clearly the demographic targeted by Chrome (The very name to start with. Then the constant "we moved a button" updates with integer version numbers (because bigger is better, especially for a Johnny-come-lately). And so on).
Fortunately (for the time being) we aren't yet forced to use Chrome (or some Chrome in disguise).
> What happens when the inevitable happens, then?
If you're talking to me, I'll stick with whatever maverick browser some crazy devs will keep making in their spare time, like I did when Microsoft torpedoed Netscape. I'm pretty confident somebody will keep making one, the "because it's there" pendulum swings both ways. And I don't really care if the "popular" sites don't work in it, I'm too old to be "cool".
As for the younger generation, they are already brainwashed into compliance: They love being analyzed and probed, they mistake it for being cared about.
Here in the States, the gubment has to be accessible to all. It's the law. If they try to make it hard on you, make it harder on them. I actually managed to convince the California DMV to deliver a Vista computer to my door so I could hit "OK" on a Web form. Their forms all work with Firefox now. The journey of a thousand miles begins with but a single footstep.
> Like government websites
I don't know where you live, but as Jake said, government websites are usually the most easy to force into compliance: They (normally) don't have commercial interests, and they (normally) are supposed to cater for the whole population, not just some specific subset thereof.
In short, I don't think that will be a problem. Commercial websites like banks and stuff will, but then I have explicitly told my bank to never ever honor any order made over their web tools. I'm probably special but driving to their nearest branch once a month covers all my banking needs, the rest is cash and credit cards.
" It has the potential to enable better web mail clients and apps based on decentralized peer-to-peer routing based on distributed hash tables."
Funny I thought web mail clients and apps were clunky and hard to use because they were shit, not because of routing inadequacies. If anything, a bit less hash might make them a bit more lucid.
Recycling Pied Piper release notes to launch your big idea does take quite a pair. Well done!
All the container folk will barf; after spending a decade re-implementing every network protocol to ride on top of layer 7 strtok() based routing ....
Jobs for life.
>Dunno how I'm going to manage banking though. There aren't many branches left.
Back in the "good old days" before I left the UK for the US in the mid-80s I was accustomed to doing all my banking electronically. Wages were paid automatically, standing orders took care of regular bills (with the billing amount averaged to keep fluctuations under control), credit cards provided plastic for payment and there were ATMs for the occasional bit of cash. Going to the US I entered a banking environment that was at least 30 years behind the UK's, it was seriously old fashioned. (Quaint as well -- banks didn't have those anti-robbery partitions.) Over the next 30-40 years the US banking system gradually caught up with the UKs but it seems that rather than importing the best of what the UK had to offer the UK has imported the worst of our banking habits -- fees and all.
Anyway, what I'm really saying is that you really could use IRC and USENET and all that good stuff and that all that would really happen is that certain large Internet firms (and numerous scam artists) would find that their platform had eroded along with their business model. Latency times would improve as well -- the Internet is stuffed with uselss traffic from carelessly designed web sites.
"Dunno how I'm going to manage banking though. There aren't many branches left."
Walk into a local branch and tell them why your are there. They will be happy to set you up.
I have NEVER used Internet services to do my banking. Ever. And I never will.
In these here Covid days I'm forced to use a drive-through, but I still talk to my banker of choice face to face, albeit through about 4 inches of bullet proof glass and via a microphone/speaker. They will physically let you in to the branch to open a new account or accounts and to take care of other important "wet ink" paperwork, at least here in California.
"Walk into a local branch and tell them why your are there. They will be happy to set you up."
You assume one exists. In many places, the last local branch of any bank within walking or even driving distance closed years ago, meaning it's online or bust, and no, the community is too small for anyone to give a soaring screw.
Jake,
"If more people eschew Internet banking and instead use the branch on their High Street, more local branches will re-open. "
Unless Time Travel or FTL vehicles are involved, you *cannot* use your high street branch to encourage banks to re-open high street branches ...... when the high street starts without an 'open' branch !!!
Other than episodes of 'Red Dwarf' this does not compute.
:)
It'll take more than one person bitching about it to pull it off.
You know, if one person, just one person does it they may think he's crazy, and they won't pay any attention to him.
And if two people, two people do it, in harmony, they may think they're both idiots and they won't pay attention to either of them.
And if three people do it, three, can you imagine, three people actually getting off their ass/arse and demanding a new local branch? They may think it's an organization.
Can you imagine fifty people a day? I said FIFTY people a day, walkin' in, singin' a bar ... Oh, wait, that was a different protest entirely. But it just might work ... Squeeky wheel & all that.
(With apologies & a heartfelt thanks to Arlo, who would undoubtedly approve.)
The need to have a widespread physical presence also ensures that new competitors won't enter the market (its extremely costly to open thousands of branches). That's why the same banks have been screwing their customers for years with no new competitors until recently.
In the last few years it's become more acceptable to have an online-only banking service, and this has resulted in lots of new services popping up with many advantages compared to legacy banks. We have faster/cheaper transfers (including international), forex with better rates and lower fees, 24/7 service etc etc.
Also those branches are extremely expensive to operate, the operation costs are paid for by you and other customers.
I don't want to go back to the days of physical branches, small cartel of providers with no competition etc.
> I have NEVER used Internet services to do my banking. Ever. And I never will.
Same here.
Just wanted to stress there are more people thinking like that. I know it's an uphill battle, but IMHO we can keep a minimum of brick & mortar bank branches around, simply because if bank A doesn't, we might switch to bank B who does. (YMMV, there are huge differences between countries and even regions, and what's possible in one place might indeed be near impossible in another, even inside the same country.)
Why would you want to do that? Keeping bank branches open and widespread enough to be useful is extremely expensive... This cost has to be paid for, by the customers using the services (ie YOU).
Setting up a network of bank branches widespread enough to be useful is extremely expensive, this creates a significant barrier of entry and pretty much ensures that the incumbent banks will have no new competition...
Metro bank launched in 2010, they were the first new high street bank in the uk in 150 years, they only have a presence in some limited areas and required a HUGE investment for this.
All of the recent innovations in banking have been introduced by new players, the vast majority of which are branchless.
The larger the barriers to entry, the more you stifle innovation.
"Question: Where do you go for coinage"
I just called a friend who owns a small, tourist-oriented, mostly cash business to ask just that. (I'm curious. So shoot me.) She says she called a vending machine business, and they were more than happy to deliver several hundred dollars worth of rolled coins in return for paper money. With no markup or delivery costs.
Interesting. Most of the vending machine vendors in my area lack the coinage, actually, as vending units in my area have been taking plastic for decades. The readers themselves are modular and upgradable. They went to chips a while back and many now take contactless. Upside: Less labor costs for collection runs more than makes up for the transaction fees.
It’s the super dodgy, poorly maintained browser that has been DDOSing the root DNS servers for the last 12 years that I’m worried about!
There are many reasons I don't allow Chrome or one of it's derivatives on my personal network and this just adds another one. There is only one reason I allow them on my work computer and that is compatibility testing due to the vast number of idiots, sorry users, that insist on using them.
*MITM attacks that inject sockets API calls into a web page or hijack plaintext connections.
*Web apps making connections or conducting DDoS attacks without the user's knowledge.
*Bypassing third parties' CORS policies.
*Third party iframes or scripts that initiate connections.
*Covert DNS manipulation to expose resources behind a firewall.
*Using the API to violate corporate policies.
You can add device and browser fingerprinting to that long list of problems as well.
I've noticed a huge uptick in the amount of websites that are using obfuscated scripts to fingerprint the users device that uses many of the API's mentioned in the article.
And as others have said, it's just more stuff that I have to disable in chrome://flags and/or about:config.
The fastest way to cure that is to become your own boss. Most of the regular posters here are perfectly capable of doing that, it is only fear of the unknown that is stopping them.
As the Boss, when the waters surrounding the ship are filled with sharks, I make soup. It's rather tasty soup, I invite all y'all to try it.
Unless you engage in a hostile takeover (aka a mutiny), odds are the ship from which you're jumping won't be your own, and it's a long way to shore (or another ship, whatever it may be). And sharks are NOT a figment of the imagination. Local news reported of an actual shark attack not too long ago, and that was on shore.
Put it this way. If OYOB was anywhere close to what you described, there would be a lot more entrepreneurs having a go at it.
What happened to Do no evil?
People barely read pop ups.
When every page needs permission to do something we will just blindly click permission dialogues.
What happens when permissions pop up for tabs not currently in focus?
So so so many obvious issues here. Of course the biggest issue is that the client browser is behind the security zones and now able to communicate directly with other stuff in the vicinity, no point bothering with security then.
Probably not an issue for Google with their non legacy security by design systems, the rest of us will be pawned in an instant.
Go ogle dropped it as a motto in 2015, when Alphabet decided "Do the right thing" was more appropriate.
But right for whom? They don't say ... My guess is the shareholders. In their warped, fuzzy little brains it's OK that they are evil now, as long as they are making a profit.
Some of us have been shunning go ogle since the year dot ... not paranoid, pragmatic.
That's why mosquito coils and the like seem to get rid of mosquitoes ... it's not the smoke they are driven away by, rather it's the excess CO2 that they become confused by. They sell propane burning mosquito traps that use this principle ... and they are very, very effective without the smoke.
You don't hit mosquitoes, silly. You swat them. Several at a time, preferably.
I don't put blood on the barrel any more than I put a little bit of Purina Duck Chow on the end of the barrel when I'm hunting duck.
Whatever happened to a stump grinder and a little patience? And incidentally, you may not have realized that I was referencing ol' Monty Python.
Interesting. Seems like this proposal could negate most of my organisations security.
This is what I think was meant by King's response:
In response King quipped, "It’s not the super dodgy, poorly maintained native software that I’m worried about. It’s the super dodgy, poorly maintained server software that is now one XSS away from hostile socket connections."
Right now, my organisation has 10's of millions of dollars in firewall appliances, gateways, multi-tier application infrastructure (which is another 10's of millions worth of developer time to create all these multi-tier applications) not to mention a couple-dozen staff who manage and operate and secure that infrastructure.
The multi-tier applications are set up such that there is no direct access to databases to the internet, thus no SQL-injection-type attacks can be made 'raw' from the internet. First stop for outside communications is hitting web applications inside the gateway environment. These don't have any access to the database, that still lies several firewalls away. These apps use various application to application protocols (corba, webservices, message passing/queing) to do fixed-function communications deeper into the application environment. These deeper components sit several firewalls deeper and can only accept those fixed-function and limited protocol communications (i.e. no ssh is allowed in) from the application servers in the gateway. These backend app components also can only perform fixed-functions calls back to the database. Therefore to be able to do arbitary SQL communications with our databases, you'd have to:
1) penetrate several layers of firewalls to gain control over a server in the gateway (since the apps running on it can't do arbitrary calls to their backend, you can't do that by just taking over the apps on the box). Youd have to gain shell access to the box.
2) once you have shell access, you'd have to do an escalation of privilege attack and bypass whitelisting to be able to install software on the box to allow further chaining deeper into the network.
3) rinse and repeat seps 1 and 2 possibly several more times (won't detail any further), that is gain shell access behind more firewalls and escalation-of-privilege to bypass whitelisting and install software to do more chaining.
4) do your attacks against the database.
Sure, our organisations security is penetrable, but it would require a custom attack and (hopefully!) hundreds of man-hours of work to do all the chaining, which gives plenty of opportunities and most importantly time for the security staff to notice something is going on and intervene manually to stop it. It'd be like someone breaking into a bank vault but taking 100 hours to do it, thus getting caught when people turn up for work the next day and notice the crooks attacking the vault. Each organisation attacked would require its own custom attack and dozens or hundreds of hours of work.
But with this proposal, you could write some javascript, insert it (legitimately) into an ad network, and await some dumb (i.e. 'typical', the type of fall for phishing email attacks constantly) user who visits a 'safe' site like the guardian, new york times, anything that uses ad networks, and skip steps 1-3 and go straight for step 4. Thus rendering all those tens of millions of dollars in firewall infrastructure and application architecture irrelevant. With this one javascript, you could probe thousands of different organisations without any extra work. This attack would even bypass typical email-phising protections, i.e. desktop whitelisting preventing documents/applications included in emails from launching at all on the desktop. However, the browser is already whitelisted, therefore anything running inside the browser, like this javascript that initiates TCP/UDP connections outbound from the PC, is also whitelisted.
Sure, this could be mitigated, desktop firewall rules that only allow the browser to communicate with the proxy server, not allowed to hoik off to random internal destinations. Zone off al the PCs into their own zone so they can't access anything else on the network, but then how to you get to your shared drives? Perform legitimate access to the database? I can think of defenses, but most of them would cause lots of pain to the end-users, e.g. not being able to access the internet at all on your desktop PC, having to remote desktop to another server/PC that is allowed browser access, and so on. But I see massive additional costs to organisations in more security work and lost productivity due to having to 'double-handle' internet access. For example, I access the internet everyday, I am a system administrator, so I'm always doing internet searches on how to resolve issues, looking up info on patches, or looking up documentation, etc.
Yeah, I'm on King's side - if I've interpreted the quoted statement correctly - on this.
If a six year old can buy a monster truck with dad's PayPal creds, what makes you so sure none of your household can figure out how to install a Trojan Browser?
https://www.theregister.com/2020/08/21/6yo_buys_19k_monster_truck_off_ebay/
(Single-person households may be compromised by attacks injected in/by Tinder or whatever floats your boat :-)
After reading the article i wanted to see what would happen if I made a typo in the search bar of my web browser over a CenturyLink DSL modem/router with default settings.
I was taken to a parking domain that uses a myriad of techniques to fingerprint my browser and device and then tries to serve up questionable ads using an API key to bypass AdBlock.
Very much like what is mentioned in this article by ThreatPost:
https://threatpost.com/malvertising-ad-blockers-mac-malware/146861/
Am I the only one who notice that Google Chrome engineering director Justin Schuh said:
IT admins "rely on super dodgy, poorly maintained native software that runs at elevated privilege and is often riddled with vulnerabilities," said Schuh.
Go ogle's ENGINEERING DIRECTOR. one Justin Schuh, has just admitted that go ogle has untrained, inexperienced admins, and that their internal servers are full of super dodgy, poorly maintained software running at elevated privilege and riddled with vulnerabilities.
Doesn't that make you feel all warm and fuzzy?
It has the potential to enable better web mail clients
Okay, I can sort of see how this could be a thing, I could talk IMAP or whatever from a web page. That could be useful (and in no way abused ;) ) but…
and apps based on decentralized peer-to-peer routing based on distributed hash tables.
What does this mean?? This just sounds like marketing Kool Aid. (Or do I hand type every nodes IP into the permission box??)
It’s a good job that I can’t see any way the most prolific data harvesting company of all time could ever use direct network access for ‘evil’.
'a powerful capability that could complicate web security.'
Sounds like a good excuse to block all chromium browsers from running on pc's that I have to look after. I believe multiple security products allow this quite easily, Sophos takes about 5 mins to configure application blocking.
Either that or some genius need to design a better gateway proxy that is as easy to use as a Pi hole.
If you want to screw up the security of every thing that can run a browser *and* has internet access ...... why not just ban firewalls and Ad-Blockers and just *hope* everyone is safe !!!
For F**** sake, I want browsers doing less in the background 'out of my control' *not* more clever crap that no one needs ....
Simple solution for now .... don't use chrome.
Longer term solution ..... Tactical nukes from orbit ..... just to be sure :)
Google's idea of "web security" is to ban entire domains because a few bad downloads came from it over time, or at least that is their excuse. The real reason most of those websites are banned is that Google's corporate partners and buyers don't *like* those websites for various reasons. But to get access to *one* of those sites, you have to *entirely* disable Google's web security.
As long as they're an "our way or the highway" security shop, I say Google can take a flying leap off a VERY high cliff... preferably over sharp rocks.
There seems to be a lot of hate for this feature, and on the surface it sounds potentially very dangerous... But think of the bigger picture?
The ability to open arbitrary sockets is likely to be tightly controlled, no browser is going to allow sites to open arbitrary sockets by default, and it's going to require users to explicitly accept the opening of sockets.
If users want to explicitly allow arbitrary sockets they can already do this, but they do so through things like java applets or even downloading and running an arbitrary binary. By doing this, not only can the code open arbitrary sockets - it can do A LOT WORSE TOO.
For cases where there is a legitimate need to connect over an arbitrary socket connection, having the client software running in the browser sandbox is an improvement on the status quo. Not only is the software sandboxed, but it allows legitimate use cases to work in this way instead of encouraging more dangerous behaviour like running random native executables.
The less need there are for native executables, the less likely users will be willing to run such executables.
It's also going to be possible to turn this functionality off entirely or restrict it by policy, if you're in an environment where such features are never required.
Overall this is an improvement to security.
"The ability to open arbitrary sockets is likely to be tightly controlled, no browser is going to allow sites to open arbitrary sockets by default, and it's going to require users to explicitly accept the opening of sockets."
The mere ability to do so is enough for malware to exploit a security hole and ram whatever they want through that ability. As for relying on the users, does the word "clickbait" ring a bell?
"If users want to explicitly allow arbitrary sockets they can already do this, but they do so through things like java applets or even downloading and running an arbitrary binary. By doing this, not only can the code open arbitrary sockets - it can do A LOT WORSE TOO."
It's still diversification, especially when dealing with Joe Stupid who pretty much says if it requires a separate app The Internet Is Broken.
"For cases where there is a legitimate need to connect over an arbitrary socket connection, having the client software running in the browser sandbox is an improvement on the status quo."
I disagree. Java was supposed to be in a sandbox and look what happened there. VMs aren't supposed to see each other or the hypervisor; then someone developed the first Red Pill exploit. Browsers need to be jacks-of-all-trades; that makes them terrible for security purposes. The only reliable way to prevent something from happening is to not have the ability to do so, period. Thus the UNIX philosophy to do ONE thing at a time.
"It's also going to be possible to turn this functionality off entirely or restrict it by policy, if you're in an environment where such features are never required."
If someone can turn it OFF, someone else can turn it back ON. Or it could be ON and no one of note realizes this.
"The ability to open arbitrary sockets is likely to be tightly controlled, no browser is going to allow sites to open arbitrary sockets by default, and it's going to require users to explicitly accept the opening of sockets."
Are you seriously suggesting that a "yes/no" dialog box is good enough to tightly control the security of your Great Aunt Martha in Duluth?
"Overall this is an improvement to security."
In Whacko World, maybe. Not here on Earth.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
