But the model will eventually be updated to detect and process the new cloaking images. So, to stay ahead, you decide to create a model that automatically generates different cloaking images, and... The whole system is now just a GAN : https://en.wikipedia.org/wiki/Generative_adversarial_network
I think there's a (hopefully strongly privacy preserving) combinatorial explosion here though. If current models can be trained to accurately-enough recognise me with, say, 100 training images - this tool might produce unique enough perturbations to require 100 images for each of the possible perturbations, potentially requiring you to train your new model using tens of thousands or millions of cloaked versions of the 100 images for each of the targets in your training set.
(If I were these researchers I'd totally be reaching out to AWS/Azure/GCE for additional research funding... <smirk>)
Not necessarily, because the changes are destructive. They can't restore what was there before, and they can't necessarily infer which image was cloaked and which was not.
The FAQ there addresses that, suggesting you can "dilute down" the ratio of normal-to-cloaked images in the public data sets the model creators train on, and hence reduce their future accuracy.
(So now you just need to somehow get as many cloaked photos of yourself uploaded and tagged to FB as they've collected in the last decade or so...)
If you use a new cloaking image for each picture you upload to social then they will all be embedded in a different location for a given feature extractor and an adversary wouldn’t be able to reverse search for linked pictures—that’s at least my understanding of how the method would need to be used. But if you keep using the same cloaking image, your adversary could definitely learn that process and effectively undo it.
Thanks for this—easier to digest than other posts I’ve seen. The ability to restrict interfaces to specific types is pretty cool (unique?) but otherwise seems like generics as usual, but with a distinct Go flavor. Looking forward to using this and cleaning up some boilerplate!
OP specifically said the constraining mechanism was unique, hence why GP (and myself) are curious about what makes it more interesting/powerful than what exists in other languages like C#.
I do wish people would resist the reflex to overtly digress onto their own favorite programming language in any given programming HN thread. I'm not talking about insightfully comparing two languages; I'm talking about going completely off-topic because you want to talk about your own favorite language.
If this is in reference to my bringing up of C# - I did so in order to talk about whether or not Go has generic constraints which are unique (which would be awesome!). I used C# as an example of a language that has constraints that are the same as/as powerful as those in this Go proposal so as not to be making an unsubstantiated claim.
Why would you prefer the risks of editing versus the risks of preimplantation screening? Editing would be strictly riskier unless there’s really no alternative (unlikely but possible)
Preimplantation screening isn't an option for me or any other of my family members who are long past implantation. I'm not saying I'd hop on stage 1 clinical trials of a potential editing cure, and we'd have to see what the data on risk looked like to compare it with the risk from cancer without editing.
This opinion piece is citing a lot of evidence and blatantly misinterpreting it. At a minimum it defers to the IHME models as the reference standard but they’ve performed terribly; similarly it cites Ioannidis from Stanford who has consistently failed to predict the actual consequences of the disease and is being ridiculed by the scientific community.
Soon to be 100,000 dead in the US with lockdowns; how could it have been a mistake? The only mistake was not doing it earlier.
Hmm I’d say all the book clubs I belong to are social first, book second; one club spends the majority of each meeting roasting the people who haven’t read the book, another good portion debating our selection procedures, and a minimal amount of time on the book itself. Different flavors for different people!
If that's the case, why have a "book" club at all, rather than make a social gathering? Let me be clear in that I also attend social events, but they're called social events on the face of it. If I'm attending a book club, I expect to talk about books.
I said this in another comment, hope it clarifies my understanding:
Sure, I get smalltalk, and I now understand the dichotomy of book club types. Some people are expecting book clubs to be casual and others hardcore. Our definitions are not the same so our conclusions as to what book clubs should be are also not the same. I like both approaches but I like them to be delineated. If I'm with my friends I can appreciate it being a social gathering with a theme, but if I attend a "hardcore" book club, well, I expect it to be hardcore, talking about the book itself for most of the time.
That there is any significant confusion at all means it is not de facto (and if something is right and true based on a definition I don’t think you can call it de facto either...).
The distinction really doesn’t seem that important for most use cases so it’s not that surprising a weaker, possibly more useful interpretation has become common...
That there is any significant confusion at all means it is not de facto
There isn't any significant confusion. There is a token amount of confusion, which is pretty much always clarified every time one of these threads comes up.
(and if something is right and true based on a definition I don’t think you can call it de facto either...).
It's de facto, not de jure, because OSI has no authority to enforce their definition, since they don't have a trademark (at least not a registered trademark) on the term "Open Source". What makes it the de facto definition is just usage. By and large, among the people who care about the legal details of Open Source licensing, the OSD is accepted. Yes, there are a handful of exceptions, but that's OK. It doesn't change the basic point.
I guess in my experience, the phrase is routinely used to refer to code availability and often the fact that a licensing fee doesn’t need to be negotiated or paid in order to run the code on our servers (either in an academic or corporate setting), which is a weaker requirement than the OSI definition.
Real usage by real people not particularly passionate about adherence to the OSI definition—to me this is its de facto meaning. I’m not saying it’s correct usage, but it’s definitely real and frequent.
It’s my impression a non-negligible number of people share the same understanding, evidence by the fact that this discussion apparently is recurring? Even those who corrected the Defold release language knew what was intended, even if they said it was incorrect usage of the phrase.
Your response assumed the number of people who use the phrase with a looser meaning is small; I just don’t think that is true based on my day to day experiences.
Real usage by real people not particularly passionate about adherence to the OSI definition—to me this is its de facto meaning.
I'm not talking about "people who are particularly passionate about adherence to the OSI definition" though. I'm talking about people who are "particularly interested in the actual technicalities of what OSS is", not all of whom may agree with the OSD. But I still argue that such a significant majority do that it constitutes the de facto definition.
Your response assumed the number of people who use the phrase with a looser meaning is small;
Not at all. I am saying that the people using that phrase in the "looser" sense, as you put it, are using it in a colloquial and not technical sense, and that such usage has no meaning as far as what the de facto meaning is, when used in an actual technical context. That's just lack of knowledge, not any attempt to create a different definition.
I see it more like somebody who doesn't know much about cars referring to an engine block as a carburetor. Even if a lot of people make that same mistake, it's still a mistake and the actual definitions of "engine block" and "carburetor" don't change.
Quite a remarkable lack of IANAL flags for a lot of people talking about false advertising/trademark law...IANAL but the minimal data I have suggests the phrase “open source” has very little protection (not strictly claimed on OSI website, no major track record of being defended in court, broadly accepted vague definition, unlikely to damage the trademarked brand’s image/rep).
Very different from falsely claiming the release is OSI compliant or whatever the legalese is...
I think people have just figured out that "IANAL" goes without saying in any online public discussion, unless for whatever reason it happens to be in a forum where arbitrary participants are especially likely to be lawyers. This is not a commercial context where fraud would be a concern, and even if the speaker was a lawyer there is no reasonable expectation of any attorney-client relationship between random participants in a public discussion. "IANAL" flags are superfluous.
> Very different from falsely claiming the release is OSI compliant or whatever the legalese is...
The de facto accepted way to say that a license is OSI compliant is to refer to it as "open source".
