The goal of this system is too make faking license plates using a bit of black tape hard/impossible. So I have some trouble getting the point of Erik Spiekermann's comment.
Well, that's one thing where he's right. Agree to disagree, I guess. ;-)
I had two online interactions with him that formed my opinion of him.
When I started being interested in typefaces, but not really able to discern one from another, I wrote him an email asking for the title of one or two books where I could see his FF Meta used for the body text. He's a busy man, so I only half expected him to reply, but I certainly didn't expect his condescending abusive email that he wouldn't help a lazy student with his homework. Great way to inspire people interested in your work!
The other time was in a type aficionado web forum where I mentioned that I had bought the Adobe Type Classics collection CD for much less than retail price (second hand). He accused me of piracy, again in pretty abusive manner.
Taken together with his holier-than-thou attitude, riling against "spec work" (https://www.nospec.com/), but then asking designers for spec work, because "it's for the UN" (and he was on the jury).
Or with his blatant lie in a Fontshop brochure I have on my shelf, claiming that there is virtually no intellectual property protection for fonts in Germany, and how it would have been impossibly expensive to register for type protection… but somehow a lot of hobbyists and small fish managed to do it.
Erik Spiekermann is a very important designer who did lots and lots of outstanding work, but I've found him to be a deeply unpleasant person.
claiming that there is virtually no intellectual property protection for fonts in Germany, and how it would have been impossibly expensive to register for type protection… but somehow a lot of hobbyists and small fish managed to do it.
What kind of protection is there? I've read that claim before.
Back then there was the "Schriftzeichengesetz" which offered protection roughly similar to a design patent called "Geschmacksmuster" (but with its own registry). It has since been subsumed by the "Designgesetz".
Typeface protection has always been weaker in Germany than copyright protection, but it existed and exists.
As an aside: Fontshop used to claim at every opportunity that they had achieved a verdict in a lawsuit that gave fonts full copyright protection. That only worked because nobody on the forums and the web had ever seen the verdict. It wasn't secret, just behind a paywall of a legal database. A friend who's a lawyer retrieved it for me and I was much amused: The verdict said precisely the opposite!
Because all the letters already look weird. The fact that the style of B and D are very different doesn't matter because the reader doesn't know what the other letter ought to look like.
Yes, if you compared them side by side with an official and the fake it would be easy to see. But when just reading, all the letters already look weird.
I do not use catch-all addresses, but use a version of [domain]@mydomain.com buy adding new email addresses (aliases) in an automated way. I "remember" the used email addresses in two ways: 1) my mail server configuration contains a list of all aliases created in the past, 2) my password manager saves logins on top of that. The nice side effect is, that you keep track of all the sites you have ever created logins at.
That depends on your definition of "solution". The scheme protects you (to a certain degree) from automated creation of inter-site profiles. The reason is, only very few people employ (a variant of) this strategy, so trying to "deanonymize" is costly and usually not worth it economically.
"It is illegal to shoot down an aircraft in such a situation in Germany."
No! The Verfassungsgerichtshof ("supreme court") ruling, makes it illegal for the government to give an order to shoot down the airplane (i.e. to make a decision on actively killing some people to save others). Most lawyers, however, agree that the pilot of the nearby fighter jet would face none or minor legal consequences if deciding to shoot down such a rouge airplane. IANAL which is why I refer for details to the following German blog (by a well renowned judge): http://www.zeit.de/gesellschaft/zeitgeschehen/2016-10/ard-fe...
This "vulnerability" is harder to exploit in Chrome because extensions in Chrome (unlike in Firefox) have their own private DOM, and settings page have isolated DOM too. If an extension uses Angular only with its private DOM there is no vulnerability.
The vulnerability can be exploited only if an extension is running Angular on an untrusted page which is less likely in Chrome (but of course one should not underestimate the level of incompetency of a modern frontend developer).
UPD: @bzbarsky noted that Firefox is using the same security model as Chrome so both browser extensions can be vulnerable. To exploit a vulnerability, several conditions should be met: 1) extension should inject Angular into a web page 2) attacker should be able to find a way to get from content script context into extension's background page context.
Note that the github discussion is about Firefox webextensions, which have the same security model as Chrome extensions (and in fact aim to be API-compatible with Chrome extensions).
Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.
Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.
Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.
It's completely expected to both inject scripts into a pages DOM, and also to set up a communication channel back from the page content script to the central extension "process". It's not a rare corner case. An ad-blocking content script might want to report user-selected extra filter requests back to the main adblocker context; or it may simply want to count the number of blocked requests; or a password manager may want the ability to save new passwords; etc.
Typically, you'd expect the central extension to trust messages it receives from its own content scripts, so even though there is a separation between the extension and the pages it's on, the separation is by no means a leak-proof security measure; it cannot be. You rely on each and every such extension being carefully written and having no security relevant bugs.
If you think about it, it should be clear that it's practically infeasible to fix this hole. Extensions authors simply need to avoid such bugs. If angular1 somehow makes it easy for them to make mistakes when used by an extension, that's a problem.
Don't update your post to include replies to your own comment. Hackernews already allows us to see the replies. If you have a response to a comment, reply to that comment.
Chrome extensions are less of an issue though, no? IIRC Firefox addons are significantly more powerful than Chrome extensions, so locking things down tighter makes sense anyway, a low threat on Chrome could be much higher on FF.
If a Chrome extension has permissions to an origin, then it can freely make cross-domain requests to it from any page. So if you have an extension using Angular 1.x on every page and then browse to a malicious page, then the page could contain text in the DOM that Angular evals from within the extension. That code could then make an AJAX request to any origin with your cookies, and make requests for your bank info or emails and do things like steal data or change your passwords.
The discussion here is about Firefox webextensions, which use the Chrome extension API and are not supposed to be more powerful than Chrome extensions.
It's possible to write Firefox extensions in JavaScript that are a lot more powerful than Chrome extensions (or webextensions, which are the Firefox equivalent of Chrome extensions) are. That capability is slowly being phased out, though.
No, historical XPI addons are in JS (and XML and CSS). While they can bundle native code most don't, but they run in at the same privilege level as the browser itself (consider Firebug, which was and still is an addon).
Every browsers addon runtime is different. Firefox is working on standardizing things with it's Web Extensions API (modeled after Chromium's API). But potentially, yes.
They still see the same content in the DOM. The extension just has a separate javascript-wrapper around the DOM. This means that an extension will not be affected if a webpage monkey-patches a DOM method to do something else. But if a webpage places some specific text content inside an HTML element, then the extension will see that same text content! (And Angular running in the extension can still choose to recognize that content as a template and eval it.)
I am really worried about the security implications for addons like bitwarden, if mozilla is right about this. I hope that competent people will take a close look.
