adambrenecki
Joined 13 years ago
Joined 13 years ago
> The characters that are used in Open Location Codes were chosen by computing all possible 20 character combinations from 0-9A-Z and scoring them on how well they spell 10,000 words from over 30 languages. This was to avoid, as far as possible, Open Location Codes being generated that included recognisable words. The selected 20 character set is made up of "23456789CFGHJMPQRVWX".
https://github.com/google/open-location-code/blob/master/doc...
This is blatant clickbait.
Right, but if the social network website can modify the HTML that the Keybase extension is injecting, then surely it can also modify the iframe's URL to an attacker-controlled one? Or, for that matter, replace the event handler on the "Keybase Chat" button itself before it even gets clicked?
I'm not an extension developer, so there might be APIs available to extensions or restrictions on webpage JS that I'm not aware of, but I suspect the only secure way to do this (if you don't trust the page you're embedding in) might be to have the extension communicate with the native Keybase app, which then opens a chat window with the appropriate user, similar to how the 1Password browser extension works.
Here's a fun little example of this: If one of your parents was a British citizen, then you're a British citizen 'by descent'—not merely eligible to become a British citizen after you fill out a form, you're an automatic British citizen by default unless you renounce your citizenship. (This has caught out at least one member of the Australian parliament, where dual citizens aren't allowed to serve.) This means that you can have someone who's an EU citizen (for the time being, at least), who doesn't live in the EU, has never set foot on EU soil, and maybe isn't even aware that they're an EU citizen themselves.
Lots of people are responding to the DPO side of this sentence, saying that it's not as onerous as the author of this article is making it sound, but as someone who's also not based in the EU it's the "EU Representative" part that I'm more worried about myself.
Article 27 says:
> (1) Where Article 3(2) applies, the controller or the processor shall designate in writing a representative in the Union.
Article 3(2) is the bit that says the GDPR applies to processing outside the EU of EU citizens' data etc.
> (2) The obligation laid down in paragraph 1 of this Article shall not apply to: > a) processing which is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing; or > b) a public authority or body.
It's clear here that not everyone outside the EU needs to have an EU representative, but 2a is wordy and confusing enough that it's real hard for a non-EU non-lawyer to figure out with certainty whether or not they need one. The ambiguous combination of 'and's and 'or's don't help, but 'unlikely to result in a risk to the rights and freedoms of natural persons' sounds like something that's ambiguous enough on its own that you might need an EU lawyer to actually interpret it.
> More concretely, our goal is to ship a high-performance standalone editor component suitable for use in any web application, something we could eventually use on GitHub.com. This standalone editor will give us a chance to test a limited set of critical features in production scenarios without building out an entire desktop-based editor. We plan to develop this new editor in the context of a prototype Electron application, but we'll offer the standalone component as a separate build artifact from the main app.
I don't know if every DV CA does this, but I got a couple of StartSSL's free certs a while back (before LE was around, and before the WoSign acquisition and subsequent debacle), and I recall the documentation saying "because this is a DV cert, we're just going to ignore all the metadata in your CSR and generate a certificate with those fields blank", or something along those lines.
Oh.
> I’ve done a ton of open source work over the course of my career. Companies have used that work to generate income for themselves. Inevitably, I’ve ended up supporting that software on those companies’ behalf for free and that is not sustainable long term.
This is totally 100% true and understandable. Unfortunately, a lot of devs are going to go "hmm, I could battle to convince someone that can approve purchases that it's worth forking out $2k/year for this, or I could just use Celery".
That said, it might still be a good idea to blacklist these anyway, as you might end up with someone registering the username 'reset-password' (which isn't on this list yet) trying to phish your users, or 'support' trying to masquerade as your support, depending on what your app does.
On a note that's tangentially related to this but more directly related to the top-level post, ProseMirror has a demo which involves a markdown-to-WYSIWYG editor where both sides are editable: http://prosemirror.net/examples/markdown/