Which is fair but someone motivated, say a vendor that sells those "track customers in your store with bluetooth/Wi-Fi" adds support for this. Sure it's relatively low signal but it also costs nothing.
Why not? I meet my friends for lunch and want to send them some photos while sitting in the restaurant?
This seems like a very plausible scenario and most users would not expect and would not want everyone in the restaurant to be able to see their email and phone number.
The implausible part is not having lunch with friends, although the pandemic has made that feel less plausible than it used to be... but rather, having an attacker actively running an attack within 10s of feet of your table at the restaurant. What is your threat model that makes this plausible?! You must be super important to have attackers following you to lunch. Or maybe you like to eat at restaurants that do their best to harvest all visitor data, even going so far as to use cutting edge vulnerabilities?
The person you replied to literally said this should be fixed. I agree with them that this is nowhere near as serious as issues Apple has had before, since the attack requires physical proximity and the use of the share pane. Even then, it doesn’t give the attacker RCE privileges or anything similarly world shaking.
Should Apple fix it? Again, absolutely. No one has said otherwise.
Nothing is 100% secure, so the relative risk posed by vulnerabilities can only really be assessed with a threat model. In most threat models, this is nowhere near as bad as their “GOTO Fail” bug or any number of others over the years.
I think celebrities and VIPs are essentially the only ones whose threat models would actually be impacted by this vulnerability in a plausible way.
> You must be super important to have attackers following you to lunch. Or maybe you eat at restaurants that do their best to harvest all visitor data, even going so far as to use cutting edge vulnerabilities?
… and do not use all of the other options for getting data from people in close proximity such as cameras or microcell sites. If your threat model goes far enough that this matters you should be more worried about all of the other options. I would be more worried about a Bluetooth, WiFi, or cellular exploit given the history.
(No, this is not saying that Apple shouldn’t improve this - only that it doesn’t seem like a huge change in the amount of risk you’re exposed to)
Or just grab the phone out of your hand - most people take their phones out of their pocket all the time even on the street. I used to ride a bus and they would grab phones and jump off just as bus would leave a stop. You can actually often get a ton more data this way if you have physical custody of device - no airdrop impersonation needed.
I was trying to exclude obvious attacks, but you’re certainly right for the average person. I’d worry more about, say, shoulder surfing a credit card or
ID card more than this.
the threat model is that many someones knowingly or unknowingly have a stinger-like phone/device constantly collecting these hashes and cracking them. i know of at least one device in my building that was (likely unknowingly) attempting bluetooth-based hacking in a similar manner.
The remote RCE issues Apple has had are critical vulnerabilities. Saudi Arabi doesn't like you, they exploit remotely (maybe not even knowing who you are at all yet) to get your data / your contact lists and social graph etc - and you could be impacted or others could be impacted as a result in a major way.
This exploit requires that they already know who you are and where you live and where you go get coffee. They have to send a physical attacker to stalk your coffee shop. They have to have this equipment to run the impersonation exercise - and then wait until you are picking up coffee and airdropping something.
And after all this they get your email and phone number? So they know all these details about you but can't be bothered to use true people search or ANY of the data brokers or any of the giant data leaks to look this up?
Apple is selling a CONSUMER device. If your threat model is this elaborate, stick your phone in a faraday cage and leave it at home, someone could just grab it out of your hand at the coffee shop and be likely to get a lot more data.
So yes, it's a risk - but on the scale of risks including just being straight mugged and your phone stolen, it seems somewhat lower?
Is that necessary though. There are plenty of stories of people setting their AirDrop policies to 'Everyone' instead of 'Contacts Only' or 'None' where people are receiving unsolicited files (usually NSFW images). From my memory, they did not need to have their sharing pane open for this to happen to them.
They obtained an "IRB-exempt letter" because their IRB found that this was not human research. It's quite likely that the IRB made this finding based on a misrepresentation of the research during that initial stage; once they had an exemption letter the IRB wouldn't be looking any closer.
Not necessarily. And the conflation of IRB-exemption and not human subjects research is not exactly correct.[0]
Each institution, and each IRB is made up of people and a set of policies. One does not have to meaningfully misrepresent things to IRBs for them to be misunderstood. Further, exempt from IRB review and 'not human subjects research' are not actually the same thing. I've run into this problem personally - IRB declines to review the research plan because it does not meet their definition of human subjects research, however the journal will not accept the article without IRB review. Catch-22.
Further, research that involves deception is also considered a perfectly valid form of research in certain fields (e.g., Psychology). The IRB may not have responded simply because they see the complaint as invalid. Their mandate is protecting human beings from harm, not random individuals who email them from annoyance. They don't have in their framework protecting the linux kernel from harm any more than they have protecting a jet engine from harm (Sorry if that sounds callous). Someone not liking a study is not research misconduct and if the IRB determined within their processes that it isn't even human subjects research, there isn't a lot they can do here.
I suspect that this is just one of those disconnects that happens when people talk across disciplines. no misrepresentation was needed, all that was needed was for someone reviewing this, who's background is medicine and not CS, to not understand the organizational and human processes behind submitting a software 'patch'.
The follow up behavior...not great...but the start of this could be a serious of individually rational actions that combine into something problematic because they were not holistically evaluated in context.
Yes, your comment is the only one across the two threads which understands the nuance of the definition of human subjects research. This work is not "about" human subjects, and even the word "about" is interpreted a certain way in IRB review. If they interpret the research to be about software artifacts, and not human subjects, then the work is not under IRB purview (it can still be determined to be exempt, but that determination is from the IRB and not the PI).
However, given that, my interpretation of the federal common rule is that this work would indeed fit the definition of human subjects research, as it comprises an intervention, and it is about generalizable human procedures, not the software artifact.
Other note...different irbs treat not research vs exempt differently.
One institution I worked with conflated “exempt” and “not human subjects research” and required the same review of both.
Another institution separated them and would first establish if something was human subjects research. If it was, they would then review whether it was exempt from irb review based on certain categories. If they determined it was not human subjects research they would not review whether it met the exempt criteria, because in their mind they could not make such a determination for research that did not involve human subjects
I agree with your last paragraph, although I can totally understand how somebody who doesn’t know much about programming or open source would see otherwise.
> Further, research that involves deception is also considered a perfectly valid form of research in certain fields
The type of deception that is allowable in such cases is lying to participants about what it is that is being studied, such as telling people that they are taking a knowledge quiz when you are actually testing their reaction time.
Allowable deception does not include invading the space of people who did not consent to be studied under false pretenses.
> They don't have in their framework protecting the linux kernel from harm any more than they have protecting a jet engine from harm (Sorry if that sounds callous).
It sounds pretty callous if that jet engine gets mounted on a plane that carries humans. In this hypothetical the IRB absolutely should have a hand in stopping research that has a methodology that includes sabotaging a jet engine that could be installed on a passenger airplane.
Waiving it off as an inanimate object doesn't feel like it captures the complete problem, given that there are many safety critical systems that can depend on the inanimate object.
Your extrapolation provides clear context about how this can harm people, which is within an irb purview and likely their ability to understand.
I’m not saying it is okay, I’m simply saying how this could happen.
It requires understanding the connection between inanimate object and personal harm, which in this case is 1)non obvious and 2)not even something I necessarily accept within a common rule definition of harm.
Annoyance or inconvenience is not a meaningful human harm within the irb framework
But, fundamentally, the irb did not see this as human research. You and I and the commenters see how that is wrong. That is where their evaluation ended...they did not see human involvement right or wrong.
And irb is part of the discussion of research ethics, it is not the beginning nor the end of doing ethical research.
Here is a case, where one university's (Portland State University) IRB saw that sending satire articles to social science journals "violated ethical guidelines on human-subjects research".
* The researcher is a professor in the humanities, which typically does not deal with human subjects research and the (often) vague and confusing boundaries. Often, people from outside the social sciences and medical/biology fields struggle a little bit with IRBs because...things don't seem rational until you understand the history and details. Just like someone from CS.
* The researcher in your example DID NOT seek review by IRB (per my memory of the situation). That was the problem. The kernel bug authors seem to have engaged with their IRB. the difference is not doing it vs. a misunderstanding.
* The comments about seeking consent before submitting the fake papers ignore that it is perfectly possible to have done this WITHOUT a priori informed consent. It is perfectly possible for IRBs to review and approve studies involving deception. In those cases, informed consent is not required to collect data.
* Finally, people on IRBs tend to be academics and are highly likely to have some understanding of how a journal works. That would mean they understand the human role in journal publishing. The exact same IRB may well not have anyone with CS experience and may have looked at the kernel study and seen the human role differently than journal study.
* Lastly, the fact that the IRB in your example looked at 'animal rights' is telling. They were trying to figure out what Peter did. He published papers with data about experiments on animals...that would require IRB review. The fact that that charge was dismissed when they figured out no such experiments occurred is telling about who is acting in good faith.
My understanding in this case is not that the IRB declined to review the study plan, but that (quoting the study authors) "The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained)." (more information here: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....)
Do you think that the IRB was correct to make the determination they did? It does sound like a bit of a grey area
> The IRB of UMN reviewed the study and determined that this is not human research (a formal IRB exempt letter was obtained). Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning.
So the statement is a bit unclear to me, and I’m hesitant to come to a conclusion because I have not seen what they submitted.
As I read this they are saying:
* we explained the study to irb and asked whether it met their definition of human subjects research - based on our description they said it is not human subjects research
* therefore we did not apply to irb to have the study assessed for the appropriate type of review.
Exempt is a type of irb review, basically it is a low level desk review of a study. It does not mean no one looks at it, it just means the whole irb doesn’t have to discuss it.
I can see both sides of this. Irbs focus on protection of the rights of research participants. The assumption in cognitive models is of direct participants. This study ended up having indirect participants. I would argue that is the researchers job to clarify and ensure was reviewed. However, there is almost certainty this study would have been approved as exempt.
I think the irb likely did the right thing based on the information provided to them. The harm that HN is identifying does not fall within the normal irb definitions of harm anyways...which is direct harm to people. The causal chain HN is spun up about is very real...just not how irb views research typically
That's what it seemed like to me as well. Based on their research paper, they did not mention the individuals they interacted with at all.
They also lied in the paper about their methodology - claiming that once their code was accepted, they told the maintainers it should not be included. In reality, several of their bad commits made it into the stable branch.
I don’t think that’s what’s happening here. The research paper you’re talking about was already published, and supposedly only consisted of 3 patches, not the 200 or so being reverted here.
So it’s possible that this situation has nothing to do with that research, and is just another unethical thing that coincidentally comes from the same university. Or it really is a new study by the same people.
Either way, I think we should get the facts straight before the wrong people are attacked.
It is also quite easy to pull the wool over an IRBs eyes. An IRB is usually staffed with a few people from the medicine, biology, psychology and maybe (for the good ethical looks) philosophy and theology departments. Usually they aren't really qualified to know what a computer scientist is talking about describing their research.
And also, given that the stakes are higher e.g. in medicine, and the bar is lower in biology, one often gets a pass: "You don't want to poke anyone with needles, no LSD and no cages? Why are you asking us then?" Or something to that effect. The IRBs are just not used to such "harmless" things not being justified by the research objective.
see my other comment to the GP. pulling the wool suggests agency and intentionality that isn't necessarily present when you have disciplinary differences like you describe. Simple miscommunication, e.g., using totally normal field terminology that does not translate well, is different.
It is your job as a researcher to make the committee fully understand all the implications of what you are doing. If you fail in that, you failed in your duties. The committee will also tell you this, as well as any ethical guideline. Given that level of responsibility, it isn't easy to ascribe this to negligence on the part of the researchers, intent is far more likely.
No, it is your job as a researcher to make sure you never even bother to submit to the IRB something that might fail review.
Sometimes you might need to make the committee understand before a full review when you are asking where a line is for some tricky part, but you ask about those parts long before you have enough of the study designed to actually put it before the review.
Ethics are a personal responsibility. You should be personally embarrassed if you ever have something fail review, and probably should have your tenure removed as well since if your ethics are so bad as to put before the board something that fails you will also do something even worse without any review.
I've seen from a distance one CS department struggle with IRB to get approval for using Amazon Mechanical Turk to label pictures for computer vision datasets. I believe the resolution was creating a specialized approval process for that family of tasks.
I think it is because many labs in CS departments do very little research involving human subjects (e.g. a machine learning lab or a theory lab), so within those labs there isn't really an expectation that everything goes through IRB. Many CS graduate students likely never have to interact with IRB at all, so they probably don't even know when it is necessary to involve IRB. The rules for what requires IRB involvement are also somewhat open to interpretation. For example, surveys are often exempt depending on what the survey is asking about.
Machine learning automatically being exempt is a huge red flag for me. There are immense repercussions for the world on every comp sci topic. It's just less direct, and often "digital" which seems separate but it's not.
> the response from the researcher saying these were automated by a tool looks like a potential lie.
To be clear, this is unethical research.
But I read the paper, and these patches were probably automatically generated by a tool (or perhaps guided by a tool, and filled in concretely by a human): their analyses boil down to a very simple LLVM pass that just checks for pointer dereferences and inserts calls to functions that are identified as performing frees/deallocations before those dereferences. Page 9 and onwards of the paper[1] explains it in reasonable detail.
> Could they have submitted patches to fix the problems based on same tooling or was that not possible (I am not close to kernel development flow)?
Depends on what you mean: they knew exactly what they were patching, so they could easily have submitted inverse patches. On the other hand, the obverse research problem (patching existing UAFs rather than inserting new ones) is currently unsolved in the general case.
I have a feeling that methods of patching the Linux kernel is a concept most members of IRB boards wouldn't understand at all. It's pretty far outside their wheelhouse.
IRB is useless. They don't use much context, including if the speediness of IRB approval would save lives. You could make a reasonable argument that IRB has contributed to millions of preventable deaths at this point, with COV alone it's at least dozens of thousands if not far more.
This is the unfortunate attitude that leads to bad research and reduces trust in science. If you think IRB has contributed to deaths you should make a case, because right now you sound like a blowhard.
By COV do you mean Covid? It sounds like you're alluding to the argument that if they'd only let us test potential vaccines on humans right away then we would have had a vaccine faster. I disagree that that's a foregone conclusion, and you certainly need a strong argument or evidence to make such a claim.
They have been too busy with integrating crypto payments instead of fixing long standing issues or planned features (allow to register without a phone number).
But - to Signal's defense - while you can scrape the phone numbers, there is not much you can gain from it, you can only tell that a specific number is a Signal user. And sometimes you can see the username (if the user chooses to not encrypt it).
Given the re-use and re-issuance of phone numbers in very busy US area codes (like 212, 202, etc) it also only allows discovery that at some unknown point in the past, that number has been registered as a Signal user.
> With its focus on privacy, Signal excels in exposing almost no information about registered users, apart from their phone number. In contrast, WhatsApp exposes profile pictures and the About text for registered numbers, and requires users to opt-out of sharing this data by changing the default settings.
It amuses me how the low limit nature of Excel has affected the ecosystem around it. Apache POI, which is a popular library to operate on Excel files, has a weird 4GB limit [1] on uncompressed file size.
throw new IllegalArgumentException("Max entry size is bounded [0-4GB], but had " + maxEntrySize);
What makes you think this limitation is related to Excel? 4GiB is a very common limit due to it being the max size you can fit on a 32bit integer. It's the max file size on FAT32 as well for instance.
Something that's been missed a lot, I think, is that the Intel-based 13" MacBook Pro actually came in two versions -- a two-port one with a less-capable, low-power processor and a lot of limitations that made it more like a juiced-up Air, and a four-port one which was much more like the 15" MBP. The current M1-based MBP is direct replacement for that two-port model, and is now absolutely just a juiced-up Air; there's very little that the M1 MBP does that the M1 Air doesn't.
And, yes, the Intel version of the MacBook Pro But Really Juiced-Up Air, or MBPBRUJUA for short, could run two external 4K displays or one external 5K display, while the M1 MBPBRUJUA can only run one external display (although for the ones and ones of you out there with 6K displays, good news!). I would presume Apple knows this is a regression and plans to address it, at least when they update the four-port MBPs.
Personally, I'm not convinced the MBPBRUJUA is going to stay around past this product cycle; it's always struck me as a laptop in sort of a weird middle space, too big to make people who really want an Air happy but not "pro" enough to make, well, actual pros happy, and the shift to Apple Silicon brings the Air and the MBPBRUJUA so close together the only material difference is the case design. I can't help but suspect that the only reason we have an M1-based MBPBRUJUA is so Apple could tick off the "shipped an ARM-based laptop with a MacBook Pro nameplate in 2020" box.
If you manage domains and force this stuff off your users will def complain.
My worry is we end up w a situation such as cookie notices - users have gotten so used to clicking through content screens they don’t pay attention anymore because a lot of it is meaningless
I had a funny situation in person recently. This place had consent forms - lady checking folks in would offer to sign on your behalf. A few folks asked what it was - a consent form - oh sure, please sign for me.
In gsuite I guess there are some settings that can impact things like location - people want recent locations to pop up etc I learned. So anytime you make 95 percent of users click through stuff they don’t care about - you start losing the battle here
Consent forms force people into legally binding agreements, with massive power disparity, under duress.
The consumer bears all the risk and the provider absolves themselves of any - unless one afford a lengthy court battle or join a class action. I suppose even more rarely a consumer can get, often fractional, relief through a government or consumer rights agency.
EULAs, consent forms, and similar are a wholesale miscarriage of justice that causes incalculable irreparable harm to a staggering number of people every day. Think about it this way, a liability waiver at a doctors office is not dissimilar, in terms of bargaining ability, to an entry level employee's boss demanding sexual favors to keep their job. I have a broken arm, fix it, if the doctor screws up pay for all resulting costs forever.
Justice, equality, and equity should never be limited to those with the most means.
One last point to hopefully drive my point out of the park. Say I don't want to consent to gmails EULA, so I go and look into hosting my own webserver. Bad news, windows has a eula, okay I'll learn how to use Linux and FOSS software. But wait to need to connect my pc to the internet. I can't escape an internet providers take it or leave it eula. But I need email, I will get fired (lose everything in life) without it. So in effect I am forced, under duress, to 'consent' to a non-negotiable agreement that I reject with every fiber of my being so that I do not lose my home, family, and everything else.
Which is why these govt type of interventions, which are all centered around getting more and more permissions from users are annoying. We will get more click through screens that 99.99% of users will say yes to. Seriously, how many users read the google ToS clickthroughs and make a decision based on that to not sign up with a google account?
I turned this stuff off at policy level, and instead of praising me, users were pissed at me. They wanted google to track them. Most didn't understand why stuff didn't work (things like saving locations in maps break at least in past, and most use gmaps for work / home commute checks). Seriously - if you run a larger gsuite deploy, put all the privacy features on and watch how folks start trying to work around / do the shadow IT thing.
the cookie debacle really illustrated how toothless and futile current regulatory attemps are, the industry simply side-stepped the intent of the legislation and that was the end of it. It seems the cookie notices are annoying by design to guide public opinion against future regulatory attempts. "See what they made us do? Don't regulations stink?!"
>It seems the cookie notices are annoying by design to guide public opinion against future regulatory attempts. "See what they made us do? Don't regulations stink?!"
I get that impression also, and doubly so for the FUD-packed GDPR messages. "Oh sorry, we can't legally serve this webpage to you, EU resident, because of the atrocious GDPR! (because it's full of spyware which the GDPR forbids but we won't say that part out loud)"
For what it's worth, I do think the GDPR messages are raising awareness in a way the cookie warnings were not, in part because some websites use dark patterns to get you to "agree" and others do not, and people are starting to smell the bullshit. If nothing else, the laundry list of trackers the websites are required to tell you about is a real eye-opener to the layperson who doesn't run uMatrix.
If think the regulation wasn't a point of this work, but the main reason this was worked on in my opinion, was to fleece the tax payer. Imagine how many dinners, conferences, experts, lawyers, contractors, researchers had to be paid over the years. They eventually had to come up with something and that's the half bottomed result. If it doesn't work? Well, everyone already got paid and probably now work on something completely different.
If there is too much noise about this, they'll have a reason to fleece the tax payer again and go through years of "fixing" the legislation.
This is when you have unaccountable organisation (EC) without any bodies that would and could investigate corruptions and scams like these.
That and an attempt by companies to continue a business model that is expressly illegal under the GDPR. If a company relies on user-tracking with assumed consent, being required to get affirmative and freely given consent tanks their income. And that's perfectly okay and reasonable for laws to do. Business models are not a right.
But, those companies then have a choice. Option A: Accept that their business model relied on widespread stalking of their users which was never acceptable and is now illegal, and significantly change the business. Option B: Pretend they didn't notice, throw up a pop-up ignore the "freely given" requirement for consent, and hope nobody calls them out on it.
Option B is a lot easier for scummy companies to do, and the prevalence of opt-out banners with assumed consent and dark patterns shows how many companies went that route.
