Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> In that case I would change the wording from "contains malware" to "may contain malware".

Or even more precise: "may contain copyright infringement".



sort by: page size:

> †: I didn't misspell the name of the executable. It's missing an h.

I've seen a lot of posts defending Zoom wrt other offences. But at this point it should be clear what their practices are.


>absurd unsubstantiated claims

Interesting way to describe a situation in which company A had the same owners as malware company B and also integrated a never-before-seen unobfuscated copy of company B's malware into company A's app.

The claims are neither absurd nor unsubstantiated.


> we think it might be <name of competitor>

You know who has in past been sued for copying competitors work, sometimes stealing the whole package including bugs and backdoors?

Here is a hit: the company is currently banned from multiple markets due to national security.


>It is against that type of OCR that my app is resistant to.

There is no form of OCR this is resistant to, simply the change the description to be accurate and remove references to being OCR resistant as this is false.


"And if it's in the blacklist, don't tell the user at all, and instead start introducing subtle errors everywhere. "What, you saved it yesterday and now it doesn't open? Whoops (snicker)." Or, misalign printing so anything looks good for a draft but not 'professional' use. Or you could go the obvious route of slapping a banner on it, but that is usually easily removable"

"Gee, I'm sure glad I decided to pirate [program], it's buggy as hell. Better warn my friends..."


> Possibly file a ticket on their github to clarify this?

At the time of writing the link on this submission is a ticket which they seem to have opened.

And based on the link in that ticket to this…

https://github.com/dotnet/core/blob/main/license-information...

… I don’t think what they’re saying is clearly wrong. I can see why they’re seeking some clarification.


To me, that wording looks like a scam attempt or a malware threat, and most first-level techs I've worked with would reject it out of hand for that reason.

> I wonder if the source was also modified, or only the binaries.

Personally, pending further information, I've removed Transmission from my machine.


> What happens when that person gets bored with the project... or decides to do something malicious (as in the case with a recent backdoor in the XZ compression tool)...

The maintainer of the xz compression tool didn't do anything malicious. This statement is incorrect and damaging.


> Correction: an internal message display tool.

For the millionth time, it was not a general message display tool. It is a security tool to flag domains that run the risk of data leakage and malware. Trying to hijack a security extension to turn it into a general messaging platform is both stupid and bad for security.


> Does it mean if it's from Korea, it automatically doesn't belong there?

No...? They mean that if a piece of third-party software adds its own CA (see Superfish) then it's automatically suspect.

-Emily


> so they really need to come up with better wording.

No, they need to come up with a better way of communication that doesn't involve leaking permission.


> I would really like to read the actual full text document.

I think they are not releasing the full text to protect their source in case the text was steganographically marked.


http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...

It's stated as much in the initial proposal.

"1) Some contributors are actively blocked from contributing code to LLVM."

> These contributors have been holding back patches for quite some time that they’d like to upstream. Corporate contributors (in particular) often have patents on many different things, and while it is reasonable for them to grant access to patents related to LLVM, the wording in the Developer Policy can be interpreted to imply that unrelated parts of their IP could accidentally be granted to LLVM (through “scope creep”).


>If the code was old, as it’s been when products like Symantec’s were leaked, this might not be so bad - but it’s not.

>http://adamcaudill.com/files/Screenshot_4_4_13_10_04_PM.png

>References in the files indicate that the code is from sometime in February - so this is current code.

Given that that image shows dates in 2012, I think the author has made the classic mistake many of us make at the start of the new year, of still thinking it's the old one.


> a test update that was pushed to production unintentionally rather than malware

This position seems to be based on the assumption that malware is less likely to be subject to mistakes than MSFT.

Want to check with the PR dept? ;)


> Looks like someone made a boo-boo it’s simply based on the user agent, w/e string matching they do is too strict they aren’t checking for actual JS/WebASM compatibility or anything like that.

Microsoft has repeatedly engaged in malicious anticompetitive behavior. Without any additional information, I therefore think it's rational to place a high prior probability on this being malicious anticompetitive behavior. The data itself might be consistent with either an accident or malicious anticompetitive behavior. In that case, the prior dictates the posterior.


> Please reply to this email for issues regarding this item removal.

Have you tried telling them that?

Failing that -- if it were me -- I'd resubmit perhaps with the only addition of a README that briefly explains the file layout.


The headline doesn't really fit the issue.

content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found and fixed.

next

Legal | privacy