Domain: googlesource.com
Stories and comments across the archive that link to googlesource.com.
Comments · 89
-
Re:Yeah, duh.
They'll probably end up contributing back to the chromium project once they've got the hang of it too.
It's already happening.. You're right, they need a standards-compliant browser because they don't own the platform anymore and it's pretty clear they don't want to, Microsoft want their software and services to run everywhere which means compatibility with web standards is critical. There's no point building your own standards-compliant HTML engine when you can just use and contribute to a collaborative one that way you know the software and services you build for your browser will run on others too.
-
Re:Can it be disabled? and WTF??
I have the same concern, particularly with regards my MS Natural Ergonomic 4000 keyboard: I use the Mute key all the time for exactly what it does natively on Windows 7 (and did on XP too): mutes all audio on the system. If this functionality is implemented in the browser, what exactly happens? Does it mute the tab (something Chrome 71 already made a mess of)? Does it mute audio in the entire browser? And if it does either of those, is there a way to disable it (say, through chrome://flags)? Because if not, that's a huge problem and major oversight.
As I wrote the above paragraph, I noticed that a reply came in elsewhere indicating that apparently the only keys it'll look at are play/pause/seek and track-oriented keys. What if people are already using those with their media player of choice? Furthermore, the document is marked Editor's Draft as of 2019/02/09, a.k.a. working draft, a.k.a. subject-to-change-at-any-moment. And even if it wasn't, we all know this is exactly how it begins: today it supports only those functions, but 6 months from now it's extended to support Mute and Volume Up/Down, which will provoke someone to consider adding Home, Favourites, Mute, Calculator, etc. via something similar -- all keys that have historically (we're talking 15+ years, folks) been dedicated to the UX aspect of the OS only, UNLESS you specifically went out of your way to configure them on a per-program basis and within that program (ex: Winamp), with some exceptions (read: Internet Explorer actually does use some of these keys itself when running) -- then it'll get extended to Logitech G15 LCD so the browser can print stupid crap on the LCD, followed by RGB LED tweaking, then some kind of fan RPM mod, blah blah blah. This is what's called creeping featurism and it is not a new phenomenon, but its prevalence has greatly amplified in the past 10 or so years.
I have no problem with the browser implementing, say, the appropriate API functions so that an extension/add-on could be used to set said keys up in the browser to perform media-related tasks (not a bad idea really, sort of akin to what the Streamdeck does alongside OBS Studio) -- the user has to install the Chrome extension by choice, thus the concern is alleviated for everyone as a default (read: majority) and bugs/quirks only affect those who effectively opted in through use of an extension.
In all seriousness, the past few major Chrome releases -- 70, 71, and 72 -- all brought with them more UX-related problems than improvements, IMO. For example, in 72 for whatever reason they decided to get rid of the incredibly useful details at chrome://net-internals/#proxy that would tell you what the active/effective settings were -- extremely useful for knowing if your PAC file was loaded or not, if a proxy was in use at all (and if so, if it was SOCKS or DIRECT or what), etc.. And just today I found they removed the chrome://net-internals/#events viewer entirely and replaced it with a dump-crap-to-a-file model that requires you to install Python and a completely separate external utility to decode it. What was wrong with doing this natively? Why not offer both?
I say all of this as a person who is an extremely strong advocate of KISS principle. I just don't see why removing useful information and capabilities of this sort is considered positive progress. Likewise, I don't see how adding media keys support to a browser is progress either. I think it creates more problems and annoyances than it solves. Obligatory Jurassic Park reference.
-
Re:Que my mom wondering why the internets broke
Perhaps you should read the link provided in the summary.
Everything I said is based on things the actual owner of the feature said.
-
Re:Gamers?
Maybe you just don't know what you are doing, and a competent person could run the same "big data sets you generate" on a decade old single machine.
Maybe you just don't know what he is doing, and in your ignorance you can't believe that *anyone* would need so much power for work, because *you* have never needed so much power for anything.
For example, here's an alternative workload that would benefit from having lots of resources: Compiling Chromium requires at least 8GB of RAM. More than 16GB is highly recommended.
-
Re:Does that mean I can get chromefree android pho
Well, that's the rub isn't it, because "pure Android" can mean "Exactly what Google would give you" (more probably) or "AOSP" (fairly unlikely.) The Mail app is part of AOSP. Google's "Android" however isn't pure AOSP, or even pure AOSP + the Google suite, it's often confused with the latter, but it's been drifting away from AOSP for many years now.
Here's email, as you can see it's in there right up to AOSP 9.1 as of the current state of the universe.
I believe most phone makers include it. Sounds like Nokia doesn't, possibly because it's advertising the "Pure Android" horseshit.
-
Re:Just What We Need...
You can view the source for libaom, which is the reference encoder and decoder. And FFmpeg 4.0 (which incorporates libaom) has been released.
-
supported models
Chromebooks using Intel’s BayTrail do not include VT-x. Yes, normally this CPU includes VMX, but the variant in Chromebooks does not. Thus, unfortunately, they'll never be supported.
Currently running GalliumOS on a Gnawty BayTrail. It does include VT-x. I can enable and use the features in virtualbox. I'm curious who wrote that bit of the page listing currently supported chromebook models.
-
Re:2019: the year of the linux desktop
Maybe Chrome OS but not Linux. Chrome OS (also Android) kernel is really irrelevant, especially considering Google's plans of ditching it in favor of Fuchsia / Zircon.
-
Another good reason to ditch it
Sadly, this probably means more shit spaghetti code than ever before. Another good reason for Google to ditch this in favor of Fuchsia / Zircon.
-
Re:Expensive paperweight.
Many flavours of Linux run on it.
Here's the latest Ubuntu https://www.servethehome.com/g...Not only is the bootloader unlockable, it's also opensource.
You're not restricted in any way with what you can do with the hardware. You just won't get any more automatic Chrome OS updates.
coreboot source: https://chromium.googlesource....
uboot source: https://chromium.googlesource....Name another laptop manufacturer with entirely open source boot code.
-
Re:Expensive paperweight.
Many flavours of Linux run on it.
Here's the latest Ubuntu https://www.servethehome.com/g...Not only is the bootloader unlockable, it's also opensource.
You're not restricted in any way with what you can do with the hardware. You just won't get any more automatic Chrome OS updates.
coreboot source: https://chromium.googlesource....
uboot source: https://chromium.googlesource....Name another laptop manufacturer with entirely open source boot code.
-
Re: A tiny fraction of the consumer market?
Presumably jd was referencing Google's experimental Fuscia OS, which may or may not ever actually replace Android (but they hope it does). Fuscia has a non-Linux (but still open source) kernel called Zircon: https://fuchsia.googlesource.c...
-
Real facts: Written in C, Former BeOS developers.
It's written in C: https://fuchsia.googlesource.c... Google hired a bunch of former BeOS developers to work on it. (It's something new though, not related to BeOS)
-
Re:Silly
lol. Vivaldi is based on chromium, which has Opera (Chinese) and Yandex (Russian) devs contributions in the code. In fact, if you look at the AUTHORS file in master https://chromium.googlesource.com/chromium/src.git/+/master/AUTHORS your likely to spy lots of Chinese, Korean, Indian, Arabic and other non-Norwegian sounding names listed as well. It even lists a Mozilla corp addy.
-
Re:So....F U Proxies and Internal CAs.
If they did care about the end user's security, they wouldn't make stupid changes like not trusting end-user / admin installed CA certs by default.
Chrome opts in through its network security config file, and Firefox has its own TLS engine. So this affects mostly native apps that use Android's TLS engine.
Since when does removing / forbidding the user's input on trust somehow boost their security?!?!?
Malware has in the past added certificates as a means of intercepting apps' traffic. So have governments.
-
Re:Linux on the desktop
Linux won in the mobile space. Linux runs on over 2 Billion monthly active devices.
Just because the the Linux kernel is used in Android doesn't mean that it's the Linux kernel's merit. It's like to say that 2 Billion cars using a particular engine means that the engine is successful while the original car, the engine is taken from, is lousy. Android is very much different from GNU/Linux, the Linux kernel is buried so deep that most of the developers don't know about it, and it can be replaced with something like this.
-
Code check: How does this work?
I know nothing about ChromeOS code. So clearly I shouldn't be surprised that I'm struggling to make since of this commit. But the size of this change seems small enough that I might expect to at least be able to make the two ends meet (the part storing and managing the new policy key and the part that reads that key and acts upon it).
https://chromium-review.google...
But I can't. All I see are things related to storing and managing the key. I don't understand how this newly created "thing" has any effect on the operation of the OS. Where is that policy checked? I assume there's some application layer outside of this structure that's acting upon the value of this new key, yes? Where could one find that?
-
Re:I love the way Google pretend to be...
In the past, chrome actually used setuid to construct a secure chroot sandbox environment. However, today setuid no longer used, as they are always developing more modern sandboxing techniques with the state of the art.
Also, to your comment, if you think checking for root privileges is as simple as checking what user a process is running as, you are sorely mistaken at the complexity involved under the hood, Forgetting for a second the fact that programs like chrome actually consist of tens of processes each running with different privilege levels, processes can gain elevated privileges without actually having a uid or effective-uid of root. For example, capabilities, open file descriptors or other handles passed in. It's very difficult to display setcap capabilities granted to a given process.
-
Re:I love the way Google pretend to be...
In the past, chrome actually used setuid to construct a secure chroot sandbox environment. However, today setuid no longer used, as they are always developing more modern sandboxing techniques with the state of the art.
Also, to your comment, if you think checking for root privileges is as simple as checking what user a process is running as, you are sorely mistaken at the complexity involved under the hood, Forgetting for a second the fact that programs like chrome actually consist of tens of processes each running with different privilege levels, processes can gain elevated privileges without actually having a uid or effective-uid of root. For example, capabilities, open file descriptors or other handles passed in. It's very difficult to display setcap capabilities granted to a given process.
-
Re:Why Chrome and not Chromium?
That blob has been fixed both upstream and in Fedora chromium since 2016-09-07: enable_hotwording=false
-
Re:Linux is communism
Don't worry, Google already started.
-
Re:Blame Chrome for Windows defects ..
Chrome wouldn't need sandboxing if the underlying Operating System did its job. That is isolate one processes memory from the other. Something the WinTEL platform seem unable to do despite numerous iterations of the x86 processor.
Except you still have all the same kinds of flaws in other operating systems, too, which is why Chrome is also sandboxed on other platforms, e.g. Linux. It's not just Windows. The techniques vary, but no mainstream OS is designed for security first. That would impinge upon performance. Microsoft literally decided to go the other direction in NT4, specifically in the name of graphics performance.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:Open BSD Linux ... WTF
Google seems to have been asleep
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...
https://android-review.googles...All of those patches were prepared some time ago, distributed to device makers, and landed in AOSP when the embargo lifted.
-
Re:So...
The complete absense of any examples of Rust code that is better than the equivalent C code would be
You mean except for Stylo or how Tor is moving to Rust?
The lack of traction of Rust outside of those that back it
You mean except for when companies like Google use Rust and Dropbox use Rust?
You're welcome.
I think you're a little confused about what evidence is.
-
Re:Can malware use this to prevent patching?
One potential flaw in this mechanism: I think a malware image can prevent rolling back to a known-good image by setting the rollback indexes to ridiculously high value, say 2147483647 (2**31-1).
This diagram shows how the workflow is supposed to proceed. If Mallory gets her verification key onto your device (either by social engineering or another flaw), then her custom malware image can be booted by the device in locked mode. The user will get a warning about this being a custom OS (good!), but then the rollback index values in Mallory's image are written to the stored rollback index values (bad!). If I then attempt to go back to Oreo 8.0, it won't let me.
A better mechanism would be to have a set of stored rollback index values per verification key, not a global set per device. Then I could roll back to the stock factory image from a Mallory's malware image.
Good info, thanks!
I'm being humorous, but truthful. This feels like "Ad non-view punishment". If a ad-blocker is installed, you can get those nice "ads pay for our site; you can't view unless you see the ads" on a desktop OS. This seems like a "if you have a custom installed OS, you get to wait 10 seconds as a time-out".
I know it's not the same, but it just seems to match. A user who installs a custom ROM on an unlocked phone should have to see the warning, at most, 1 time. To see it every time is a form of coercing the user into going back to the main or losing ADHD valuable time if user doesn't wanna.
-
This does not prevent custom ROMs!
As is made clear further down, the rollback index does not prevent custom ROMs, old versions, or anything else from being installed IF the device's bootloader is unlocked - as has always been the case when installing custom ROMs.
All it does is prevent locked devices from being downgraded (to a presumably less-secure version that could be exploited). Locked devices are locked for security, so this is entirely expected behaviour. If you would rather take control and manage your own security, you can unlock the bootloader at any time (at least on Google's own devices; YMMV with other vendors). Then you can install anything you want.
-
Can malware use this to prevent patching?
One potential flaw in this mechanism: I think a malware image can prevent rolling back to a known-good image by setting the rollback indexes to ridiculously high value, say 2147483647 (2**31-1).
This diagram shows how the workflow is supposed to proceed. If Mallory gets her verification key onto your device (either by social engineering or another flaw), then her custom malware image can be booted by the device in locked mode. The user will get a warning about this being a custom OS (good!), but then the rollback index values in Mallory's image are written to the stored rollback index values (bad!). If I then attempt to go back to Oreo 8.0, it won't let me.
A better mechanism would be to have a set of stored rollback index values per verification key, not a global set per device. Then I could roll back to the stock factory image from a Mallory's malware image.
-
Re:Offline voice recognition
You could seriously look for yourself.
-
Re:One line st a time...
BTDT, more times than I could possibly remember.
OTOH, I'm proud to say that there have been a number of times in the last few years (of a 30 year career) that I've looked at something and thought "Damn, this is really clean and elegant, and that bit is incredibly clever in its simplicity"... and then realized that was my code. And I've had co-workers compliment me on the simplicity and clarity of my code. That is an awesome feeling.
On the gripping hand, I would *not* say that of the project I've been working on for the last three years. It started out fairly decent (not great, but good, IMO), but has gotten very crufty and at this point is pretty hard to follow. It really needs a major refactor. If I only had a quarter to spend on cleanup... but new requirements come in too fast.
Writing working code is easy. Writing readable code is much, much harder. Worth the effort, though.
Here's a tip: Once you have developed enough as a programmer to have a good sense of what's clear enough to be readable to another programmer (i.e. yourself in three months) and what isn't, enough that you know when you need to add explanatory comments to clarify how bits of the code do their job, then you should start treating inline comments as a code smell. If the code can't stand on its own, refactor until it can. Often this is as simple as picking some better variable or function names, or pulling apart a calculation so you can assign parts of it to well-named variables, or factoring a block of code out into a separate method so you can give it a descriptive name. Other times, after doing all of that it's still not good and you need to do a deeper refactor. But don't be satisfied until the code can stand alone, comment-free, and still be clear, concise and straightforward. There are some cases in which this is impossible, but I think they are rare.
-
Re:Epically Lame....
Oh I know what a microkernel is alright.
If you're referring to it as a buzzword when the sourcecode for this project is available and demonstrably disproves your assertion then no, you don't. You might think you do, but clearly you do not.
Either they're pathetically slow or they aren't really a microkernel.
The fact that you are saying it's one of the two means you haven't even looked at it despite the source being available:
http://fuchsia.googlesource.com/magenta/+/master/kernel/
So what specifically do you take issue with?
Like NT, which was supposed to be a microkernel, but they put the GDI in kernel space on NT 4.0.
So what's that got to do with anything?
-
Re:What's the init system? Not systemd?
It uses a custom in-house developed init just like Android does. Since Android only uses the Linux kernel this have nothing what so ever to do with systemd. https://fuchsia.googlesource.c...
-
Re:Well rust must be reallllly good...
(Because everyone decided to repeat the same mistake.)
Google is still repeating it, sorta. They are writing Magenta in a mix of C++ and C, when they could have used L4 instead of LK to eliminate the C bits, or they could have used Rust for the kernel and solved this mistake once and for all.
-
Re:Actually what the guy wrote was
-
Actual repo link
Since it's not in the summary here is the repo link.
-
Re:Oh please
They have a lot of servers and it's more cost effective to come up with their own solution for management, monitoring, maintanance, etc?
You can't exactly wait for a kernel patch or a fix for a breaking change if you're working with over a million servers.
Also to get bang for your buck You need your programs with a lot of patches to make them fit for your specific requirements and stripped of any code that goes unused or is deemed a security risk which means a whole lot of packages that are compiled in-house. hell even individual packages that are forked are posing problems for them (see https://boringssl.googlesource...)
All of this means you have to use your own package repositories which means even if they use redhat as a base it's not redhat anymore.
Did I mention ridiculous pricing? -
Re:No problem
Android 4.4 and 5.1 got security updates a month ago: https://android.googlesource.c...
Granted, OEMs and carriers are probably blocking those from getting to 99% of peoples' phones, but that's not Google's fault. -
License
https://fuchsia.googlesource.c...
the consequences that we've seen from google's failure to use a self-protecting license includes:
* companies incorporating GPL'd code into Android (particularly video players) and not releasing the source
* performing DRM or other lock-downs ("Tivoisation") and in the case of qualcomm ending up with 900 million devices that are basically landfill
* causing confusion in the minds of corporations over the fact that the linux KERNEL (and u-boot) is still GPL'ddo i need to continue the list? i don't but i believe a reference to mjg59's list is appropriate:
http://www.codon.org.uk/~mjg59...google seems unable to comprehend the severe detrimental consequences of its actions, and the effects that their decisions have on the rest of the software libre community. i appreciate that they're an advertising company so are required to maximise the effective distribution of devices so that they can thus maximise the number of devices through which they can advertise, but pissing all over the free software community that MADE IT POSSIBLE FOR THEM TO HAVE A BUSINESS AT ALL is completely unethical, not to mention the detrimental consequences and money that users have to throw away when devices turn out to have major security flaws that the designers CAN'T FIX IN THE FIELD. http://arstechnica.com/securit...
-
Re:Microsoft: convenience over security
Guess a PPAPI plugin that's being built as part of the Chrome build process and shipped with it by default is somehow "native PDF rendering without a plugin": https://chromium.googlesource....
-
Re:Many things are worse than bad comment punctuat
The most important comments are the ones that specify "why not".
Like complex mathematical derivations, that's another case where comments may be essential. My recommendation isn't to eschew all comments, it's to avoid duplicating in comments what can be just as clearly expressed in code... and to work hard to try to express the information in code rather than in comments. Doing so will make your code cleaner and much more maintainable.
My code isn't comment-free, but it is comment-light, and I think it has gotten much better since I adopted this policy (which, BTW, I should be clear that I didn't originate. I got the idea from one of Robert Martin's books on code craftsmanship.).
Some examples might help. Consider this case, where I had to write a comment to explain why not to do something. Or (to pick a section from the same file), look at this case which is interesting because the comment is very large -- as large as the code that it documents -- and because I think that without the comment it's really not clear why the code is doing what it's doing. I have toyed with various ways of refactoring that code to eliminate the need for the comment, but short of using something like a strategy pattern I can't find one that does the job. And even a strategy-based implementation would still require me to both ensure that the strategies are applied in the correct *order*, and to document what that order is.
Doh! I just noticed that that long comment has bit-rotted a little. It was originally written when the code only handled options 1, 3 and 6, so the concluding paragraph doesn't explain about options 2, 4 or 5, or why they're tested in the order they are. That example is an even better one than I thought, since it demonstrates both the need for and risks of explanatory comments.
That SoftKeymasterContext class, however, is an exception to the rule. It exists specifically to address a bunch of unusual corner cases and so it's not surprising that it requires much more explanation than 99% of code should. Here's a better example (chosen more or less at random from the same project) of what comment-free code should look like.
-
Re:Many things are worse than bad comment punctuat
The most important comments are the ones that specify "why not".
Like complex mathematical derivations, that's another case where comments may be essential. My recommendation isn't to eschew all comments, it's to avoid duplicating in comments what can be just as clearly expressed in code... and to work hard to try to express the information in code rather than in comments. Doing so will make your code cleaner and much more maintainable.
My code isn't comment-free, but it is comment-light, and I think it has gotten much better since I adopted this policy (which, BTW, I should be clear that I didn't originate. I got the idea from one of Robert Martin's books on code craftsmanship.).
Some examples might help. Consider this case, where I had to write a comment to explain why not to do something. Or (to pick a section from the same file), look at this case which is interesting because the comment is very large -- as large as the code that it documents -- and because I think that without the comment it's really not clear why the code is doing what it's doing. I have toyed with various ways of refactoring that code to eliminate the need for the comment, but short of using something like a strategy pattern I can't find one that does the job. And even a strategy-based implementation would still require me to both ensure that the strategies are applied in the correct *order*, and to document what that order is.
Doh! I just noticed that that long comment has bit-rotted a little. It was originally written when the code only handled options 1, 3 and 6, so the concluding paragraph doesn't explain about options 2, 4 or 5, or why they're tested in the order they are. That example is an even better one than I thought, since it demonstrates both the need for and risks of explanatory comments.
That SoftKeymasterContext class, however, is an exception to the rule. It exists specifically to address a bunch of unusual corner cases and so it's not surprising that it requires much more explanation than 99% of code should. Here's a better example (chosen more or less at random from the same project) of what comment-free code should look like.
-
Re:Many things are worse than bad comment punctuat
The most important comments are the ones that specify "why not".
Like complex mathematical derivations, that's another case where comments may be essential. My recommendation isn't to eschew all comments, it's to avoid duplicating in comments what can be just as clearly expressed in code... and to work hard to try to express the information in code rather than in comments. Doing so will make your code cleaner and much more maintainable.
My code isn't comment-free, but it is comment-light, and I think it has gotten much better since I adopted this policy (which, BTW, I should be clear that I didn't originate. I got the idea from one of Robert Martin's books on code craftsmanship.).
Some examples might help. Consider this case, where I had to write a comment to explain why not to do something. Or (to pick a section from the same file), look at this case which is interesting because the comment is very large -- as large as the code that it documents -- and because I think that without the comment it's really not clear why the code is doing what it's doing. I have toyed with various ways of refactoring that code to eliminate the need for the comment, but short of using something like a strategy pattern I can't find one that does the job. And even a strategy-based implementation would still require me to both ensure that the strategies are applied in the correct *order*, and to document what that order is.
Doh! I just noticed that that long comment has bit-rotted a little. It was originally written when the code only handled options 1, 3 and 6, so the concluding paragraph doesn't explain about options 2, 4 or 5, or why they're tested in the order they are. That example is an even better one than I thought, since it demonstrates both the need for and risks of explanatory comments.
That SoftKeymasterContext class, however, is an exception to the rule. It exists specifically to address a bunch of unusual corner cases and so it's not surprising that it requires much more explanation than 99% of code should. Here's a better example (chosen more or less at random from the same project) of what comment-free code should look like.
-
OpenSSL?
-
Re:Get rid of the frigging embedded PDF viewer!Chrome and Firefox render PDFs in different ways.
Firefox implements PDF.js. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.
Chrome uses plugin called PDFium. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.
Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.