View Single Post
  #11  
Old July 18th 18, 08:05 AM posted to alt.privacy.anon-server,comp.os.linux.advocacy,comp.os.linux.misc,alt.comp.os.windows-10
Wouter Verhelst
external usenet poster
 
Posts: 11
Default Google Enables "Site Isolation" Feature for 99% of Chrome DesktopUsers

On 15-07-18 17:43, Mayayana wrote:
"Wouter Verhelst" wrote

| However, they *do* genuinely care about computer security. This site
| isolation feature of theirs is something that I think is a good idea in
| the face of spectre and meltdown (and friends), and I hope that other
| browsers will follow suit (I suspect firefox will, not so sure about
others)
|

Sounds fine, but it uses more RAM. (+10-13%
according to Google.
https://security.googleblog.com/2018...isolation.html

)


There's always some cost to extra features. I think 10 to 13% is a bit
much, but not surprisingly so.

And how much value does it actually have? What's
the real risk of an attacker getting same-process
(or cross-process) exploitable data from a separate
loaded webpage? Especially if you don't keep numerous
windows/tabs open when you enter a credit card
number online.


Sure, but regular users may not have the background to realize that that
isn't necessarily a good idea.

Then compare that to a typical webpage where
within that one process are connections to numerous,
shady 3rd parties. Acme.com is not usually the problem.
Rather, the problem is likely to be cross-site scripting
or malicious attacks done through buying ads on the
acme.com page you're visiting. That kind of direct attack
is a far greater risk than malware coming through acme.com
that manages to fish your credit card number out of RAM.


The fact that there are other attacks that are more likely does not
negate the fact that site isolation is a good defense against *this*
attack. Are you saying that a browser with defenses against cross-site
scripting *and* the site isolation feature is a worse idea than a
browser with just the defenses against cross-site scripting, in theory?

I agree that there are many holes for cross-site scripting still open,
and that getting those plugged would be great; however, plugging those
holes is not as easy to do as plugging the meltdown/spectre issues.

(And even more mitigated for those of us using AMD.)
With something like an ad-based attack someone can
read your credit card number from within that page and
process.

Anyone who cares at all about security (not
to mention privacy) should at least be limiting
script as much as possible and blocking ad servers
in their HOSTS file, as well as blocking 3rd-parties
where possible.


Well, yes, but that's not something a browser maker can do.

The fears of spectre, meltdown
and shared memory exploits in general have been
grossly overdone.


I agree with that, to some extent, but they are not entirely unfounded
either.

It's like worrying that someone
walking by your house might use a telescope to read
your bankbook in a mirror on your wall, while you've
left your front door ajar.


Not quite.

A malicious site could just start some javascript code that targets one
or more banking sites with a meltdown or spectre-based attack. In more
than 99% of cases it won't find any useful data, but that's the thing
about malicious code; you don't need a huge success rate for it to be
beneficial to the attacker.

The site could start a ServiceWorker[1] if it wanted to be able to
continue the attack even after the user closed the tab in question.

[1] https://developer.mozilla.org/en-US/...ice_Worker_API

Then of course there's the fact that most attacks
are carried out by even more pedestrian methods.
I read the other day that the hacking of Hillary Clinton's
email was accomplished, at least in part, by the kind
of thing that any office worker should know to look
out for: attachments with names like
clinton-campaign.xlsx.com.


For atargetted attack on a specific subject, you would do it that way, yes.

If you just want to get in as many people's bank accounts as possible,
you wouldn't.
Ads