What a failure of Secure by Design looks like: Web Browsers

DA
Dave Aitel
Thu, May 16, 2024 2:48 PM

I know it's in vogue to pick on enterprise hardware marketed to "Secure
your OT Environment" but actually written in crayon in a language made of
all sharp edges like C or PHP, with some modules in Cobol for spice. This
is the "Critical Infrastructure" risk du jour, on a thousand podcasts and
panels, with Volt Typhoon in the canary seat, where once only the
"sophisticated threat" Mirai had root permissions.

As embarrassing as having random Iranian teenagers learn how to do systems
administration on random water plants in New Jersey is, it's more
humiliating to have systemic vulnerabilities right in front of you, have a
huge amount of government brain matter devoted to solving them, and yet not
make the obvious choice to turn off features that are bleeding us out.

And when you talk about market failure in Security you can't help but talk
about Web Browsers, both mobile and desktop. Web Browsing technology is in
everything - and includes a host of technologies too complicated to go
into, but one of the most interesting has been Just in Time compiling,
which got very popular as an exploitation technique (let's say) in 2010
http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf but
since then - for over a decade! - has been a bubbling septic font of
constant systemic, untreated risk.

Proponents of having a JIT in your Javascript compiler say "Without this
kind of performance, you wouldn't be able to have GMail or Expedia!" Which
is not true on today's hardware (Turn on Edge Strict Security mode today
and you won't even notice it), and almost certainly not true on much older
hardware. The issue with JITs is visible to any hacker who has looked at
the code - whenever you have concepts like "Negative Zero
https://googleprojectzero.blogspot.com/2020/09/jitsploitation-one.html"
that have to be gotten perfectly every time or else the attacker gets full
control of your computer, you are in an indefensible space.

I would, in a perfect world, like us to be able to get ahead of systemic
problems. We have a rallying cry and a lot of signatories on a pledge, but
we need to turn it into clicky clicking on the configuration options that
turn these things off on a USG and Enterprise level, the same way we banned
Russian antivirus from having Ring0 in our enterprises, or suspiciously
cheap subsidized Chinese telecom boxes from serving all the phone companies
across the midwest.

The issue with web browsers is not limited to JITs. A Secure By Design
approach to web browsing would mean that most sites would not have access
to large parts of the web browsing specification. We don't need to be
tracked by every website. They don't all need access to Geolocation or
Video or Web Assembly or any number of other parts of the things our web
browsers give them, largely in order to allow the mass production of
targeted advertising.

If we've learned anything in the last decade, it is that the key phrase in
Targeted Advertising is "Targeted", and malware authors have known this for
as long as the ecosystem existed. The reason your browser is insecure by
default is to support a parasitic advertising ecology, enhancing
shareholder value, but leaving our society defenceless against anyone
schooled enough in the dark arts.

Google's current solution to vulnerabilities in the browser is Yet Another
Sandbox. These work for a while until they don't - over time, digital
sandboxes get dirty and filled with secrets just like the one in your
backyard gets filled with presents from the local feral cat community. I
know Project Zero's Samuel Groß is better at browser hacking than I am, and
he personally designed the sandbox, but I look out across the landscape of
the Chinese hacking community and see only hungry vorpal blades and I do
not think it is a winning strategy.

-dave

References:

  1. Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman)
    https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d
  2. The Sandbox: https://v8.dev/blog/sandbox
I know it's in vogue to pick on enterprise hardware marketed to "Secure your OT Environment" but actually written in crayon in a language made of all sharp edges like C or PHP, with some modules in Cobol for spice. This is the "Critical Infrastructure" risk du jour, on a thousand podcasts and panels, with *Volt Typhoon* in the canary seat, where once only the "sophisticated threat" Mirai had root permissions. As embarrassing as having random Iranian teenagers learn how to do systems administration on random water plants in New Jersey is, it's *more* humiliating to have systemic vulnerabilities right in front of you, have a huge amount of government brain matter devoted to solving them, and yet not make the obvious choice to turn off features that are bleeding us out. And when you talk about market failure in Security you can't help but talk about Web Browsers, both mobile and desktop. Web Browsing technology is in everything - and includes a host of technologies too complicated to go into, but one of the most interesting has been Just in Time compiling, which got very popular as an exploitation technique (let's say) in 2010 <http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf> but since then - for over a decade! - has been a bubbling septic font of constant systemic, untreated risk. Proponents of having a JIT in your Javascript compiler say "Without this kind of performance, you wouldn't be able to have GMail or Expedia!" Which is not true on today's hardware (Turn on Edge Strict Security mode today and you won't even notice it), and almost certainly not true on much older hardware. The issue with JITs is visible to any hacker who has looked at the code - whenever you have concepts like "Negative Zero <https://googleprojectzero.blogspot.com/2020/09/jitsploitation-one.html>" that have to be gotten perfectly every time or else the attacker gets full control of your computer, you are in an indefensible space. I would, in a perfect world, like us to be able to get ahead of systemic problems. We have a rallying cry and a lot of signatories on a pledge, but we need to turn it into clicky clicking on the configuration options that turn these things off on a USG and Enterprise level, the same way we banned Russian antivirus from having Ring0 in our enterprises, or suspiciously cheap subsidized Chinese telecom boxes from serving all the phone companies across the midwest. The issue with web browsers is not limited to JITs. A Secure By Design approach to web browsing would mean that most sites would not have access to large parts of the web browsing specification. We don't need to be tracked by every website. They don't all need access to Geolocation or Video or Web Assembly or any number of other parts of the things our web browsers give them, largely in order to allow the mass production of targeted advertising. If we've learned anything in the last decade, it is that the key phrase in Targeted Advertising is "Targeted", and malware authors have known this for as long as the ecosystem existed. The reason your browser is insecure by default is to support a parasitic advertising ecology, enhancing shareholder value, but leaving our society defenceless against anyone schooled enough in the dark arts. Google's current solution to vulnerabilities in the browser is Yet Another Sandbox. These work for a while until they don't - over time, digital sandboxes get dirty and filled with secrets just like the one in your backyard gets filled with presents from the local feral cat community. I know Project Zero's Samuel Groß is better at browser hacking than I am, and he personally designed the sandbox, but I look out across the landscape of the Chinese hacking community and see only hungry vorpal blades and I do not think it is a winning strategy. -dave References: 1. Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman) https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d 2. The Sandbox: https://v8.dev/blog/sandbox
MZ
Michal Zalewski
Thu, May 16, 2024 3:11 PM

As you note, the list is much longer than JIT - web fonts, WebGL, and so on.

But I was there, and many of these decisions weren't about not
grasping the risk, or prioritizing performance for the sake of it.

Rather, they came from a place of terror: look at mobile applications
cannibalizing the browser market share! If we don't give people the
ability to build applications with as much flexibility as they have
natively, the web will start shrinking, and we'll trade an open
platform for a universe of walled gardens tightly controlled by
companies such as Facebook. And you know, it's hard to offer a good
rebuke to that. "Sure, the web might die, but it will die secure".

In practice, yeah, some of this didn't matter. Web fonts were
essential. WebGL enabled some niche applications, but it didn't
revolutionize the platform. Stuff like JS JIT or WebAssembly probably
weren't worth the price. But you only know this in retrospect.

The fundamental problem with browsers is that the current way we think
about them is kind of nuts - i.e., we design them as operating systems
that can safely run untrusted code. But if you started with the
paradigm that you don't want to expose anything risky or unproven to
the world, you'd have ended up with a fairly niche document reader -
plus a lot more native apps and monstrosities such as Java in the
browser or Macromedia Flash. So at what point do you say "enough"?

/mz

On Thu, May 16, 2024 at 8:49 AM Dave Aitel via Dailydave
dailydave@lists.aitelfoundation.org wrote:

I know it's in vogue to pick on enterprise hardware marketed to "Secure your OT Environment" but actually written in crayon in a language made of all sharp edges like C or PHP, with some modules in Cobol for spice. This is the "Critical Infrastructure" risk du jour, on a thousand podcasts and panels, with Volt Typhoon in the canary seat, where once only the "sophisticated threat" Mirai had root permissions.

As embarrassing as having random Iranian teenagers learn how to do systems administration on random water plants in New Jersey is, it's more humiliating to have systemic vulnerabilities right in front of you, have a huge amount of government brain matter devoted to solving them, and yet not make the obvious choice to turn off features that are bleeding us out.

And when you talk about market failure in Security you can't help but talk about Web Browsers, both mobile and desktop. Web Browsing technology is in everything - and includes a host of technologies too complicated to go into, but one of the most interesting has been Just in Time compiling, which got very popular as an exploitation technique (let's say) in 2010 but since then - for over a decade! - has been a bubbling septic font of constant systemic, untreated risk.

Proponents of having a JIT in your Javascript compiler say "Without this kind of performance, you wouldn't be able to have GMail or Expedia!" Which is not true on today's hardware (Turn on Edge Strict Security mode today and you won't even notice it), and almost certainly not true on much older hardware. The issue with JITs is visible to any hacker who has looked at the code - whenever you have concepts like "Negative Zero" that have to be gotten perfectly every time or else the attacker gets full control of your computer, you are in an indefensible space.

I would, in a perfect world, like us to be able to get ahead of systemic problems. We have a rallying cry and a lot of signatories on a pledge, but we need to turn it into clicky clicking on the configuration options that turn these things off on a USG and Enterprise level, the same way we banned Russian antivirus from having Ring0 in our enterprises, or suspiciously cheap subsidized Chinese telecom boxes from serving all the phone companies across the midwest.

The issue with web browsers is not limited to JITs. A Secure By Design approach to web browsing would mean that most sites would not have access to large parts of the web browsing specification. We don't need to be tracked by every website. They don't all need access to Geolocation or Video or Web Assembly or any number of other parts of the things our web browsers give them, largely in order to allow the mass production of targeted advertising.

If we've learned anything in the last decade, it is that the key phrase in Targeted Advertising is "Targeted", and malware authors have known this for as long as the ecosystem existed. The reason your browser is insecure by default is to support a parasitic advertising ecology, enhancing shareholder value, but leaving our society defenceless against anyone schooled enough in the dark arts.

Google's current solution to vulnerabilities in the browser is Yet Another Sandbox. These work for a while until they don't - over time, digital sandboxes get dirty and filled with secrets just like the one in your backyard gets filled with presents from the local feral cat community. I know Project Zero's Samuel Groß is better at browser hacking than I am, and he personally designed the sandbox, but I look out across the landscape of the Chinese hacking community and see only hungry vorpal blades and I do not think it is a winning strategy.

-dave

References:

Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman) https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d
The Sandbox: https://v8.dev/blog/sandbox


Dailydave mailing list -- dailydave@lists.aitelfoundation.org
To unsubscribe send an email to dailydave-leave@lists.aitelfoundation.org

As you note, the list is much longer than JIT - web fonts, WebGL, and so on. But I was there, and many of these decisions weren't about not grasping the risk, or prioritizing performance for the sake of it. Rather, they came from a place of terror: look at mobile applications cannibalizing the browser market share! If we don't give people the ability to build applications with as much flexibility as they have natively, the web will start shrinking, and we'll trade an open platform for a universe of walled gardens tightly controlled by companies such as Facebook. And you know, it's hard to offer a good rebuke to that. "Sure, the web might die, but it will die secure". In practice, yeah, some of this didn't matter. Web fonts were essential. WebGL enabled some niche applications, but it didn't revolutionize the platform. Stuff like JS JIT or WebAssembly probably weren't worth the price. But you only know this in retrospect. The fundamental problem with browsers is that the current way we think about them is kind of nuts - i.e., we design them as operating systems that can safely run untrusted code. But if you started with the paradigm that you don't want to expose anything risky or unproven to the world, you'd have ended up with a fairly niche document reader - plus a lot more native apps and monstrosities such as Java in the browser or Macromedia Flash. So at what point do you say "enough"? /mz On Thu, May 16, 2024 at 8:49 AM Dave Aitel via Dailydave <dailydave@lists.aitelfoundation.org> wrote: > > I know it's in vogue to pick on enterprise hardware marketed to "Secure your OT Environment" but actually written in crayon in a language made of all sharp edges like C or PHP, with some modules in Cobol for spice. This is the "Critical Infrastructure" risk du jour, on a thousand podcasts and panels, with Volt Typhoon in the canary seat, where once only the "sophisticated threat" Mirai had root permissions. > > As embarrassing as having random Iranian teenagers learn how to do systems administration on random water plants in New Jersey is, it's more humiliating to have systemic vulnerabilities right in front of you, have a huge amount of government brain matter devoted to solving them, and yet not make the obvious choice to turn off features that are bleeding us out. > > And when you talk about market failure in Security you can't help but talk about Web Browsers, both mobile and desktop. Web Browsing technology is in everything - and includes a host of technologies too complicated to go into, but one of the most interesting has been Just in Time compiling, which got very popular as an exploitation technique (let's say) in 2010 but since then - for over a decade! - has been a bubbling septic font of constant systemic, untreated risk. > > Proponents of having a JIT in your Javascript compiler say "Without this kind of performance, you wouldn't be able to have GMail or Expedia!" Which is not true on today's hardware (Turn on Edge Strict Security mode today and you won't even notice it), and almost certainly not true on much older hardware. The issue with JITs is visible to any hacker who has looked at the code - whenever you have concepts like "Negative Zero" that have to be gotten perfectly every time or else the attacker gets full control of your computer, you are in an indefensible space. > > I would, in a perfect world, like us to be able to get ahead of systemic problems. We have a rallying cry and a lot of signatories on a pledge, but we need to turn it into clicky clicking on the configuration options that turn these things off on a USG and Enterprise level, the same way we banned Russian antivirus from having Ring0 in our enterprises, or suspiciously cheap subsidized Chinese telecom boxes from serving all the phone companies across the midwest. > > The issue with web browsers is not limited to JITs. A Secure By Design approach to web browsing would mean that most sites would not have access to large parts of the web browsing specification. We don't need to be tracked by every website. They don't all need access to Geolocation or Video or Web Assembly or any number of other parts of the things our web browsers give them, largely in order to allow the mass production of targeted advertising. > > If we've learned anything in the last decade, it is that the key phrase in Targeted Advertising is "Targeted", and malware authors have known this for as long as the ecosystem existed. The reason your browser is insecure by default is to support a parasitic advertising ecology, enhancing shareholder value, but leaving our society defenceless against anyone schooled enough in the dark arts. > > Google's current solution to vulnerabilities in the browser is Yet Another Sandbox. These work for a while until they don't - over time, digital sandboxes get dirty and filled with secrets just like the one in your backyard gets filled with presents from the local feral cat community. I know Project Zero's Samuel Groß is better at browser hacking than I am, and he personally designed the sandbox, but I look out across the landscape of the Chinese hacking community and see only hungry vorpal blades and I do not think it is a winning strategy. > > -dave > > References: > > Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman) https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d > The Sandbox: https://v8.dev/blog/sandbox > > > > > _______________________________________________ > Dailydave mailing list -- dailydave@lists.aitelfoundation.org > To unsubscribe send an email to dailydave-leave@lists.aitelfoundation.org
DA
Dave Aitel
Tue, Jun 4, 2024 1:06 AM

[image: image.png]
So on one hand, a net completely controlled by Facebook and Apple and every
other walled off application "garden" would be a terrible thing. And yet,
did we not get just that in a manner of speaking? How healthy would we say
the net is right now?

Also, I find the security argument against extensions
https://cybernews.com/privacy/google-to-weaken-chrome-ad-blockers-push-for-security/#:~:text=Starting%20June%202024%2C%20adblockers%20such,the%20more%20limited%20V3%20version.
that block ads very weird. Apparently this goes into practice this month?
It's always been weird that mobile browsers are not allowed to have ad
blockers. Does anyone have depth on this issue they can actually share?

-dave

On Thu, May 16, 2024 at 11:11 AM Michal Zalewski lcamtuf@coredump.cx
wrote:

As you note, the list is much longer than JIT - web fonts, WebGL, and so
on.

But I was there, and many of these decisions weren't about not
grasping the risk, or prioritizing performance for the sake of it.

Rather, they came from a place of terror: look at mobile applications
cannibalizing the browser market share! If we don't give people the
ability to build applications with as much flexibility as they have
natively, the web will start shrinking, and we'll trade an open
platform for a universe of walled gardens tightly controlled by
companies such as Facebook. And you know, it's hard to offer a good
rebuke to that. "Sure, the web might die, but it will die secure".

In practice, yeah, some of this didn't matter. Web fonts were
essential. WebGL enabled some niche applications, but it didn't
revolutionize the platform. Stuff like JS JIT or WebAssembly probably
weren't worth the price. But you only know this in retrospect.

The fundamental problem with browsers is that the current way we think
about them is kind of nuts - i.e., we design them as operating systems
that can safely run untrusted code. But if you started with the
paradigm that you don't want to expose anything risky or unproven to
the world, you'd have ended up with a fairly niche document reader -
plus a lot more native apps and monstrosities such as Java in the
browser or Macromedia Flash. So at what point do you say "enough"?

/mz

On Thu, May 16, 2024 at 8:49 AM Dave Aitel via Dailydave
dailydave@lists.aitelfoundation.org wrote:

I know it's in vogue to pick on enterprise hardware marketed to "Secure

your OT Environment" but actually written in crayon in a language made of
all sharp edges like C or PHP, with some modules in Cobol for spice. This
is the "Critical Infrastructure" risk du jour, on a thousand podcasts and
panels, with Volt Typhoon in the canary seat, where once only the
"sophisticated threat" Mirai had root permissions.

As embarrassing as having random Iranian teenagers learn how to do

systems administration on random water plants in New Jersey is, it's more
humiliating to have systemic vulnerabilities right in front of you, have a
huge amount of government brain matter devoted to solving them, and yet not
make the obvious choice to turn off features that are bleeding us out.

And when you talk about market failure in Security you can't help but

talk about Web Browsers, both mobile and desktop. Web Browsing technology
is in everything - and includes a host of technologies too complicated to
go into, but one of the most interesting has been Just in Time compiling,
which got very popular as an exploitation technique (let's say) in 2010 but
since then - for over a decade! - has been a bubbling septic font of
constant systemic, untreated risk.

Proponents of having a JIT in your Javascript compiler say "Without this

kind of performance, you wouldn't be able to have GMail or Expedia!" Which
is not true on today's hardware (Turn on Edge Strict Security mode today
and you won't even notice it), and almost certainly not true on much older
hardware. The issue with JITs is visible to any hacker who has looked at
the code - whenever you have concepts like "Negative Zero" that have to be
gotten perfectly every time or else the attacker gets full control of your
computer, you are in an indefensible space.

I would, in a perfect world, like us to be able to get ahead of systemic

problems. We have a rallying cry and a lot of signatories on a pledge, but
we need to turn it into clicky clicking on the configuration options that
turn these things off on a USG and Enterprise level, the same way we banned
Russian antivirus from having Ring0 in our enterprises, or suspiciously
cheap subsidized Chinese telecom boxes from serving all the phone companies
across the midwest.

The issue with web browsers is not limited to JITs. A Secure By Design

approach to web browsing would mean that most sites would not have access
to large parts of the web browsing specification. We don't need to be
tracked by every website. They don't all need access to Geolocation or
Video or Web Assembly or any number of other parts of the things our web
browsers give them, largely in order to allow the mass production of
targeted advertising.

If we've learned anything in the last decade, it is that the key phrase

in Targeted Advertising is "Targeted", and malware authors have known this
for as long as the ecosystem existed. The reason your browser is insecure
by default is to support a parasitic advertising ecology, enhancing
shareholder value, but leaving our society defenceless against anyone
schooled enough in the dark arts.

Google's current solution to vulnerabilities in the browser is Yet

Another Sandbox. These work for a while until they don't - over time,
digital sandboxes get dirty and filled with secrets just like the one in
your backyard gets filled with presents from the local feral cat community.
I know Project Zero's Samuel Groß is better at browser hacking than I am,
and he personally designed the sandbox, but I look out across the landscape
of the Chinese hacking community and see only hungry vorpal blades and I do
not think it is a winning strategy.

-dave

References:

Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman)

The Sandbox: https://v8.dev/blog/sandbox


Dailydave mailing list -- dailydave@lists.aitelfoundation.org
To unsubscribe send an email to

[image: image.png] So on one hand, a net completely controlled by Facebook and Apple and every other walled off application "garden" would be a terrible thing. And yet, did we not get just that in a manner of speaking? How healthy would we say the net is right now? Also, I find the security argument against extensions <https://cybernews.com/privacy/google-to-weaken-chrome-ad-blockers-push-for-security/#:~:text=Starting%20June%202024%2C%20adblockers%20such,the%20more%20limited%20V3%20version.> that block ads very weird. Apparently this goes into practice this month? It's always been weird that mobile browsers are not allowed to have ad blockers. Does anyone have depth on this issue they can actually share? -dave On Thu, May 16, 2024 at 11:11 AM Michal Zalewski <lcamtuf@coredump.cx> wrote: > As you note, the list is much longer than JIT - web fonts, WebGL, and so > on. > > But I was there, and many of these decisions weren't about not > grasping the risk, or prioritizing performance for the sake of it. > > Rather, they came from a place of terror: look at mobile applications > cannibalizing the browser market share! If we don't give people the > ability to build applications with as much flexibility as they have > natively, the web will start shrinking, and we'll trade an open > platform for a universe of walled gardens tightly controlled by > companies such as Facebook. And you know, it's hard to offer a good > rebuke to that. "Sure, the web might die, but it will die secure". > > In practice, yeah, some of this didn't matter. Web fonts were > essential. WebGL enabled some niche applications, but it didn't > revolutionize the platform. Stuff like JS JIT or WebAssembly probably > weren't worth the price. But you only know this in retrospect. > > The fundamental problem with browsers is that the current way we think > about them is kind of nuts - i.e., we design them as operating systems > that can safely run untrusted code. But if you started with the > paradigm that you don't want to expose anything risky or unproven to > the world, you'd have ended up with a fairly niche document reader - > plus a lot more native apps and monstrosities such as Java in the > browser or Macromedia Flash. So at what point do you say "enough"? > > /mz > > On Thu, May 16, 2024 at 8:49 AM Dave Aitel via Dailydave > <dailydave@lists.aitelfoundation.org> wrote: > > > > I know it's in vogue to pick on enterprise hardware marketed to "Secure > your OT Environment" but actually written in crayon in a language made of > all sharp edges like C or PHP, with some modules in Cobol for spice. This > is the "Critical Infrastructure" risk du jour, on a thousand podcasts and > panels, with Volt Typhoon in the canary seat, where once only the > "sophisticated threat" Mirai had root permissions. > > > > As embarrassing as having random Iranian teenagers learn how to do > systems administration on random water plants in New Jersey is, it's more > humiliating to have systemic vulnerabilities right in front of you, have a > huge amount of government brain matter devoted to solving them, and yet not > make the obvious choice to turn off features that are bleeding us out. > > > > And when you talk about market failure in Security you can't help but > talk about Web Browsers, both mobile and desktop. Web Browsing technology > is in everything - and includes a host of technologies too complicated to > go into, but one of the most interesting has been Just in Time compiling, > which got very popular as an exploitation technique (let's say) in 2010 but > since then - for over a decade! - has been a bubbling septic font of > constant systemic, untreated risk. > > > > Proponents of having a JIT in your Javascript compiler say "Without this > kind of performance, you wouldn't be able to have GMail or Expedia!" Which > is not true on today's hardware (Turn on Edge Strict Security mode today > and you won't even notice it), and almost certainly not true on much older > hardware. The issue with JITs is visible to any hacker who has looked at > the code - whenever you have concepts like "Negative Zero" that have to be > gotten perfectly every time or else the attacker gets full control of your > computer, you are in an indefensible space. > > > > I would, in a perfect world, like us to be able to get ahead of systemic > problems. We have a rallying cry and a lot of signatories on a pledge, but > we need to turn it into clicky clicking on the configuration options that > turn these things off on a USG and Enterprise level, the same way we banned > Russian antivirus from having Ring0 in our enterprises, or suspiciously > cheap subsidized Chinese telecom boxes from serving all the phone companies > across the midwest. > > > > The issue with web browsers is not limited to JITs. A Secure By Design > approach to web browsing would mean that most sites would not have access > to large parts of the web browsing specification. We don't need to be > tracked by every website. They don't all need access to Geolocation or > Video or Web Assembly or any number of other parts of the things our web > browsers give them, largely in order to allow the mass production of > targeted advertising. > > > > If we've learned anything in the last decade, it is that the key phrase > in Targeted Advertising is "Targeted", and malware authors have known this > for as long as the ecosystem existed. The reason your browser is insecure > by default is to support a parasitic advertising ecology, enhancing > shareholder value, but leaving our society defenceless against anyone > schooled enough in the dark arts. > > > > Google's current solution to vulnerabilities in the browser is Yet > Another Sandbox. These work for a while until they don't - over time, > digital sandboxes get dirty and filled with secrets just like the one in > your backyard gets filled with presents from the local feral cat community. > I know Project Zero's Samuel Groß is better at browser hacking than I am, > and he personally designed the sandbox, but I look out across the landscape > of the Chinese hacking community and see only hungry vorpal blades and I do > not think it is a winning strategy. > > > > -dave > > > > References: > > > > Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman) > https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d > > The Sandbox: https://v8.dev/blog/sandbox > > > > > > > > > > _______________________________________________ > > Dailydave mailing list -- dailydave@lists.aitelfoundation.org > > To unsubscribe send an email to > dailydave-leave@lists.aitelfoundation.org >
MZ
Michal Zalewski
Tue, Jun 4, 2024 1:39 AM

Also, I find the security argument against extensions
https://cybernews.com/privacy/google-to-weaken-chrome-ad-blockers-push-for-security/#:~:text=Starting%20June%202024%2C%20adblockers%20such,the%20more%20limited%20V3%20version.
that block ads very weird. Apparently this goes into practice this month?
It's always been weird that mobile browsers are not allowed to have ad
blockers. Does anyone have depth on this issue they can actually share?

The security argument is fairly good in the sense that the extension
security model is broken. It's not even about ad blockers: far too many
extensions request overly broad permissions and then either do sneaky
things (e.g., "monetizing" users by stealing browsing histories) or put
users at risk. It doesn't help that if you pop a developer's account, you
can essentially deploy a backdoored extension to all users instantly.

But, there are many ways to improve this, and Google has chosen an approach
that is inherently controversial given that they're an ad company and that
their other divisions are openly waging a war on ad blocking right now.

/mz

> > Also, I find the security argument against extensions > <https://cybernews.com/privacy/google-to-weaken-chrome-ad-blockers-push-for-security/#:~:text=Starting%20June%202024%2C%20adblockers%20such,the%20more%20limited%20V3%20version.> > that block ads very weird. Apparently this goes into practice this month? > It's always been weird that mobile browsers are not allowed to have ad > blockers. Does anyone have depth on this issue they can actually share? > The security argument is fairly good in the sense that the extension security model is broken. It's not even about ad blockers: far too many extensions request overly broad permissions and then either do sneaky things (e.g., "monetizing" users by stealing browsing histories) or put users at risk. It doesn't help that if you pop a developer's account, you can essentially deploy a backdoored extension to all users *instantly*. But, there are many ways to improve this, and Google has chosen an approach that is inherently controversial given that they're an ad company and that their other divisions are openly waging a war on ad blocking right now. /mz
AG
Andre Gironda
Tue, Jun 4, 2024 3:37 AM

On Mon, Jun 3, 2024 at 8:12 PM Dave Aitel via Dailydave <
dailydave@lists.aitelfoundation.org> wrote:

So on one hand, a net completely controlled by Facebook and Apple and
every other walled off application "garden" would be a terrible thing. And
yet, did we not get just that in a manner of speaking? How healthy would we
say the net is right now?

The problem of ads or things-in things is in a poor state. It's bad on
every stack, every ecosystem. Ads or SEO poisoning bubbled up this
crimeware-to ransomware via "Bing AI Chat" --
https://www.bleepingcomputer.com/news/security/bing-chat-responses-infiltrated-by-ads-pushing-malware/
Try asking your AI buddy a download link for Advanced IP Scanner

and there's been other strange stories such as this one --
https://www.scmp.com/tech/tech-trends/article/3246612/chatgpt-aided-ransomware-china-results-four-arrests-ai-raises-cybersecurity-concerns
-- (read on https://archive.is/qZfPg )

On Mon, Jun 3, 2024 at 8:12 PM Dave Aitel via Dailydave < dailydave@lists.aitelfoundation.org> wrote: > So on one hand, a net completely controlled by Facebook and Apple and > every other walled off application "garden" would be a terrible thing. And > yet, did we not get just that in a manner of speaking? How healthy would we > say the net is right now? > The problem of ads or things-in things is in a poor state. It's bad on every stack, every ecosystem. Ads or SEO poisoning bubbled up this crimeware-to ransomware via "Bing AI Chat" -- https://www.bleepingcomputer.com/news/security/bing-chat-responses-infiltrated-by-ads-pushing-malware/ Try asking your AI buddy a download link for Advanced IP Scanner and there's been other strange stories such as this one -- https://www.scmp.com/tech/tech-trends/article/3246612/chatgpt-aided-ransomware-china-results-four-arrests-ai-raises-cybersecurity-concerns -- (read on https://archive.is/qZfPg )
TR
Tom Ritter
Tue, Jun 4, 2024 4:14 PM

On Mon, 3 Jun 2024 at 23:18, Dave Aitel via Dailydave <
dailydave@lists.aitelfoundation.org> wrote:

It's always been weird that mobile browsers are not allowed to have ad
blockers. Does anyone have depth on this issue they can actually share?

Speaking about (but not for - this is just how I interpreted it) Firefox -
mostly sausage making and org pains. Fennec (the old mobile architecture)
supported extensions, although I don't remember to what extent/how well. In
2016 it got WebExtension support - before that it was supporting extensions
in the old style of "Just let them do whatever they want in the browser,
I'm sure it will be fine.[0]" And in late 2017 we removed access to those
capabilities. Somewhere around 2019 we switched from the old browser
architecture (Fennec) to the new one (Fenix) - and 2019 was when we
launched, so we started the development quite some time earlier and kept
Fennec on life support during it.

Fenix - while not a total rewrite of the rendering or js engine - was a
rewrite of everything else, including the UI, accounts, sync, telemetry,
session storage, push, reader view, downloads, etc etc. [1] Getting a
consistent and reliable handle on the Android OS process management also
took time[2] - running extensions in the parent meant the parent got reaped
a lot; they needed to be moved to a separate process, and then we needed to
handle how to behave when that process got reaped but others did not.
Fenix supported a curated list of extensions (including Ghostery, AdGuard,
and uBlock Origin) for a while, but in the past 6 months finally hit the
milestone where it opened up so anyone can publish, and anyone can install,
an extension on Android without jumping through hoops.

Add into all of this mix a couple rounds of layoffs including the big one
in 2020, which disrupted a lot of things. (And, you know, the pandemic.) I
don't know/remember if anyone directly working on Fenix was let go,
although I would wager yes, but I do know many mobile engineers in
non-Firefox products were let go and I have to assume the knowledge drain,
upheaval, and hurt when your colleagues are let go led to departures and
general delays in what people originally hoped to accomplish.

Anyway, I don't know if you wanted more technical nitty-gritty on it, but
from my perspective, that's what I can offer. I don't think there was any
specific de-prioritization of extensions from a philosophical standpoint
(we all know that extensions are what made Firefox what it is), just
juggling lots of work that resulted in a slower rollout than we hoped.

-tom

ref: https://blog.mozilla.org/addons/page/1/?s=android

[0] Narrator: It was not fine.
[1] Unsurprisingly we've been playing whack-a-mole with re-implementations
of the annoying 'yes it's a bug but no one exploits
address-bar-impersonation so =/' class of bugs.
[2] 'Takes time' is both engineering time and wall-time as you write code,
deploy it, run an experiment, and wait for results.

On Mon, 3 Jun 2024 at 23:18, Dave Aitel via Dailydave < dailydave@lists.aitelfoundation.org> wrote: > It's always been weird that mobile browsers are not allowed to have ad > blockers. Does anyone have depth on this issue they can actually share? > Speaking about (but not for - this is just how I interpreted it) Firefox - mostly sausage making and org pains. Fennec (the old mobile architecture) supported extensions, although I don't remember to what extent/how well. In 2016 it got WebExtension support - before that it was supporting extensions in the old style of "Just let them do whatever they want in the browser, I'm sure it will be fine.[0]" And in late 2017 we removed access to those capabilities. Somewhere around 2019 we switched from the old browser architecture (Fennec) to the new one (Fenix) - and 2019 was when we launched, so we started the development quite some time earlier and kept Fennec on life support during it. Fenix - while not a total rewrite of the rendering or js engine - was a rewrite of everything else, including the UI, accounts, sync, telemetry, session storage, push, reader view, downloads, etc etc. [1] Getting a consistent and reliable handle on the Android OS process management also took time[2] - running extensions in the parent meant the parent got reaped a lot; they needed to be moved to a separate process, and then we needed to handle how to behave when _that_ process got reaped but others did not. Fenix supported a curated list of extensions (including Ghostery, AdGuard, and uBlock Origin) for a while, but in the past 6 months finally hit the milestone where it opened up so anyone can publish, and anyone can install, an extension on Android without jumping through hoops. Add into all of this mix a couple rounds of layoffs including the big one in 2020, which disrupted a lot of things. (And, you know, the pandemic.) I don't know/remember if anyone directly working on Fenix was let go, although I would wager yes, but I do know many *mobile* engineers in non-Firefox products were let go and I have to assume the knowledge drain, upheaval, and hurt when your colleagues are let go led to departures and general delays in what people originally hoped to accomplish. Anyway, I don't know if you wanted more technical nitty-gritty on it, but from my perspective, that's what I can offer. I don't think there was any specific de-prioritization of extensions from a philosophical standpoint (we all know that extensions are what made Firefox what it is), just juggling lots of work that resulted in a slower rollout than we hoped. -tom ref: https://blog.mozilla.org/addons/page/1/?s=android [0] Narrator: It was not fine. [1] Unsurprisingly we've been playing whack-a-mole with re-implementations of the annoying 'yes it's a bug but no one exploits address-bar-impersonation so =/' class of bugs. [2] 'Takes time' is both engineering time and wall-time as you write code, deploy it, run an experiment, and wait for results.