mrmr1993

mrmr1993

3 ปีที่แล้วdiscuss

I think this may have been this issue[0], which was fixed in [1]. Seems like the limit has crept up from 3 to 25 at some point in the last decade-ish, but in theory it should be undoable with 25X (or by mashing X to undo as many x commands as required). [0]: https://github.com/philc/vimium/issues/1126 [1]: https://github.com/philc/vimium/pull/1128

mrmr1993

4 ปีที่แล้วdiscuss

Indeed, that is what they decided. However, I still find the interpretation very surprising.

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.

mrmr1993

4 ปีที่แล้วdiscuss

The UK's ICO took a different stance[0] when the Washington Post tried to do this a few years back. For companies that want to do business in the UK, it probably makes sense to follow that more conservative decision.

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/

mrmr1993

5 ปีที่แล้วdiscuss

Where possible, I prefer making the syntax opt-in, and explicitly so. For example, stealing OCaml's syntax:

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.

mrmr1993

5 ปีที่แล้วdiscuss

I think that exceptions are a problem and cause this developer burden only because they are invisible. If they appeared in the type signature, for example as

() -[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.

mrmr1993

6 ปีที่แล้วdiscuss

It doesn't always make sense to plan the types ahead of time; letting the compiler do the work while you code and then creating a nice interface after is a reasonable way to work.

mrmr1993

6 ปีที่แล้วdiscuss

> Potentially dumb question here, but would it be generally possible to create a permissions system for browser extensions that can distinguish between an extension that is actually sending information based on sensitive sources like page content and browser history and an extension that only sends harmless stuff over the network like e.g. asking for updated ad block lists?

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.

mrmr1993

6 ปีที่แล้วdiscuss

> Just because someone once committed a broken build, doesn’t mean I’ll never again trust them with access.

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.

mrmr1993

6 ปีที่แล้วdiscuss

The current position is "sorry for breaking your trust, please trust us". It's hard to find it compelling.

> 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.

mrmr1993

7 ปีที่แล้วdiscuss

Not a comment on the article, but it seems like the GDPR compliance overlay for securitymagazine.com isn't GDPR compliant.

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.

mrmr1993

7 ปีที่แล้วdiscuss

> It's against Facebook's terms:

> > 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.

mrmr1993

7 ปีที่แล้วdiscuss

> The language designer saw fit to include both.

=== wasn't introduced until ECMAScript 3 in 1999, originally there was 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.

mrmr1993

7 ปีที่แล้วdiscuss

To my mind, a unit test should test a unit: something which functions independently, and which is interacted with through an abstraction layer. Type systems are good tools for clarifying and catching bugs around these abstraction layers.

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'.

mrmr1993

8 ปีที่แล้วdiscuss

I would have thought that Coffeescript's optional chaining, present at least as early as v1.0 in 2010[0], would have counted as prior art.

[0]: https://github.com/jashkenas/coffeescript/blob/1.0.0/lib/par...

mrmr1993

8 ปีที่แล้วdiscuss

Agreed.

(Although it's (2^m) sequences, where m is the largest index of the n.)

mrmr1993

8 ปีที่แล้วdiscuss

> It’s going to seem incredible, almost magical, but be assured you there are no tricks involved.

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

will never terminate. (Disclaimer: I don't write Swift.)

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.

mrmr1993

8 ปีที่แล้วdiscuss

We would and should expect that it is be possible: unless Firefox signs configuration changes per-user, server-side (violating their privacy intentions), the whole configuration code is open source, and can easily be easily used or reverse engineered to make an external editor.

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.

mrmr1993

8 ปีที่แล้วdiscuss

Yes, this leads Firefox to be fairly conservative with its permissions.

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.

mrmr1993

8 ปีที่แล้วdiscuss

I can agree in general, but, for now, disabling a firefox --install maliciousaddon.xpi and firefox --setconfig keyyoudontwant=valueyoudontlike is enough barrier to stop a majority of bad actors. None of us want users to click yes through install screens, having toolbars and spyware installed for the average user, but that has been the reality of those APIs thus far.

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.

mrmr1993

8 ปีที่แล้วdiscuss

This seems to be by design: when these things are available, spyware -- especially on Windows -- will be quick to make malicious changes in all these if they can.

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.

Submissions

Generic programs can't reliably use/manipulate documents via the DOM

comments