4 ms·

> I think it would be a grave mistake to simply give up on mixing code with different trust labels in the same address space. Apart from having to redesign lot

> I think it would be a grave mistake to simply give up on mixing code with different trust labels in the same address space. Apart from having to redesign lot of software, that would set a hard lower bound on the cost of transitioning between trust zones. It would be much better if hardware mitigations can be designed to be usable within a single address space. I wonder what software redesigns he has in mind. As far as I can tell, best practices are already trending toward only one trust zone per address space. Some might argue that that's the whole point of multiple address spaces. I suspect that Spectre will accelerate this trend. I do know how difficult this kind of change can be. The example I have in mind started before Spectre, and is unique to one platform. On Windows, developers of third-party screen readers for the blind are going through a painful transition where they can no longer inject code into application processes in order to make numerous accessibility API calls with low overhead. This change particularly impacts the way screen readers have been making web pages accessible since 1999. For the curious, here's a blog post on this subject: https://www.marcozehe.de/2017/09/29/rethinking-web-accessibility-on-windows/ https://www.marcozehe.de/2017/09/29/rethinking-web-accessibi...

candiodari 9y ago
According to a blind friend of mine, the web, despite the constant touting of it as being great for accessibility, has been a total disaster for accessibility. As you point out, windows applications have much better accessibility (and Microsoft still cares) than most webpages.
- mwcampbell 9y ago
  I'm not surprised by your friend's observations, but that's rather beside the point of my comment. I was simply giving one example I know of a case where redesigning a system to work efficiently across address space boundaries is difficult. I'm curious about other examples, particularly in mainstream applications.
- dotancohen 9y ago
  The Web is great for accessibility in the traditional sense of the word. Information is accessible. The HCI sense of accessibility is completely dependent on the Web page authors. The hoards and hoards of them, who are using a technology that was specifically designed to be used by people with no training in the medium.
  - dcow 9y ago
    Unfortunately when differently-abled people are simply another user segment there is absolutely no way to get business resoures to address them because they sadly aren't your target market. That's been my experience amyway. IMO it's one of the biggest issues with agile: MVPs aren't accessible (among many other things).
    - flukus 9y ago
      I think MVPs are another casualty, having a server spit out html is surely the minimum viable approach?
- nils-m-holm 9y ago
  I have slightly impaired vision, so I need a 30pt font to be able to read comfortably, and the web is already a disaster in terms of accessibility. There are lots of sites that I cannot use, because of overlapping content, unreadable text, hidden buttons, etc.
  - paulie_a 9y ago
    While I doing my solution would work for 30pt fonts, for years I have disabled all fonts and sizes outside of my preferred font and narrow size range
  - hollerith 9y ago
    Same here. The web of 1996 was very accommodating to people (like me) who can read from screens, but need or strongly prefer a larger-than-normal text size, the web of 2018 vastly less so. Some developments that made things harder for me were: Mobile Safari's decision not to reflow the paragraphs when the user does the inverse of the pinch gesture ("zoom"?), which seems to have encouraged the makers of the other browsers to give less priority to reflow even though they did not completely give up on it; at large text sizes, that decision required the user to scroll horizontally left and right for every line of text; Google's purchase of Blogger followed by its changing Blogger so it will not show the reader any text unless Javascript is enabled, which seems to have encouraged other sites to do the same; this made it impossible for me to continue to visit those sites in Lynx (a browser that ran inside a terminal window, but did not support Javascript); HTML5 in general was a disaster for me. For example, at large text sizes, the elements that remain at a fixed position relative to the window regularly end up taking up most of the window's real estate, leaving little room for the text I want to read. Clarification: those have been my frustrations when trying to read what is or easily could have been static content; this comment is not about web apps.
  - Fnoord 9y ago
    Does Firefox "Reader View" feature help you in any kind of way? Or is it that reading isn't the issue, but browsing around is?
    - 9y ago
userbinator 9y ago
On Windows, developers of third-party screen readers for the blind are going through a painful transition where they can no longer inject code into application processes in order to make numerous accessibility API calls with low overhead. All these isolation changes are ostensibly for "security", but I suspect DRM is at least part of the motivation; corporations want to be able to silo content more and restrict the free flow thereof. To a user, a screenreader is a benevolent helper; to them, it's a malicious "attack", a way of extracting and consuming content that they may not want.
- roca 9y ago
  This is absurd. Browsers offer many ways to scrape DOM content that are far more effective than using a screenreader. No doubt there are people who wish DOM content was harder to scrape, but "make screenreaders suck" would be completely ineffective for that, and accusing browser developers of deliberately doing it is slanderous.
  - taeric 9y ago
    Many of the screens people interested with prior to web 2.0 were much more flat in abstraction. You can simply look at early HTML to see how much simpler a document first format looks. The raw number of embedded div elements greatly complicates most screen reading.
    - paulie_a 9y ago
      Except pre 2.0 web was design by tables.
      - taeric 9y ago
        Not really. It was certainly a way to do things. But it was less used than the current plethora of divs. Probably easier to understand programmatically, oddly.
        9y ago
roca 9y ago
The kernel BPF filters come to mind. Any case where people are currently using interpreters to execute untrusted code ... Truetype hinting programs, DWARF debug info ...
- ithkuil 9y ago
  It's easy to overlook the fact that the act of parsing structured input is equivalent to executing code in a VM, and in many cases it can lead to the same class of issues that running code can, especially side channel attacks.
  - infogulch 9y ago
    I have never considered parsing to be equivalent to executing a VM. Does this mean that if you found the right gadgets in the implementation of JSON.parse you could attack a browser just with that?
    - Xylakant 9y ago
      I'm not aware of an instance where browsers were attacked via that vector, but for example Ruby On Rails was vulnerable to attacks via the JSON Parser: https://www.exploit-db.com/exploits/24434/ https://www.exploit-db.com/exploits/24434/ (many other frameworks too, I'm just picking this one because I'm familiar with it)

candiodari 9y ago

According to a blind friend of mine, the web, despite the constant touting of it as being great for accessibility, has been a total disaster for accessibility. As you point out, windows applications have much better accessibility (and Microsoft still cares) than most webpages.

mwcampbell 9y ago
I'm not surprised by your friend's observations, but that's rather beside the point of my comment. I was simply giving one example I know of a case where redesigning a system to work efficiently across address space boundaries is difficult. I'm curious about other examples, particularly in mainstream applications.
dotancohen 9y ago
The Web is great for accessibility in the traditional sense of the word. Information is accessible. The HCI sense of accessibility is completely dependent on the Web page authors. The hoards and hoards of them, who are using a technology that was specifically designed to be used by people with no training in the medium.
- dcow 9y ago
  Unfortunately when differently-abled people are simply another user segment there is absolutely no way to get business resoures to address them because they sadly aren't your target market. That's been my experience amyway. IMO it's one of the biggest issues with agile: MVPs aren't accessible (among many other things).
  - flukus 9y ago
    I think MVPs are another casualty, having a server spit out html is surely the minimum viable approach?
nils-m-holm 9y ago
I have slightly impaired vision, so I need a 30pt font to be able to read comfortably, and the web is already a disaster in terms of accessibility. There are lots of sites that I cannot use, because of overlapping content, unreadable text, hidden buttons, etc.
- paulie_a 9y ago
  While I doing my solution would work for 30pt fonts, for years I have disabled all fonts and sizes outside of my preferred font and narrow size range
- hollerith 9y ago
  Same here. The web of 1996 was very accommodating to people (like me) who can read from screens, but need or strongly prefer a larger-than-normal text size, the web of 2018 vastly less so. Some developments that made things harder for me were: Mobile Safari's decision not to reflow the paragraphs when the user does the inverse of the pinch gesture ("zoom"?), which seems to have encouraged the makers of the other browsers to give less priority to reflow even though they did not completely give up on it; at large text sizes, that decision required the user to scroll horizontally left and right for every line of text; Google's purchase of Blogger followed by its changing Blogger so it will not show the reader any text unless Javascript is enabled, which seems to have encouraged other sites to do the same; this made it impossible for me to continue to visit those sites in Lynx (a browser that ran inside a terminal window, but did not support Javascript); HTML5 in general was a disaster for me. For example, at large text sizes, the elements that remain at a fixed position relative to the window regularly end up taking up most of the window's real estate, leaving little room for the text I want to read. Clarification: those have been my frustrations when trying to read what is or easily could have been static content; this comment is not about web apps.
- Fnoord 9y ago
  Does Firefox "Reader View" feature help you in any kind of way? Or is it that reading isn't the issue, but browsing around is?
  - 9y ago

userbinator 9y ago

On Windows, developers of third-party screen readers for the blind are going through a painful transition where they can no longer inject code into application processes in order to make numerous accessibility API calls with low overhead. All these isolation changes are ostensibly for "security", but I suspect DRM is at least part of the motivation; corporations want to be able to silo content more and restrict the free flow thereof. To a user, a screenreader is a benevolent helper; to them, it's a malicious "attack", a way of extracting and consuming content that they may not want.

roca 9y ago
This is absurd. Browsers offer many ways to scrape DOM content that are far more effective than using a screenreader. No doubt there are people who wish DOM content was harder to scrape, but "make screenreaders suck" would be completely ineffective for that, and accusing browser developers of deliberately doing it is slanderous.
- taeric 9y ago
  Many of the screens people interested with prior to web 2.0 were much more flat in abstraction. You can simply look at early HTML to see how much simpler a document first format looks. The raw number of embedded div elements greatly complicates most screen reading.
  - paulie_a 9y ago
    Except pre 2.0 web was design by tables.
    - taeric 9y ago
      Not really. It was certainly a way to do things. But it was less used than the current plethora of divs. Probably easier to understand programmatically, oddly.
      - 9y ago

roca 9y ago

The kernel BPF filters come to mind. Any case where people are currently using interpreters to execute untrusted code ... Truetype hinting programs, DWARF debug info ...

ithkuil 9y ago
It's easy to overlook the fact that the act of parsing structured input is equivalent to executing code in a VM, and in many cases it can lead to the same class of issues that running code can, especially side channel attacks.
- infogulch 9y ago
  I have never considered parsing to be equivalent to executing a VM. Does this mean that if you found the right gadgets in the implementation of JSON.parse you could attack a browser just with that?
  - Xylakant 9y ago
    I'm not aware of an instance where browsers were attacked via that vector, but for example Ruby On Rails was vulnerable to attacks via the JSON Parser: https://www.exploit-db.com/exploits/24434/ https://www.exploit-db.com/exploits/24434/ (many other frameworks too, I'm just picking this one because I'm familiar with it)