6 ms·

Bonus points for the bug reporters complaining that it's taking years to 'fix' this (which seems like plenty of time to fix their quizzes, given how much free t

by gwern 5y ago

Bonus points for the bug reporters complaining that it's taking years to 'fix' this (which seems like plenty of time to fix their quizzes, given how much free time they apparently have to lobby Google), and for someone observing that the 'solution' is, like all security-by-obscurity fails, already broken (because of devtools). Meanwhile, the code complexity and unintuitive behavior (who would ever expect 'view-source' to have a blacklist or be controllable by the web page?!) will get externalized onto all Chrome users forevermore.

lima 5y ago
> who would ever expect 'view-source' to have a blacklist or be controllable by the web page This is about enterprise policy in a managed environment. It was already able to block a URL - like https://google.com https://google.com - but not view-source:https://google.com https://google.com. Blocking devtools was already possible.
- azeirah 5y ago
  does this prevent you from pasting js like this into the URL bar? javascript:let $code=document.createElement('textarea');let source=document.body.outerHTML;$code.innerHTML = source;document.body.appendChild($code); For those who don't feel like reading a js oneliner, it reads the page source and adds an element to the page that displays all of it.
  - sbierwagen 5y ago
    Does pasting javascript into the URL bar execute it?
    - azeirah 5y ago
      Yes, the `javascript:` prefix tells the browser to interpret the url as javascript. Try this one for example javascript:alert('hello world'); Do note that some browsers remove the `javascript:` part when you paste it into the url bar because it could easily be used maliciously so you might have to type that yourself.
- gwern 5y ago
  > Blocking devtools was already possible. You've patched one hole. How many more are possible? We know where this game goes...
notatoad 5y ago
>who would ever expect 'view-source' to have a blacklist or be controllable by the web page i would expect that when a browser displays source code at a url that looks like view-source://the-url-of-the-page, and gives me a pattern-matching blacklist feature, then blocking view-source://* would block urls matching that pattern. having a blacklist feature that selectively doesn't work on certain types of URLs seems like a bug to me. removing a special-case exclusion is hardly unintuitive behaviour, unless you're using the definition of "unintuitive" that means "something i don't like"
- gwern 5y ago
  No, you would not expect a URL you can render and view and run to then suddenly have view-source blocked, because you are not just viewing the source, you are loading, parsing, and executing it. That's what they are asking for, to browse a URL but then disable view-source (of the URL you are currently successfully browsing).

by gwern 5y ago

lima 5y ago

> who would ever expect 'view-source' to have a blacklist or be controllable by the web page This is about enterprise policy in a managed environment. It was already able to block a URL - like https://google.com https://google.com - but not view-source:https://google.com https://google.com. Blocking devtools was already possible.

azeirah 5y ago
does this prevent you from pasting js like this into the URL bar? javascript:let $code=document.createElement('textarea');let source=document.body.outerHTML;$code.innerHTML = source;document.body.appendChild($code); For those who don't feel like reading a js oneliner, it reads the page source and adds an element to the page that displays all of it.
- sbierwagen 5y ago
  Does pasting javascript into the URL bar execute it?
  - azeirah 5y ago
    Yes, the `javascript:` prefix tells the browser to interpret the url as javascript. Try this one for example javascript:alert('hello world'); Do note that some browsers remove the `javascript:` part when you paste it into the url bar because it could easily be used maliciously so you might have to type that yourself.
gwern 5y ago
> Blocking devtools was already possible. You've patched one hole. How many more are possible? We know where this game goes...

notatoad 5y ago

>who would ever expect 'view-source' to have a blacklist or be controllable by the web page i would expect that when a browser displays source code at a url that looks like view-source://the-url-of-the-page, and gives me a pattern-matching blacklist feature, then blocking view-source://* would block urls matching that pattern. having a blacklist feature that selectively doesn't work on certain types of URLs seems like a bug to me. removing a special-case exclusion is hardly unintuitive behaviour, unless you're using the definition of "unintuitive" that means "something i don't like"

gwern 5y ago
No, you would not expect a URL you can render and view and run to then suddenly have view-source blocked, because you are not just viewing the source, you are loading, parsing, and executing it. That's what they are asking for, to browse a URL but then disable view-source (of the URL you are currently successfully browsing).