For context, this is is not allowing websites to prevent View Source for all users. Rather it is a setting that administrators can set on Google Chrome installations within their company/school/etc.
That said, I highly doubt that Google would take this feature request seriously if this were not associated with another Google property. For example, I can't imagine that if Typeform users opened a similar bug ticket that it would see any traction. To me this highlights a danger I had not considered before around the monopoly power of Google - inane requests that would benefit properties within the Google ecosystem get undue consideration despite it harming the broader ecosystem.
The bug is from 2018, and was fixed three years later. So it doesn't seem like there was any kind of special prioritization going on here. It was also fixed by a person working at Microsoft, not by somebody at Google.
Yes, I understand that's that was the point. But again, Google clearly didn't actually particularly want this since nobody from that company actually worked on this bug during the three years it was open.
Your suggestion seems equally invalid. The Chromium bug tracker currently has about 9k open feature requests. A lot of them are more niche than this, have no indication on the bug that they're relevant to Google, and have still not been closed as WONTFIX.
So it really was not a valid point to start with, and I don't understand why you're doubling down on it like that.
As shown in the changelog, the bug was filed by a user @amplifiedit.com, and was seen as a worthwhile bug to fix by Brian Malcolm "Taking ownership as the client team in BVE will work on this item"[0]; however, it was stalled for nearly 3 years until Eric submitted a patch for it[1]. While Google thinks it's worthwhile to fix, Microsoft is trying to have a faster-than-usual rise in adoption for their new Edge which is based on Chromium, so that means fixing as many things as possible that their business/EDU customers complain about.
BTW Google already allowed MDM (device) admins to disable devtools, but everyone involved in the issue also wanted it to disable view-source since it allowed students to look at the HTML.
Is it remotely possible to vote against this policy? Who controls Chromium features – I know it's open source and thus one could always fork it, but how is the project governed? "Benign" dictatorship?
The best way to vote against changes like this is to use Firefox. The people who govern the project will pay attention to market share much better than anything else other than forking the project.
I think you may have some core assumption that open source software has a voting system when none really exists and it’s either a committee or a corporation that gives no voting rights whatsoever. Participation instead gets things in when your are both trusted and the governance approves.
You think you should get to vote against other people's local policies? Just you, or do we each get a vote? Where do I get my list of your policies in case I need to vote against some of them?
That's a rather aggressive way of answering my question. I meant "who decided to let chromium disable view-source, and if this decision is unpopular, can it be reconsidered?".
Your local policy is yours, but in much the same way that I don't think it's a good idea for an OS provider to provide a single, easy-to-use button saying "spy on this user who I pinky-swear is a member of my family under 18 and tell me everything they do and where their mobile is", an option to permit the disabling of view-source in a mainstream browser does not fit easily with me. I accept that there might be some situations in which you'd want to do it, but honestly it's the thin-edge of the wedge.
"Benign dictatorship" is a common form of open-source project governance; it's not unreasonable to expect that is the case here (with Google, or a part of it, as the dictator). That being said, many open-source projects are managed in a way other than "benign dictatorship". Debian, for example, famously uses the Condorcet method [1] if there are any significant ideological disputes; see this vote [2] about Richard Stallman for an example.
To my mind, a browser supporting -- in whatever form -- an option to disallow "view-source" could well be a controversial enough decision to necessitate a vote through this means. I don't know how Chromium is governed, and all I meant to do was ask how.
Isn't it closing the hole that allowed you to bypass the blocklist by using source viewer rather than adding a way to block viewing the source altogether?
> With Schools using Google Forms as a testing platform, students are able to use this shortcut to search through the source of the page, and determine the correct answers.
So they're serving the answers with the questions, and get annoyed when the students figure this out. What a lark. How about using a system which doesn't do that?
This is also the type of thing that plants the seed of interest for a career or hobby of computing, which is another reason it's stupid. Reward people's curiousity instead of punishing it, especially in a schooling situation!
I got a crash course in running proxy servers and various VPNs when I was in school, due to the school blocking stuff. I don't recall what sites I was even trying to get to (pre-facebook) nor do I remember really caring about them, but just working around the blocks was particularly fun.
I had a similar experience, but in my case it was less that the school was blocking particular sites I wanted to visit, and more that there was a single very-slow proxy server for the entire state's educational system. So I ssh tunneled to my home instead.
I wonder what chain of events lead this PR being filed.
How did the kid(s) get caught? Did a teacher decide to tell the IT department head? Did the head of department then tell the IT maintenance team? Then the IT maintenance team told the test vendor?
Very odd chain of events to lead to such a dangerous change.
These types of "hacks" spread very quickly in school. Once the flaw is discovered, the entire class likely "aced" the test. From there, it's pretty obvious how the vendor found out: the school could no longer use the testing software and demanded an answer.
And since the student taking the quiz very frequently has no choice over whether or not they have to be there or take the quiz, their desires and goals are entirely irrelevant.
Edit: are you intentionally or unintentionally trying to justify any and all cheating as a means to get the highest grade possible?
But perhaps they will get by in life by finding clever solutions that circumvent common expectations through curiosity and familiarity with technology.
I think it’s easy to imagine cheating in a post-school context: copying code from a project your employer doesn’t own into one it does. And that has huge legal ramifications. So students do need to learn about those kinds of restrictions via analogues.
Which is why I accounted for that scenario. Breaking the law is applicable post-school, "cheating" outside of illegality is just thinking outside the box.
I was trying to speak figuratively, not literally. Any programmer will need to look at source code to solve problems, but that's not what I was getting at.
When you're taking a math quiz, the goal is to learn how to solve math problems, not bypassing the quiz.
What I really should have said is that in life, shortcuts aren't always appropriate. If you're an engineer confronted with the task of calculating the load the bridge can take, you're supposed to do the hard slog of calculating how much the bridge will take. Let's suppose that engineer didn't understand math, but simply cheated their way through University and took a guess - will you be stepping foot on the bridge?
Teaching kids it's okay to take inappropriate shortcuts is bad, because in the real world, inappropriate shortcuts can have nasty consequences.
Yeah. There's bizarre situations where 'view source' shouldn't really be necessary/beneficial and yet somehow it's a handy life skill. I remember doing it while booking a flight on RyanAir (Very bad website. I knew the option to not pay for extra insurance had to be on the page somewhere!)
Google Forms lets you set an answer key with correct answers which are not exposed client-side in the responder view[1]. Teachers complaining that students can see "answers" are using a different feature[2].
I’m not that surprised tbh. A couple of years back the Chrome Dev Summit quiz did the same thing. I thought that was the joke (“haha, they’re requesting allanswers.json at startup”), and didn’t realize it was apparently unintentional until they revealed I was in first place at the end of the day.
It's funny that 15-20 years ago when real HTML forms were the norm for stuff like this, this wouldn't be a problem. It's only one created by the reliance (or default?) to client-side JS for everything.
1. I landed this fix because there was a policy that did not work properly. We could instead document that the URLBlocklist policy works for every scheme but one, or we could fix it. Fixing it makes more sense.
2. This policy only can be set on managed machines.
3. This policy, in isolation, is trivially circumvented. Managed environments block many things, including many of the proposed circumventions here.
4. I've built one of the world's most popular tools for viewing and modifying web traffic. The narrative that this feature has broad implications for anything is absurd.
Many of the best people in IT are there today, because they got curious about how stuff worked, experimented with it, broke the rules, and learned from that. This curiosity needs to be encouraged, not stopped.
The young generation in IT already has issues because many of them don’t understand files, and many of them can’t even use a computer anymore.
They grow up with tech all around them, but because all of it is closed and proprietary and restricted, they never even try to look behind the curtain.
We call ourselves software engineers, then we also need to take on the ethical responsibility of our actions just like engineers do.
If you contribute to this culture of closed technology, you are just as well at fault as developers of DRM tech or Android SafetyNet.
Amen to that! Sadly, it's easier to persuade the population (and hence squeeze the $$$ out of them) when they are kept docile, unknowing, and unquestioning. Knowledge is power, and they don't want you to have too much.
Some students get a managed device from their school - and are allowed to take it home.
There have been already some scandals revolving around those devices. From school accessing their webcam - and trying to discipline someone for taking drugs when they ate jelly beans.
Most of the students using chromebooks at university or school do not have own computers at home. These devices are all they've got to access the internet.
Every experience they'll make during their teenage years with computers is shaped by these managed experiences.
Just because it's legacy, doesn't mean it's not a powerful tool.
Files have multiple advantages over other approaches, such as being independent from the application that created them (even if the company subsequently goes under), being editable with a different application from the one that created them (though imperfectly sometimes), and being self-contained bundles of data that need no infrastructure to support them other than a local application (compared to other approaches, where a large cloud infrastructure is basically mandatory and you're SOL if it goes away for you).
Recency bias is a thing. Try to work counter to it.
First of all: thank you for taking the time to respond to the irate crowd.
Second: It's still a really bad idea, because it feeds into the narrative that inherently unsafe client side restrictions are a viable security barrier e.g. dangerously incompetent politicians like Mike Parson already want to put the F12 key behind bars rather than admit to leaking PII on official websites.
You guys are giving administrators way too much power without any good reasons.
I realize that if they really wanted, they could give up on Chrome and use something else, but for many of them, they will simply lock everything down out of laziness and probably wouldn't without a convenient way of doing so.
An example out of many: why give admins a simple way to disable the built-in password manager? This just enables dumb and archaic password policies for no good reason.
As to your last question, many organizations have a central password management system that lets them audit who uses which password and when. Having the passwords stored in a secondary system makes the audits useless.
> > "NOTE: [RFC7258] treats pervasive monitoring as an attack, but it doesn’t apply to managed devices."
> We don't think this is adequate. Given the power dynamics at play in an employer-employee relationship, the UA should still be working in the best interests of the end-user (the employee) even if the device being used is managed by an administrator. That is to say, pervasive monitoring is never a feature.
Chrome may not consider it part of the "web-exposed platform", since the code doesn't live in blink/, but the same logic applies to view-source. The needs of the users are more important than the security theatre you wish to put on for their teacher's benefit.
> We could instead document that the URLBlocklist policy works for every scheme but one, or we could fix it. Fixing it makes more sense.
What makes more sense - a small documentation update to explain an edge case scenario, or a breaking change across the web? Hint: it's not the one that involves code changes.
>2. This policy only can be set on managed machines.
What about kids in school? So only the poor kids who don't have access to their own hardware will be subject to these rules that prevent them from viewing source? Sounds pretty insane.
What's truly absurd is the apparent lack of critical thought that went into this decision.
Keep patting yourself on the back though, Eric. You're obviously totally 100% right on this one /s
I don't know how to phrase this without it sounding like an attack which I absolutely do not mean it to sound like. But when considering if I would like to receive this same message, I would be more discouraged if someone didn't try to respond because they were afraid to upset me, than if they said something I (or wy ego) didn't want to hear. This preamble is only to make it clear that I'm not trying to be mean, for whatever small value that may be.
I've responded here https://news.ycombinator.com/item?id=29213370 I'd bet it's pretty obvious the internet thinks this was a mistake (and we all know how sound and reasonable the internet always is :D ) but I thought the why it's so infuriating was important to point out too.
You're, a moron, I guess? I mean, you work for Microsoft, so you clearly have 0 qualms about supporting the legacy of a robber baron college drop out who plagiarized actual researchers in the field of computer science, multiple times.
Have you ever been a LISA scale administrator? A K-12 level County Office of Education administrator? Have you ever helped patch embargoed bugs in codebases such as BIND, used billions of times per hour by oh, more or less everyone online?
Were you buddies with Doug Engelbart?
Do you have anything personally signed by Dr. Marshall Kirk McKusick?
Have you ever even met Tim Berners-Lee?
What about John Gilmore?
I'm guessing, your answer to those rhetorical questions would be no, but please: surprise me!
What uhh, "world's most popular tools for viewing and modifying web traffic" did you build? Because, this is the first time I have ever encountered you, and I have been root/Enterprise Admins/enable/etc/sudoers/wheel/etc. for the company which runs the cross-browser development framework utilized by Fortune 1 among others. I know a lot of people in this field going back to the 1970s, at least, and you found about the worst wage imaginable to become known to my periphery.
Moreover, since this is not NNTP, and I am guessing you are too young to even know what it means when someone writes: "welcome to my .killfile" do you want to have a career in this, or any other solar system in the next several lifetimes?
Because I am betting on: you will be in the realm of: no one, anywhere, ever, will want to hire you, ever, again from what I have read from you so far, and yes, I spent the time to peruse your pathetic commits since 2019 on Chromium too.
Know spoonm? I helped him get a job at Google, back before it became Alphabet, he worked on Chrome's V8 engine, among other things. I knew him before he even had a commit in the Metasploit Project. Ever heard of Chris Palmer? Because I was root/etc. at iSEC Partners, which is one of the places he worked before he went over to Google/Alphabet to supposedly help with Chrome's security, among other things.
How young were you when even NIST got on board with recommending against "security through obscurity"?
Bonus: others have already found workarounds, and begun to document them publicly. However, that seems to be begging the question: why make them jump through extra hoops unnecessarily? If it can be "trivially circumvented" then it is, IMHO, better to avoid, entirely.
Learn from your elders: “Simple things should be simple, complex things should be possible.”ーAlan Kay
You attempting to change the "narrative" and discount others' to fit your perspective, is worse than mere abject ignorance of how discourse and comments function, or did you forget that RFCs built the intergalactic network of computers? It’s down right rude, dehumanizing even. You do not get to unilaterally decide that people objecting to your boneheaded idiocy are uncertain of the implications, when I know quite well how GPOs and other draconian centralized ACL management systems operate at scale. I haven’t just deployed some, I am personal friends with the authors of firewall engines used in places best not to mention by name at the moment and am versed in a panoply of configuration management languages they do not tend to even teach at postgraduate levels, but hey, at least some of them have source code readily available and are, IMHO, far more critical to network operations than a browser has ever been, or will ever be.
If you wanted to get clout and attention and make a bunch of enemies from people you have never bothered to learn about, you sure picked a hell of a way to do it, emphasis on hell. I do not envy your karma.
It's not ok to post like this to HN. I've banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
You know whats funny dang that you let misinformation about vaccination and other made up shit from old accounts go without even giving warnings. You know what lets do a little test and mirror this site for 4 weeks lets say every 5 minutes just to look what your agenda really is. see you in a month.
I have no idea who you are but i guarantee he knows more about web protocols, standards and tooling than you. He’s been doing this for 20 years and enormous amounts of the web are better because of his completely free tool.
You have no idea who this person is and yet you decide to make aspersions about his skill set and background? Sounds cool.
This is for the chromeos devices/managed chrome browsers [1]. From the bug [2] it looks like this was relevant in a school setting, where this is common. So the school hands out some chromebooks and wants to use that managed environment to prevent kids cheating on quizzes by looking at source code.
DRM and related technologies are an effort to wrest control of devices away from their owners, and give control the manufacturers and software companies. For managed devices, this is a bit more reasonable (a school should be able to manage its devices I suppose) but the technological framework here also eliminates software freedom.
It also prevents kids from using their machine to learn how to write HTML. What an incredibly short-sighted change. If kids can see the answers to their quizzes in the source code, purchase better software that doesn't allow that.
Maybe a case of shortsightedness, thinking, that they need to solve it in a javascript single page app framework and then forgot the basics about client server architecture, sending the solutions to the frontend, to check them right there. A beginner mistake.
... then don't that behaviour lead to a browser that honours the cheap stakes?
Any script that was doing a password comparison client-side was laughed at in the past -- rightly so --, but now that MS & Google see a business case it's fine? (And a password being a secret, is basically the same as the answer to a question).
Even worse: the existence of this feature (now merged) can be used to justify writing crappy code, because this is the "security" mechanism (as opposed to the proper way: not sending the answers to the client).
The existence of badly-written apps that rely on this crutch become justification for keeping this stupid feature in.
Lazy admins will use `view-source: *` rather than blocking specific sites.
So frustrating: Everyone doing bad/lazy things 'wins', and the users suffer because now these devices basically can't be used to learn or do web development.
> With Schools using Google Forms as a testing platform, students are able to use this shortcut to search through the source of the page, and determine the correct answers.
Dear StackOverflow, students keep cheating by looking at the page source and finding the multiple choice option with the id "correct-answer".
How do I add a new feature to Chromium, submit a pull request to Google, get it past their various layers of checks and policies, and mandate that all schools use this new option?
My son has now done many months of homeschooling during Sydney's lockdown via Google Classroom and this feature request is completely unsurprising as the product is a complete joke.
This is hilarious, though it would likely only show you the public version of a page, so a basic login feature would "protect" against that. Unless people are willing to give their credentials to such a website, then I suppose it might become an arms race of sorts.
i was thinking of all sorts of ways how a testing platform could prevent this workaround. but then i realized that with the same effort they could just prevent answers showing up in the source...
That gibberish produced by the framework du jour, most of the time is creapily bloated, sometimes even shockingly redundant (read: you could strip 50% to 75% without loosing any functionality).
Modern web: bloat website, than use clown cars full of dependencies to "minimize" instead of having a slim and readable source in the first place.
I have no idea what everyone’s problem is with this:
- Active Directory/Group Policy/Managed Devices have hundreds of thousands of ways to lock machines down based on the IT staff’s needs (eg disabling USB ports, disabling devtools, etc)
- You will not be affected by this in ANY way if you don’t have a managed machine
- The feature is already there, just broken
If you’re mad about this, get mad at your IT staff?
Speaking for myself, the problem is in the proposed solution to the issue that brought up this PR. It is to limit/change the way a fundamental browser feature works (view source), instead of simply fixing Google Forms website so that it does not expose answers in plain HTML code.
Extrapolate this mindset into the future and you have
removal/alternation of other browser features because someone can not code a website properly.
Browser is supposed to be the 'user agent', the 'unstoppable force', and it has been that since the dawn of the web and it should stay that way.
If this were the script to a play and it read: "Villain enters from stage left" it would more or less have precisely this style of commit message I guess.
Why do I feel like everyone will do this in the quest for "protecting ad money" and will once again have the case of that man charged with hacking for doing CTRL+u
Chrome uses a `view-source` scheme to trigger showing the source of a web page. This change allows Chrome Enterprise administrators to add `view-source:*` to their blocklist so Chrome instances governed by an enterprise policy with that enabled (like at a school or company) wouldn't be able to visit those pages and so wouldn't be able to view source in the browser.
Yes, you have to manually type "javascript:" then paste the code. Or copy everything but the leading 'j' and hand type that after pasting. Or put it in a bookmark. Also, alert() truncates the text, but makes for a nice short demo. You could append a <pre> element to the page, or similar.
> The <plaintext> HTML element renders everything following the start tag as raw text, ignoring any following HTML. There is no closing tag, since everything after it is considered raw text.
You could use the <pre> tag, but that can be "escaped" from if a </pre> tag exists on the page. Escaping the angle brackets with < and > would fix it, but <plaintext> is more elegant IMO.
Yeah, that works great. Then the kids just put that in a bookmark called "view-source". Probably also easy enough to make another bookmark that puts it back to normal.
This kind of stuff can make sense when you consider "enterprise" environments like school labs.
Notice on the bug report that the reproduction steps include setting a "DeveloperToolsDisabled" registry entry. Curl / wget wouldn't always be accessible in this kind of locked down setup (and they're probably trying to make it difficult even if it's impossible to block completely).
At that level of pay you stop caring for anything making sense?
Just saying. Apart from drug addicts doing blunt cybercrimes, I find the most creapy things are done by devs that got used to a big paycheck -- additionally, sometimes got fkd in academia before and just became a well trained cynic.
That said, I highly doubt that Google would take this feature request seriously if this were not associated with another Google property. For example, I can't imagine that if Typeform users opened a similar bug ticket that it would see any traction. To me this highlights a danger I had not considered before around the monopoly power of Google - inane requests that would benefit properties within the Google ecosystem get undue consideration despite it harming the broader ecosystem.