mrmr1993
The GDPR reads as if its authors had a different understanding. For example, the 'data minimisation' principle indicates that you should not be collecting personal data unless doing so would prevent the desired activity; serving an article, or even serving an article with adverts, can both be achieved without this data. There's also a question over whether the services are the same: a subscription appears to be materially different to one-shot access to an article, a question which is entirely overlooked in their analysis.
Beyond the weakening of 'detriment' to 'significant detriment' by reference to their pre-GDPR decisions, I also find the result unusual. The practical interpretation is that, if a user wishes to read 100 articles from 100 service providers all using this scheme, the cost of privacy is a significant detriment at €600. I am not confident that other data protection authorities will be as eager to jump to this same weakened interpretation.
There is probably a safer middle ground: giving the user the option to pay for either the article or the subscription, and allowing for either direct payment or payment by proxy through an advertising broker. In the latter context, the user's relationship and data-flow is controlled by the advertising broker, and the service provider needs no data relationship with the user. Of course, this shifts the controller liability into the advertisers -- something that they would probably prefer to avoid -- and I'm not aware of any services offering this or concrete decision on it yet.
The decision that you link also seems very much at-odds with the text of the GDPR (in both the German and English versions):
> (42) Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.
Interestingly, the decision that you linked prefers to rely on the case law of the data protection authority when interpreting the question of consent, in particular referring to rulings that predate the GDPR, despite its refinement of the concept of consent. It also focuses upon 'wesentlicher Nachteil' (significant detriment) where the original text of the GDPR prohibits just 'Nachteil' detriment. I find these choices rather suspicious, and wouldn't be comfortable with relying on them holding if challenged in other EU states.
[0]: https://www.theregister.com/2018/11/19/ico_washington_post/
let check_exp (g : Elliptic_curve_pt.t) (x : int) (y : int) = let xy = x * y in let open Elliptic_curve_pt.Num_syntax in (g ^ x) ^ y = g ^ xy
This lets you avoid making hard decisions about what can be added/multiplied/etc. at the language level -- can a list of numbers representing the coefficients of a polynomial be added? -- without jumping to the extreme of allowing anything implicitly. This also lets the typechecker catch more of your mistakes by having stricter types, and means you know exactly where to go to find out what the syntax is encoding.
() -[DatabaseReadError]-> ()
then they would be part of a function's 'contract'.
With this, consumers of your function are making an active decision about whether to handle or bubble an exception without examining your implementation, and the type of the main function tells you which errors will end up being fatal.
Disclaimer: this is not a new idea. There are proposals for OCaml to add 'algebraic effects', which have similar annotations on arrows, and I believe there have been discussions around using the syntax to track exceptions.
An invasive but effective strategy would be Javascript string/object tagging, where objects and strings derived from identifying API accesses are marked as dirty, and attempting to serialise these into requests or URLs triggers a permissions check. This would also give the option of replacing numbers and strings with junk data if the permission is denied, which seems pretty attractive.
Given the massive scope of a change like this, I don't expect it to happen, but it's nice to think of a world where any website or extension that attempts to exfiltrate data will be noticed by default.
I don't think this analogy is useful. An error in execution can be quite different in an error in judgement.
To offer an alternative example: a contractor decides to publish the source code to a company's closed-source software, so that they can use it as evidence of their work for their next job application.
> It’s argubly more like “sorry for being a moron, but I hear you. Please give us another chance”?
When these kinds of bad judgement happen, the person normally loses some decision-making power to stop it from happening again. This is in noticeable contrast to Triplebyte here: an apology as a PR exercise, and no material change to prevent it in future.
> Given the prevalence of comments like this, I wonder why any company would ever bother offering an apology or retraction.
To project my own opinion onto others: these comments are warranted because an apology has no actual value. The fact remains that Triplebytes can still do this if they wish to, and they are constrained only by what they can manage to slip past their users.
There's a stark asymmetry in the digital space, where service providers are protected by the legal language in their TOS or EULA, but the users have to trust that the service provider will not act outside their interests, and with no recourse. By contrast, in a normal contract negotiation, there will be an opportunity for both sides to ammend the contract to better serve their interests.
If Triplebytes wanted to show that they will not attempt to do this again, they could break this asymmetry and constrain themselves in their user contract, accepting all resulting liability or specifying concrete penalties if they do persue this route in the future. An apology is just a meaningless PR exercise.
To quote the GDPR at (4)(11):
> ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;
and (7)(4):
> When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.
If there's an alternative link that sits better with EU law on this, I think it might be better to switch to that instead.
> > 8. You must not use or make derivative use of Facebook icons, or use terms for Facebook features and functionality, if such use could confuse users into thinking that the reference is to Facebook features or functionality.
As written, if the reference is to Facebook features or functionality, then there can be no confusion and this clause does not apply. This would seem to be the case here.
=== wasn't introduced until ECMAScript 3 in 1999, originally there was only == when the language was created in '95.
The accepted wisdom is to prefer the newer === in the interest of clarity and consistency. With ==, it's easy to forget about one of the types it overloads (e.g. string vs. number) when making changes to existing code, and correct-looking code may behave unexpectedly for one of these types.
Maybe my understanding is wrong, but what you described doesn't seem like a unit test. I think the appropriate term for a test like this at the junction of UI, business logic and code-level triggers is 'feature test', 'integration test', or maybe even just 'test'.
[0]: https://github.com/jashkenas/coffeescript/blob/1.0.0/lib/par...
(Although it's (2^m) sequences, where m is the largest index of the n.)
The trick involved is: BitSequence.find is a naïve brute-force search, but the predicates only check n bits (for some n), and laziness ensures that at most n bits are generated.
We run into the expected problems if n is large, or there is no such n. For example,
func evenNumberOfOnesAtStart(_ s : BitSequence) {
return (s.atIndex(0) == .zero ||
(s.atIndex(1) == .one &&
evenNumberOfOnes(BitSequence { s.atIndex($0 + 2) })))
}
evenNumberOfOnesAtStart == evenNumberOfOnesAtStart
While it's nice to try smuggling in some mathematics at the end, I think a better conclusion for the article to draw is: if you ask a computer to do a brute-force search on some fixed number of bits, it will do it, even where has to compute this number of bits itself along the way.
This doesn't change that a sanctioned API invites abuse far more readily than reverse-engineering, especially when spyware is less frequently updated than Firefox itself. That there isn't a sanctioned API, and that the de facto API can and does change every version, is an advantage for Firefox against potential attackers.
If this is something you are sorely lacking, Firefox has also been straightforward to modify and compile, in my experience. You can always share a patch and enjoy these features as part of a smaller community, without compromising the userbase as a whole.
In general, blocking userspace from installing extensions and otherwise running malicious code stops FF from being exploited. Blocking all of these options blocks the OS from bad behaviour, especially where the user may expect a new computer/phone to have the default behaviour.
The vendors of phones and personal computers seem to have an interest in interfering with users' internet access; perhaps it is a good decision that Firefox does not let them.
Perhaps a more fine-grained permission model is needed for cross-application changes, but I can't think of anybody actively working on it in an OS.
It's a pain, but I can see the compromise. If it makes the average Firefox user more vulnerable, there's definitely a case to protect them, even at the expense of its more capable users.
For example, Vimium (which I've worked on in the past) needs access to every page so it can add its key bindings, most browser functionality so it can trigger it when the appropriate key is pressed, and history, tabs, etc. so that commands for opening these work correctly. This combination gives Vimium full permission to harvest data and send it to arbitrary URLs, open tabs to random spammy URLs, and generally invade the user's privacy in any way that an extension possibly could, if it so desired.
As an alternative, it would be nice to have some kind of data source marker (user-provided to extension, user-provided to webpage, webpage data, browser data, hardcoded data) and then flow permissions around these, so you can have permissions like: - open tabs/make requests/load images/etc. with user-provided URLs - open tabs/make requests/load images/etc. with URLs found in/derived from webpage URLs (in the same origin) - open tabs/make requests/load images/etc. to URLs with a hardcoded origin - include some kind of browser information in a request to one of the above types - include data a user has provided to a webpage in a request to one of the above types - include webpage data in a request to one of the above types - inject browser data into a webpage with a specific/arbitrary URL - etc.
By separating permissions for what requests extensions can make, what data can be included in requests, what webpages they can affect, and what behaviours they can trigger, it should be very easy to see what an extension is/could be doing. Sadly, this would be very technically challenging to implement, there doesn't seem to be much appetite for it, and there's a real danger of overcomplicating the permissions model so that it becomes unusable.
Just my €0.02.
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
To layer on some interpretation: * Red Shell is collecting information * which relates to "an identifiable natural person" * who "can be identified [...] by reference to [...] one or more factors specific to the physical [...] identity of that natural person" * where these factors are the information Red Shell is collecting about the software and hardware of their physical devices * and thus are "personal data", as regulated by the GDPR.
Given that their primary purpose is identifying users, they're going to have a hard time arguing that they don't fall under the GDPR's jurisdiction.
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
This sounds a lot like Object.freeze[0] in JS, at least for prototypes. I can't remember any of the major engines doing this, but it could be an interesting direction to explore.
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[0]: Article 6(1), https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
Expecting a solution that covers everything first time -- and trying to persuade people that the special cases are necessary without seeing the system in action -- is a great way to achieve slow/no progress.
The DMCA strikes a balance for the copyright holder and the host, by letting the host avoid any liability for the copyright infringement, as long as they enforce valid requests by no longer hosting the content.
The new EU law builds on this principle, giving hosts more responsibility to check whether copyright might be being infringed. I'm strongle against the idea, but I can see the logic that the host is best-placed to actively monitor all uploaded content.
A big issue I have, both with the DMCA and this new legislation, is that there's no balancing in the direction of the uploader. Aggressive solutions like your proposal do address this imbalance, but they don't do anything to address the actual concerns each side has.
If we want more reasonable copyright laws in this arena going forward, we should also be pushing for an uploader's right to appeal, as a balance against the rights of and affordances for the other two parties: * There should be an 'appeals'/'counterclaim' process for content uploaders to take responsibility for the content. Presumably, to balance against the copyright holder's needs, they should submit their name and address when they claim that their content is non-infringing. * From the host's side, the uploader following this process should remove all responsibility for that content from them, so they have no concern about liability and can re-enable access to the content. * From the copyright holder's side, they need to be able to seek recourse if they still think the content is infringing. This can be done by taking the uploader to court, using the details they have provided.
I desperately hope this new legislation fails, but I think you were spot-on about aiming for a 'fair balance', and even acheiving that would be a great improvement.
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
> GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
There's also some further discussion about how it probably gives them an unfair advantage, but that's the policy they've chosen to persue regardless.
[1]: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...